[lkml]   [1997]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: pre-31-7 does badblocks better than -6
On Wed, 20 Aug 1997, Rogier Wolff wrote:

-> > 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 -
Tel: +31-30-6025400 Fax: +31-30-6050799

 \ /
  Last update: 2005-03-22 13:40    [W:0.039 / U:0.588 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site