Messages in this thread | | | Date | Fri, 13 Nov 1998 09:08:11 +0000 | From | Jamie Lokier <> | Subject | Re: 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/
| |