<SNIP>
-> > FWIW, people should probably be aware that almost no system in the world
-> > will *not* be sluggish suring a badblocks run simply because the drive bus
-> > is being nailed so hard that interactive work has to wait its turn in line
-> > to get drive requests out the queue (which will be a rather large queue
-> > when doing a badblocks -w).
->
-> When, just like with CPU scheduling, the kernel would prefer giving a
-> slot to an interactive process instead of the disk-hogging process, it
-> would be less of a problem.
->
-> This is why deep tagged-queues are a bad idea.
->
-> When implemented correctly, as soon as there is contention for a
-> resource like a disk, the kernel should prevent the process that is
-> monopolizing the resource from using all the bandwidth. This could be
-> accomplished by inserting an extra delay on, in this case, writing
-> another block. Yes, this will mean that the disk starts to be idle
-> some of the time. This is exactly what you want. My guess is that this
-> algorithm should try to keep the disk idle for about 10% of the time.
On interactive systems this is undoubtedly true, but what about systems
dedicated to special purposes, like CD burning. Sacrificing 10% of the source
disk bandwidth is not a problem, but you cannot sacrifice 10% of your CD
writer bandwidth or you lose the CD every time. There are probaly other
applications where this applies too.
In other words, such a feature should preferably be configurable on a per
device basis.
-----------------------------------------------
Hugo Van den Berg - hbe@cypres.nl
hugo.vandenberg@net.hcc.nl
Tel: +31-30-6025400 Fax: +31-30-6050799
-----------------------------------------------