Re: Benefits from computing physical IDE disk geometry?

[Nick Piggin <piggin@cyberone.com.au>]

Mark Hahn wrote:

>>>>The benefit I see is knowing the seek time itself (not geometry), which
>>>>can be used to tune the IO scheduler. This is something that I'll
>>>>
>
>but seek time is some combination of headswitch time, rotational 
>latency, and actual head motion.  the first three are basically
>not accessible in any practical way.  the latter is easy, and the 
>
Yep which is one reason why I don't think being fancy will pay
off (the other reason being that even if you did know the parameters
I don't think they would help a lot).

I just want to know the average seek time.

>
>current approximation (seek time is a linear function of block distance)
>is very reasonable.
>
Well, strictly, not linear. But yes it does provide a good ordering.
That is besides the point though: I can decide if one request will
have a shorter seek time than another just fine. I would still like
to know the aproximate seek _time_ for higher level tuning stuff
eg. will anticipation be worth it, and how soon should requests
expire.

>
>
>adjusting the cost function would be interesting: I'm guessing that 
>handling short seeks (which are quite fast) would be more important
>than adjusting for zones.  given that the current queueing code 
>handles starvation, I wonder if we could actually permit backward
>seeks of, say, 0-2 cylinders.
>
There is (in AS) no cost function further than comparing distance
from the head. Closest forward seek wins.

If by the queueing code you mean the actual IO schedulers? Then
yes, they do handle starvation, however they (AS, deadline)
handle _fairness_ by not seeking backward. Well actually
AS does allow a process to seek upto IIRC 256MB backward
which is a couple of ext2 blockgroups while maintaining quite
good fairness.

>
>
>>Well using the assumption that |head sector - target sector| gives
>>an ordering correstponding to seek time, we do sort the queue optimally.
>>I personally feel that being trickier than that is too much complexity.
>>
>
>exactly.
>  
>