[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.020 / U:95.360 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site