cvs commit: src/etc/defaults periodic.conf
Greg 'groggy' Lehey
grog at FreeBSD.org
Tue Jan 31 13:29:02 PST 2006
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.
>> The periodic output is for humans. The monitoring software -
>> nagios, remstats, etc runs df (or other tools) itself.
>
> Then it should not use df with the -h (hideous) flag.
Heh.
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
/dev/ad0s5 9388 3615 5296 41% /ubuntu
/dev/ad0s7 27764 14707 11646 56% /home
procfs 0 0 0 100% /proc
battunga:/ 3969 2931 721 80% /battunga
battunga:/home 5267 1800 3046 37% /battunga/home
echunga:/ 14873 8226 5457 60% /echunga
echunga:/home 9916 3869 5252 42% /echunga/home
echunga:/src 188356 115525 57762 67% /src
echunga:/dump 122037 88778 23496 79% /dump
wantadilla:/ 9912 5813 3305 64% /wantadilla
wantadilla:/home 51895 46826 917 98% /wantadilla/home
wantadilla:/dumpa 76285 62487 7695 89% /dumpa
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
/dev/ad0s5 9.2G 3.5G 5.2G 41% /ubuntu
/dev/ad0s7 27G 14G 11G 56% /home
procfs 4.0K 4.0K 0B 100% /proc
battunga:/ 3.9G 2.9G 721M 80% /battunga
battunga:/home 5.1G 1.8G 3.0G 37% /battunga/home
echunga:/ 15G 8.0G 5.3G 60% /echunga
echunga:/home 9.7G 3.8G 5.1G 42% /echunga/home
echunga:/src 184G 113G 56G 67% /src
echunga:/dump 119G 87G 23G 79% /dump
wantadilla:/ 9.7G 5.7G 3.2G 64% /wantadilla
wantadilla:/home 51G 46G 918M 98% /wantadilla/home
wantadilla:/dumpa 74G 61G 7.5G 89% /dumpa
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'.
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
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
For most, however, it would correspond to -m. The important thing is
that it should use the same unit for all file systems mentioned.
Thoughts?
Greg
--
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20060201/8d9f1bde/attachment.bin
More information about the cvs-src
mailing list