bug-coreutils
[Top][All Lists]
Advanced

[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: Pádraig Brady
Subject: bug#10561: stat unclear about size on disk and type of blocks discussed
Date: Tue, 07 Feb 2012 18:55:54 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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.

>>
>>> 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.
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

>> You may have missed the start of the last mail, where I said
>> the du command is more appropriate (it does the above for you).
>>
> 
> I did not miss that. I was looking for information from stat. I am not asking 
> stat to provide that information. What annoyed me was that I couldn't tell if 
> stat was providing that information because some of the statistics displayed 
> were unclear.
> I'll try to remember to use du for that, thanks, but it's easier to remember 
> a single command, and I generally prefer a command that tells me both the 
> size on disk and the actual size.

The best we can do is:

stat -c 'allocated-space=%B*%b apparent-size=%s' $file

cheers,
Pádraig.





reply via email to

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