Subject: Re: nore on disk stats
To: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
From: Michael Galassi <>
List: tech-kern
Date: 11/10/1995 06:44:26
>> 	struct disk *disk_getfirst __P((void));
>> 		Returns first disk in disklist.

>> 	struct disk *disk_getnext __P((struct disk *));
>> 		Returns next disk in disklist.

>"why bother"?  Why not just let the users of the code access the list
>structures themselves?

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.

>If you Really Really Really want these, at least make them macros (not

No reason not to, but neither of these is performance critical and
macros can be messy.  Code with a liberal smatering of macroes also
tends to be hard on the eyes and brain when in a debugger.

>Quads are your friends.  I sincerely doubt that you'll wrap a quad
>counter "very quickly" (or even "at all" 8-)...

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

>I'd say: count in bytes.  it's the only thing you can count on.
>failing that, count in blocks, where 'blocks' are the device block

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.

>speaking of which, the disk structure should contain the device block

Amen, brother Chris!

>oh yeah, and in the long term, assuming in other code that the 'device
>block size' (i.e. DEV_BSIZE) is 512 bytes is annoying...

Especialy for those of us who keep hoping this will shift to 1024.

>> Anyhow, I'd like to hear any comments or suggestions, particularly, what 
>> the most useful "size unit per time unit" combination would be.

>"why bother"?  You're storing time, in some unit, and you're storing
>some unit of "data transferred."

>In my opinion, the only thing calculating averages should be user-land

Again, amen.  Maintain time stamps with couters, updated concurently with
counter changes.  Make available the time origin, and the time of latest
update as a single opperation and all else is trivialy done "as needed"
in user space.

Michael Galassi