Re: df: the inode format and various block-size arguments

[Bernhard Voelker]

On September 17, 2012 at 10:42 AM "Pádraig Brady" <address@hidden> wrote:
> On 09/17/2012 07:39 AM, Bernhard Voelker wrote:
> > Working on the new --output option for df, I realized that
> > 'df -i' only honors the --block-size arguments 'si' and
> > 'human-readable', but not arbitrary values like '1M':
> >
> >    $ for o in human-readable si M 1M ; do \
> >        src/df -i --block-size=$o . ; \
> >      done
> >    Filesystem     Inodes IUsed IFree IUse% Mounted on
> >    /dev/sdb         256K   21K  236K    9% /home
> >    Filesystem     Inodes IUsed IFree IUse% Mounted on
> >    /dev/sdb         263k   22k  241k    9% /home
> >    Filesystem     Inodes IUsed  IFree IUse% Mounted on
> >    /dev/sdb       262144 21406 240738    9% /home
> >    Filesystem     Inodes IUsed  IFree IUse% Mounted on
> >    /dev/sdb       262144 21406 240738    9% /home
> >
> > There's nothing helpful about this in the .texi file.
> > Is this correct behavior? If true, then it should at
> > least be documented.
>
> Not a big issue, but yes inode count should be consistent
> with formatting options for bytes so this is a bug I'd say.

df.c is quite complicated when it comes to the handling of the
variables human_output_opts, inode_format, header_format,
human_scale and output_block_size.

> > But here's an even stranger example: df appends the
> > 'B' suffix to the inode values while not taking the
> > factor into account:
> >
> > src/df -i --block-size=MiB .
> > Filesystem      Inodes  IUsed   IFree IUse% Mounted on
> > /dev/sdb       262144B 21406B 240738B    9% /home
> >
> > What about this?
>
> Yep it's not a byte count so there should be no 'B'.
> There is a related general issue with human() in
> that it treats the B suffix as significant:
>
> # Why no suffix here?
> $ df --block-size=1M .
> Filesystem           1M-blocks      Used Available Use% Mounted on
> /dev/sdb1                98430     71074     22357  77% /home

As I read the info page, I'd say that's expected behavior
(see *node Block size):

    A plain suffix without a preceding integer acts as if `1' were
  prepended, except that it causes a size indication to be appended to
  the output.  For example, `--block-size="kB"' displays 3000 as `3kB'.

> # Without a leading '1' a suffix is used
> $ df --block-size=M .
> Filesystem           1M-blocks      Used Available Use% Mounted on
> /dev/sdb1               98430M    71074M    22357M  77% /home

dito.

> # You can't use IEC units without a trailing 'B'
> $ df --block-size=Mi .
> df: invalid suffix in --block-size argument `Mi'

Maybe also covered?

     An integer block size can be followed by a suffix to specify a
  multiple of that size.  A bare size letter, or one followed by `iB',
  specifies a multiple using powers of 1024.


> # But you can use IEC units without a trailing 'B' from the environment?
> $ BLOCKSIZE=Mi df .
> Filesystem           1M-blocks      Used Available Use% Mounted on
> /dev/sdb1                98430     71074     22357  77% /home

yes, that looks like an error. That's because there's no format
checking in humblock() in lib/human.c when 'spec' comes from
the BLOCKSIZE or BLOCK_SIZE env variables.

> # IEC with a trailing 'B' is Ok as as --block-size arg
> $ df --block-size=MiB .
> Filesystem         1MiB-blocks      Used Available Use% Mounted on
> /dev/sdb1             98430MiB  71074MiB  22357MiB  77% /home

That's as it should, isn't it?

> # The only way to select SI units is to use a trailing 'B'
> $ df --block-size=MB .
> Filesystem          1MB-blocks      Used Available Use% Mounted on
> /dev/sdb1             103211MB   74526MB   23443MB  77% /home

or --si ;-)

> All very inconsistent and confusing.

Well, as long as it is documented and consistent with other
df implementations, I don't see a problem. ;-)

> Note fixing some of this is not possible because of backwards compat issues.

I think this needs further discussions ...

In the meantime, I'll try to get the same results as today
with my new --output option.

Have a nice day,
Berny