[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10561: stat unclear about size on disk and type of blocks discussed

From: Filipus Klutiero
Subject: bug#10561: stat unclear about size on disk and type of blocks discussed
Date: Tue, 07 Feb 2012 14:20:43 -0500
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20120104 Icedove/8.0

On 2012-02-07 13:55, Pádraig Brady wrote:
On 02/07/2012 06:26 PM, Filipus Klutiero wrote:
Hi Pádraig,

On 2012-01-20 19:03, Pádraig Brady wrote:
On 01/20/2012 05:47 PM, Filipus Klutiero wrote:
Hi Pádraig and Jim,

On 2012-01-20 09:15, Pádraig Brady wrote:
On 01/20/2012 02:03 PM, Jim Meyering wrote:
Pádraig Brady wrote:
As for %o, if you'd ask me what "I/O block size" means without any
context, I'm far from being sure I would answer it means size on
disk. I suggest to call this Size on disk, or Size used on the
I/O implies transfer.
So it corresponds to an "optimal transfer size hint"
This value can be different at each layer, for example:

$ stat -c "%o" .                # file level
$ stat -f -c "%s" .             # file system level
# blockdev --getioopt /dev/sda  # device level

I'm not sure what language should be used instead. Perhaps instead
of blocks the manual should talk about "data storage device blocks".
I suppose we could clarify "I/O block size" a bit.
How about s|I/O block size|optimal I/O block transfer size|
or even without "block",

     "optimal I/O transfer size"
OK I'll go with "optimal I/O transfer size hint",
since there is nothing guaranteed about it,
and in fact it's often wrong.


I'm sorry but this change does not really address my concern.
It does actually, because...

The previous definition of %o did refer to "block" without specifying which kind of 
block. This is no longer the case as the new definition no longer refers to blocks. However, I 
still do not consider the new definition, "Optimal I/O transfer size hint", 
To come back to my original problem, I tried figuring out how much disk space a small file took. In Windows, 
I would look at "Size on disk". If "optimal I/O transfer size hint" means size on disk, 
this is still very unclear. Even after reading your answers, I don't understand what "Optimal I/O 
transfer size" means.
I am not looking for a transfer size.
... you know to ignore %o
What do you mean?
Above you realised you're not looking for a transfer size.
Hence it should be apparent that %o doesn't output anything
you're interested in.

So are you saying that stat cannot display a file's size on disk?

My question is, if I'm putting a small file on my filesystem, how much space 
will it use.
Here are 2 new descriptions I suggest:
Size occupied when including slack space
Size of the clusters occupied

Appart from %o, the ambiguity problem in the descriptions of %b and %B remains.
No it does not.
Really? The description of %b still reads:
Number of blocks allocated (see %B)
How does this description exclude that it refers to file system blocks?

As I said they're abstract entities only valid in relation to each other.
Just multiple %b x %B to get your answer.
If these statistics are internals, please mention that. It would also be nice 
to explain if the user can do anything with these internals.
I don't see any ambiguity. %b and %B are described in relation
to each other, which is all that's required.

That's not all that's required. Each directive should have a useful description, not just a circular definition.
See how each refers to the other in the docs:

   %b     Number of blocks allocated (see %B)
   %B     The size in bytes of each block reported by %b

I see that, but I fail to see how that would make the description of %b unambiguous. A file has a number of file system blocks allocated. I do not see what would prevent a reader from interpreting %b as that number.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]