Messages in this thread | | | Subject | Re: pre-31-7 does badblocks better than -6 | Date | Wed, 20 Aug 1997 07:41:57 +0200 (MET DST) | From | (Rogier Wolff) |
| |
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.
| |