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
