cvs commit: src/etc/defaults periodic.conf

[Bruce Evans]

On Wed, 1 Feb 2006, Greg 'groggy' Lehey wrote:

> On Tuesday, 31 January 2006 at 21:59:48 +1100, Bruce Evans wrote:
>> On Tue, 31 Jan 2006, Gleb Smirnoff wrote:
>>
>>> On Tue, Jan 31, 2006 at 08:28:16AM +1030, Greg 'groggy' Lehey wrote:
>>> G> On Monday, 30 January 2006 at 15:35:25 +0300, Gleb Smirnoff wrote:
>>> G> > On Mon, Jan 30, 2006 at 12:33:44PM +0000, Matteo Riondato wrote:
>>> G> > M>   Make df output in periodic mail human readable
>>> G> >
>>> G> > Thanks!
>>> G>
>>> G> *sigh*
>>> G>
>>> G> Not everybody is human.
>>
>> Is somebody who thinks in exponential notation human?
>
> Possibly.  But is -h exponential?  It's far too coarse-grained.

It's exponential used in a bad way.  Exponential notation is good
for consistently scaling things that have similar sizes, and for
comparison of things that have exponentially different sizes.
In df it is used to inconsistently scale things that have similar
sizes.

> My main objection to -h is that it's so difficult to read.  Currently
> I look at the output and I can see optically the relationships between
> the individual file systems.  For example:
>
>  Filesystem        1048576-blocks   Used Avail Capacity  Mounted on
>  /dev/ad0s3a                 8905   7924   268    97%    /
>  devfs                          0      0     0   100%    /dev
>  /dev/ad0s2a                 7929   2385  4908    33%    /5
>  ...
>  wantadilla:/dumpb         187780 180114  5788    97%    /dumpb
>  /dev/da0s1                   121     16   104    13%    /camera
>
> With -h, this distinction disappears: I need to read each individual
> line to compare them:
> 
>  Filesystem           Size    Used   Avail Capacity  Mounted on
>  /dev/ad0s3a          8.7G    7.7G    268M    97%    /
>  devfs                1.0K    1.0K      0B   100%    /dev
>  /dev/ad0s2a          7.7G    2.3G    4.8G    33%    /5
>  ...
>  wantadilla:/dumpb    183G    176G    5.7G    97%    /dumpb
>  /dev/da0s1           121M     16M    105M    13%    /camera
>
> In the first output, the size of /dummpb is clearly about 1500 times
> the size of /camera (bottom two lines).  In the second output, you
> really need to look at the 'G' and the 'M'.

Also, for "/" and others, the scales are different within a single line.

Humans actually already use exponential notation too "see" things.
The see the lengths of the digit strings, which are essentially the
logarithms to base 10 of the sizes.  It is only necessary to read the
sizes to compare ones that are close.  With df -h, the lengths of the
digit strings can be seen in the same way, but to compare sizes all
the suffixes must be read, converted to different integers ("G" -> 9,
etc.) and added to the things seen.  I can't do the latter step
"optically" for even 2 numbers.

> Matteo suggested using -m instead of -k.  Clearly I like that (it's my
> default).  But maybe the real question is a matter of scaling.
> Clearly something like this looks confusing:
>
>  Filesystem        1K-blocks      Used   Avail Capacity  Mounted on
>  wantadilla:/dumpb 192287056 184436908 5927280    97%    /dumpb

1K is already scaled from the POSIX default of 512, and the POSIX
default of 512 is already scaled from the actual fs block size which
now defaults to 2K for ffs.

I think a config flag to set the default is enough and the default
shouldn't have been changed.

> So maybe we need a df option that maintains a certain number of
> significant digits; for /camera it might correspond to -k:
>
>  Filesystem 1K-blocks  Used  Avail Capacity  Mounted on
>  /dev/da0s1    124096 16704 107392    13%    /camera

Yes, this would give dynamically what most (?) users do statically by
setting BLOCKSIZE.

> For most, however, it would correspond to -m.  The important thing is
> that it should use the same unit for all file systems mentioned.

-k works fine for file system sizes up to 10G or 100G, which may still
be the sizes for most.

Bruce