Subject: Re: nore on disk stats
To: Michael Galassi <>
From: Jason Thorpe <>
List: tech-kern
Date: 11/10/1995 11:00:24
On Fri, 10 Nov 1995 06:44:26 -0800 
 Michael Galassi <> 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                             
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