I have an Athlon 800 running 2.4.1 with two IDE hard drives, hda and hdc. hda has the OS on it, hdc is currently blank and unused. Today I had a bad sector error on hdc so I decided to wipe it properly with the following: for n in /dev/hdc? ; do cat /dev/zero > $n ; done When running this I ran top in another session and noticed the cat process taking 30% CPU time, this is what I expected as the version of cat on that system uses 1K buffers (4K buffers require half the CPU time according to my last tests of the issue). Then I decided to run sync, I expected it to sync all buffers in memory (most of the 256M of RAM in the machine should have been write-back cache buffers by that time so it should take less than 10 seconds, the drive is a reasonably fast ATA66 drive - see http://www.coker.com.au/~russell/hardware/46g.png for a graph of the drive's performance characteristics). Instead sync appears to want to keep going until there are no buffers left (IE when all 46G of data have been written). Is it supposed to be this way? I can imagine situations where sync could run for weeks/months/years without completing! Then I looked at the top output and it reported that sync was in state "RW" and using >60% CPU (not in state "D" as I expected). Non-kernel processes that are not in state "D" are supposed to be killable, so I tried giving it a "kill -9" which had no affect. So the process seems to be state "D" after all. This raises the following questions: Is this operation considered correct behaviour of 2.4.1 kernels? Or have I discovered a bug? Is this a new feature for 2.4.x that processes that are in a disk IO state will report CPU usage and not report as being in state "D"? If so how do I recognise such processes? Is it a known bug that sync can run virtually forever? -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
