GNU bug report logs - #10561
stat unclear about size on disk and type of blocks discussed

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10561 in the body.
You can then email your comments to 10561 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Filipus Klutiero <chealer <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: stat unclear about size on disk and type of blocks discussed
Date: Fri, 20 Jan 2012 02:16:04 -0500

Today I tried figuring out how much disk space a small file took. I used 
stat, but that turned out surprisingly difficult:

> # LANG=C stat htpasswd.setup
>   File: `htpasswd.setup'
>   Size: 54              Blocks: 8          IO Block: 4096   regular file
> Device: 805h/2053d      Inode: 5268976     Links: 1
> Access: (0640/-rw-r-----)  Uid: (    0/    root)   Gid: (   33/www-data)
> Access: 2012-01-19 15:00:58.000000000 -0500
> Modify: 2012-01-19 15:00:54.000000000 -0500
> Change: 2012-01-19 15:00:54.000000000 -0500
>  Birth: -
> root <at> vinci:/etc/phpmyadmin#

The "real" size is clear, but at first I thought that didn't say the 
size on disk.

There are 3 interesting format sequences:

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

> %o
>  I/O block size

In the default format, %b is shown as "Blocks" and %o is shown as "IO 
Block".
On my system, there are 2 kinds of blocks, those on the HDD, 512 bytes 
each, and those of the filesystem, 4096 each. The manual's descriptions 
do not make it clear which kind of block is referred to. After 
verification, %b refers to HDD blocks.
I'm not sure what language should be used instead. Perhaps instead of 
blocks the manual should talk about "data storage device blocks".

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.

Message #8 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Filipus Klutiero <chealer <at> gmail.com>
Cc: 10561 <at> debbugs.gnu.org
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Fri, 20 Jan 2012 12:27:34 +0000

On 01/20/2012 07:16 AM, Filipus Klutiero wrote:
> Today I tried figuring out how much disk space a small file took. I used stat, but that turned out surprisingly difficult:

First of all, `du` is probably a better tool to this use case. Anyway...

>> # LANG=C stat htpasswd.setup
>>   File: `htpasswd.setup'
>>   Size: 54              Blocks: 8          IO Block: 4096   regular file
>> Device: 805h/2053d      Inode: 5268976     Links: 1
>> Access: (0640/-rw-r-----)  Uid: (    0/    root)   Gid: (   33/www-data)
>> Access: 2012-01-19 15:00:58.000000000 -0500
>> Modify: 2012-01-19 15:00:54.000000000 -0500
>> Change: 2012-01-19 15:00:54.000000000 -0500
>>  Birth: -
>> root <at> vinci:/etc/phpmyadmin#
> 
> The "real" size is clear, but at first I thought that didn't say the size on disk.
> 
> There are 3 interesting format sequences:
> 
>> %b
>>  Number of blocks allocated (see %B)
>> %B
>>  The size in bytes of each block reported by %b
> 
>> %o
>>  I/O block size
> 
> In the default format, %b is shown as "Blocks" and %o is shown as "IO Block".
> On my system, there are 2 kinds of blocks, those on the HDD, 512 bytes each, and those of the filesystem, 4096 each. The manual's descriptions do not make it clear which kind of block is referred to. After verification, %b refers to HDD blocks.

Well %B may not always refer to "HDD blocks".
Just interpret it as described.
I.E. an abstract multiplier for %b.

To be concrete about block sizes, there are generally 3 to consider:

1. physical     defined by the hardware device
2. logical      the smallest addressable unit used for the device
3. file system  ditto for the file system

Traditionally one had a physical block size of 512,
but a larger logical size of say 4096, with the size
determining the usual I/O ops vs fragmentation trade-off.

One can query 1. and 2. like:

# strace -e ioctl blockdev --getpbsz /dev/sda
ioctl(3, BLKPBSZGET, 512)               = 0
512
# strace -e ioctl blockdev --getbsz /dev/sda
ioctl(3, BLKBSZGET, 4096)               = 0
4096

`stat` works at the file and file system level,
so 3. can be queried like:

$ stat -f -c "%S" .
4096

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

cheers,
Padraig.

Message #11 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 10561 <at> debbugs.gnu.org, Filipus Klutiero <chealer <at> gmail.com>
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Fri, 20 Jan 2012 15:03:03 +0100

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"

Either way.  Thanks.

Message #16 received at 10561-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 10561-done <at> debbugs.gnu.org, Filipus Klutiero <chealer <at> gmail.com>
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Fri, 20 Jan 2012 14:15:41 +0000

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.

p.s. marking bug done...

Message #19 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Filipus Klutiero <chealer <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 10561 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Fri, 20 Jan 2012 12:47:49 -0500

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

