Messages in this thread | | | Date | Thu, 11 Feb 1999 18:56:11 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 2.2.1, killing wantonly. |
| |
On 11 Feb 1999, Eugene Crosser wrote:
>In article <199902101407.OAA22565@mauve.demon.co.uk>, > Ian Stirling <root@mauve.demon.co.uk> writes: >> 2.2.1, on 16Mb ram. >> After an unfortunate incident, that seems fortunately not to have harmed >> my system, I wanted to check my hard drives. >> However, when I did badblocks -w /dev/xxx count>40000, the system became very >> unresponsive, (0.2-0.5 seconds for a char to be echoed on a text vc), and >> then started killing stuff, beginning with my webcache, and continuing with >> inetd, update, and after a few seconds init. >> Fortunately, a shell stayed live, so I was able to shutdown gracefully. >> Badblocks in write mode >>does: write 1024 bytes of data, lseek 1024 bytes into the file, write 1024, >> lseek 2048, ..... >> >> Happens with dma on, or off, on two seperate (quantum bigfoot) drives, X >> running or not, kernel compile running or not. > >`badblocks' program effectively kills *any* linux kernel I tried it on, >when run in write mode. Not necessarily hangs, but it becomes so slow >that you would rather reboot than wait a few days till it finishes...
It's because kflushd don't wait for I/O completation if the number of dirty buffers is high. Grep for too_many in the kernel list and you'll find some patch that will fix the bad behavior. I guess Linus will include one of the patches in 2.2.2.
Andrea Arcangeli
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |