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.
