From owner-cvs-all@FreeBSD.ORG Wed Feb 1 13:59:30 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B55F16A422; Wed, 1 Feb 2006 13:59:30 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD6FE43D6E; Wed, 1 Feb 2006 13:59:26 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k11DxOEr020009; Thu, 2 Feb 2006 00:59:24 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id k11DxL0P005527; Thu, 2 Feb 2006 00:59:22 +1100 Date: Thu, 2 Feb 2006 00:59:21 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "Greg 'groggy' Lehey" In-Reply-To: <20060131212852.GD97116@wantadilla.lemis.com> Message-ID: <20060201235815.A4168@delplex.bde.org> References: <200601301233.k0UCXiKq085748@repoman.freebsd.org> <20060130123525.GD83922@FreeBSD.org> <20060130215816.GC91655@wantadilla.lemis.com> <20060130220810.GA93542@FreeBSD.org> <20060131215638.V679@delplex.bde.org> <20060131212852.GD97116@wantadilla.lemis.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Matteo Riondato , Gleb Smirnoff , src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/etc/defaults periodic.conf X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2006 13:59:30 -0000 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