Re: pre-31-7 does badblocks better than -6
Rogier Wolff (R.E.Wolff@BitWizard.nl)
Wed, 20 Aug 1997 07:41:57 +0200 (MET DST)
Doug Ledford wrote:
>
> On Mon, 18 Aug 1997, Pete Harlan wrote:
>
> > FYI,
> >
> > pre-patch-2.0.31-7 had no problems doing badblocks, while
> > pre-patch-2.0.31-6 produced "Couldn't get a free page" and was
> > unreachable over the network (no response to pings) for 10-20 sec.
> >
> > Interactive performance was sluggish throughout badblocks run with
> > either kernel.
>
> 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.
Roger.