Subject: Re: nore on disk stats
To: Michael Galassi <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 11/10/1995 11:00:24
On Fri, 10 Nov 1995 06:44:26 -0800
Michael Galassi <firstname.lastname@example.org> 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
Thanks all for the suggestions.
Jason R. Thorpe email@example.com
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