lkml.org 
[lkml]   [1998]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: elevator algorithm bug in ll_rw_blk.c
On Sun, Nov 15, 1998 at 07:24:46PM +0000, Riley Williams wrote:

> 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 taake
> 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...
>
> > A long seek does not take that much longer than a medium one using
> > a unidirectional scan lowers the max-norm of the wait.
>
> Nope, it RAISES it - which is also the reason why most printers have
> switched over to doing bidirectional printing...

The problem with harddrives is that they, unlike printers, only spin in one
direction.

Thus it is very unwise to read sectors in descending order.

You could apply a two way elevator well if you knew about the physical
characteristics of the drive. Unfortunately there is no way to find that out
for most modern drives.

Yes, some heuristic could be done, along the way 'if the block I'm going
to read is far enough, I'd probably have no trouble with the sector slipping
just under the head' and such, but I think this would only add more
complexity.

Vojtech

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.340 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site