Subject: Re: nore on disk stats
To: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
From: Michael Galassi <nerd@percy.rain.com>
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
>functions)...
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
>size...
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
>size.
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
>programs...
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
--
Michael Galassi nerd@percy.rain.com http://percy.rain.com/~nerd/