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

From: Filipus Klutiero <[email-masked]>
Date: Tue, 07 Feb 2012 14:20:43 -0500

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
>>>>>>>> filesystem.
>>>>>>> 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.
>>>>>
>>>>> cheers,
>>>>> Pádraig.
>>>>>
>>>> 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", understandable.
>>>> 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.