What do you know, edit a diary entry and the date changes!
After having studied many different types of I/O
schedulers,
I've come to the conclusion that simple ascending request
sorting is the most optimal for most circumstances. It has
decent runtime for insertions and good average seek time.
Combine that with some stuff for limiting starvation and you
got yourself a decent disk elevator - and behold - this is
what we have in current 2.3. After having tried the BSD
style elevator, I implemented one that always returns the
request closest to the one the drive is servicing right now.
In terms of runtime it is expensive and the gains over the
simple ascending sort was just not worth it. So my work yet
again degenerates into just getting good performance with
tweaking elevator defaults, how boring. Well almost, I want
to modularise the current elevator so that it is possible to
select which one you want. For IDE drives the current one is
pretty good, for SCSI it does some work that is really
unneeded but does not harm performance (well, we do take a
small hit because of the unneeded work, but that is
neglible). For intelligent devices (highend SCSI HBA/disks,
I2O) that claim to do their own elevating, we shouldn't need
to do much.
At least one person is having problems caused by
changing
the default mode page size in ide-cd to the standard
specified size. So it looks like we are reverting to old
behaviour again. The only known case (to me) that fails with
the smaller mode page is the ACER 50 drive, not enough to
justify changing the old default.
I want to get a new workstation PC. Contemplating
getting a K7, but I'm not sure I really need it. Oh well.