>> That overlooks the fact that for a unidirectional scan, the head
>> still has to be scanned back across the whole width of the disk,
>> so you're actually saying that one is better off making all
>> suchlike seeks take 1+1=2 rather than letting some of them take
>> 1/2+1/2=1 - and I have to say that I disagree with you...
> You are missing the point. A return scan takes a short time, the
> time taken is in stopping the heads to service a request. The extra
> cost of the return is usually accepted as a tradeoff for the
> fairness.
{Shrug} Linus has spoken and stated that he won't consider anything
that converts the current system to scan in both directions, so the
decision has been made...
Personally, I can see nothing wrong in either method - providing the
head moves monotonically across the surface in each pass, I can see no
problem with reading sectors on the way back.
Before anybody starts, I agree that a "nearest sector" algorithm would
be a bad idea, but I've never proposed that anyway.
Also, there have been comments about a reverse scan being bad as the
head may have to reference sectors earlier on the same track. I don't
buy that, simply because not all disks make use of a 1:1 interleave
internally, so even a request for consecutive ascending sectors may
cause that to occur. To ensure that it never occurs, you'd have to
ensure that only sectors on different tracks were accessed after each
other, and that'd hold up requests for several consecutive sectors
abysmally and defeat the whole object of using an elevator algorithm
in the first place...
> Most os textbooks have a chapter on filesystem design that treats
> this topic. They usually explain why a one-way scan is usually
> used.
I had a look in the three OS textbooks I have access to. One followed
your comments pretty much to the letter, one explained that a one-way
scan is normally used because it's easier to program than a two-way
scan, and the third states that a two-way scan is normally used "in
professional systems" because of its higher efficiency.
It looks like in the OS textbook world, the jury's still out...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/