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/