Subject: Re: nore on disk stats
To: Michael Galassi <nerd@percy.rain.com>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-kern
Date: 11/10/1995 11:00:24
On Fri, 10 Nov 1995 06:44:26 -0800 
 Michael Galassi <nerd@percy.rain.com> wrote:

 > My two cents, hiding the way the "struct disk"s are layed out in
 > memory seems like a good thing.  The various directory access methods
 > that various UNIXen went through and the pain associated with them
 > teaches that.

Actually, after having frobbed with a thing or two (mostly, ripping the 
dk_time caclulation out of kern_clock.c and moving it into subr_disk.c 
where it belongs), there's not really much of a need to access the 
disklist itself outside of subr_disk.c.  I've nuked the fist/next 
functions.  For cases access to the disk (dkdevice) "list" was needed 
before, the disk_find() function suffices (and, it actually a bit more 
correct than the method previously being used).

 > If you are talking byte counters they will wrap, you can always
 > overflow into a "counter of counters" though.

Hmm ... between a u_int64_t counter and a u_int64_t overflow, you could 
_really_ count some bytes :-)

 > Since all tranfers are in blocks I would go with blocks, a one byte
 > write is after all still transfering a whole block to the disk.

Actually, the problem with counting blocks is "whose notion of blocks?".  
Are we using DEV_BSIZE (which might not be the actual devie blocksize), 
the value in lp->d_secsize (which can be arbitrarily changed to an 
incorrect value), or some other disk-depenent value?  Chris mentioned, 
and I agree, that the disk structure should carry a "dk_blksize" 
member, but it's not clear to me that very many things will be able to 
use it first-off.

In any case, for the sake of simplicity, I'm counting bytes, caclulated 
by (bp->b_bcount - bp->b_resid).  This value is passed to disk_unbusy(), 
and the counter incremented.  The kernel will not do any transfer rate 
calculations.  Rather, it will keep a running total of bytes and busy 
time, and a user-land program that wants to know the average transfer 
rate can easily calculate it in whichever units are most meaningful at 
the time.

Thanks all for the suggestions.

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939