Thank you for the information about blocks and commands Pádraig.

Message #22 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Filipus Klutiero <chealer <at> gmail.com>
Cc: 10561 <at> debbugs.gnu.org
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Sat, 21 Jan 2012 00:03:24 +0000

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

> 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. As I said they're abstract entities only valid in relation to each other.
Just multiple %b x %B to get your answer.

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

cheers,
Pádraig.

Message #25 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 10561 <at> debbugs.gnu.org, P <at> draigBrady.com
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Fri, 20 Jan 2012 16:26:36 -0800

On 01/20/2012 06:15 AM, Pádraig Brady wrote:
> I'll go with "optimal I/O transfer size hint",

There's no guarantee that it's optimal,
and I/O is always transfer, so how about
something like "I/O buffer size hint" instead?

Message #28 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10561 <at> debbugs.gnu.org
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Sat, 21 Jan 2012 00:48:39 +0000

On 01/21/2012 12:26 AM, Paul Eggert wrote:
> On 01/20/2012 06:15 AM, Pádraig Brady wrote:
>> I'll go with "optimal I/O transfer size hint",
> 
> There's no guarantee that it's optimal,
> and I/O is always transfer, so how about
> something like "I/O buffer size hint" instead?

Well I used optimal so that'sit's clear it's
a performance knob, and it correlates with
ioctl() and blockdev(1) params.

Also "buffer size" might be construed as
referring to an existing system buffer.

So I marginally prefer what's already committed.

cheers,
Pádraig.

Message #31 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Filipus Klutiero <chealer <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 10561 <at> debbugs.gnu.org
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Tue, 07 Feb 2012 13:26:21 -0500

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

Message #34 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Filipus Klutiero <chealer <at> gmail.com>
Cc: 10561 <at> debbugs.gnu.org
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Tue, 07 Feb 2012 18:55:54 +0000

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.

Message #37 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Filipus Klutiero <chealer <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>, 10561 <at> debbugs.gnu.org
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
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.

Message #40 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Filipus Klutiero <chealer <at> gmail.com>
Cc: 10561 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Tue, 07 Feb 2012 12:44:07 -0700

[Message part 1 (text/plain, inline)]

On 02/07/2012 12:20 PM, Filipus Klutiero wrote:
> 
> So are you saying that stat cannot display a file's size on disk?

Not without inventing a new % modifier, or else you doing the math
yourself.  So maybe it is worth adding a new one, as in:

%S  Allocated size (same as %b * %B)

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

Maybe it would help to do things like:

%b   Number of blocks allocated (see %B), corresponds to st_blocks
%B   The size in bytes of each block reported by %b, or st_blksize

for those that are familiar with the stat(2) interface.  For that
matter, tying ALL of the existing % modifiers back to struct stat
members might be handy.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #43 received at 10561 <at> debbugs.gnu.org (full text, mbox):

From: Filipus Klutiero <chealer <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>, 10561 <at> debbugs.gnu.org
Subject: Re: bug#10561: stat unclear about size on disk and type of blocks
	discussed
Date: Tue, 07 Feb 2012 15:51:21 -0500

Hi Eric,

On 2012-02-07 14:44, Eric Blake wrote:
> On 02/07/2012 12:20 PM, Filipus Klutiero wrote:
>> So are you saying that stat cannot display a file's size on disk?
> Not without inventing a new % modifier, or else you doing the math
> yourself.

Thank you very much.

I apologize for much of what I said in this report. I started with the 
assumption that stat could display the size on disk. When I saw that no 
field other than %o contained that, that %o's description read "I/O 
block size" and that %o indeed matched the size on disk for one file, I 
concluded that %o meant size on disk. It turns out that was just a 
coincidence, which happens only when a file fits in a single block.

Please disregard everything I said about %o. From this point, please 
consider this bug report to be only about the descriptions of %b and %B.

>    So maybe it is worth adding a new one, as in:
>
> %S  Allocated size (same as %b * %B)

Absolutely. I requested that in #10755: 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10755
>
>>> 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.
> Maybe it would help to do things like:
>
> %b   Number of blocks allocated (see %B), corresponds to st_blocks
> %B   The size in bytes of each block reported by %b, or st_blksize
>
> for those that are familiar with the stat(2) interface.  For that
> matter, tying ALL of the existing % modifiers back to struct stat
> members might be handy.

Probably. I am not familiar with stat(2), and although that would indeed 
provide a way to decide which sense is meant, it would not be a very 
accessible one to me.
I still recommend to specify the type of blocks discussed. Based on 
Pádraig's explanation, I believe a reference to "physical blocks" rather 
than "blocks" would address the problem.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.