sync in strange state in 2.4.1

From: Russell Coker (
Date: Wed Feb 07 2001 - 04:31:24 EST

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 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

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

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?

--     Bonnie++ hard drive benchmark       Postal SMTP/POP benchmark Projects I am working on     My home page
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Feb 07 2001 - 21:00:26 EST