lkml.org 
[lkml]   [1998]   [Nov]   [13]   [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 Fri, Nov 13, 1998 at 11:32:00AM +1300, Chris Wedgwood wrote:
> I ask this because back aroun 2.1.26 I made a small char device which
> allowed to to log and then dump the sequences of disk update produced
> during a `sync' operation.
>
> Anyhow, the net result of this was that they were not optimally
> order, not even close.

Even with the elevator algorithm, with a limited request queue size
`sync' is going to be far from optimal. You'll get reordering within
the request queue, but the bulk order will depend on the page scanning
order not disk order.

It might be worth sorting the list of I/O pages according to an
optimised I/O order from time to time. If anyone wants, I have an
exceedingly fast singly-linked list sorting macro kicking around...

Similarly horrible problems apply to e.g. squid starting up, and
updatedb, makewhatis etc. They scan a huge number of directories or
files, and the disk makes a lot of seeking noises for quite a long time.

That might be helped (maybe a lot) if readdir returned directory entries
sorted by disk I/O order (for the inodes perhaps, the data if the inodes
are cached?, it's difficult to say what is the best order).

-- Jamie

-
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.089 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site