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

[Filipus Klutiero]

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.