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.