Question on shredding a terebyte drive
Cameron Simpson
cs at zip.com.au
Thu Sep 3 05:16:20 UTC 2009
On 02Sep2009 17:07, Rick Stevens <ricks at nerd.com> wrote:
| Dean S. Messing wrote:
| > 4) I don't know if the fact that the process runing at 100% of one CPU
| > means it is compute bound. Looking at the disk I/O meter in
| > gkrellm I see bursts of writes followed by intervals of no
| > transfer. I know that magnetic reorientation requires some time
| > to "set" and that may be why the delays are there. Or it may be
| > compute bound.
|
| Run "top" and you may find that the shred process is in a "D" state a
| lot of the time. That means it's in an I/O wait state, waiting on the
| drive to complete some operation.
During this time it should be consuming _no_ CPU.
| A "D" state can suck up a lot of CPU.
It should not. Historically, processes in D state have been counted
towards the load average, because D states are normally very brief and
the process will be back on the run queue Real Soon Now.
So while D state processes run up your load average, purely for purposes
of having that number indicated better how "busy" your system is, a
process in D state does _not_ suck up CPU unless it's flickering in and
out of D state so fast that the OS housekeeping becomes expensive.
Cheers,
--
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
This is not a bug. It's just the way it works, and makes perfect sense.
- Tom Christiansen <tchrist at jhereg.perl.com>
I like that line. I hope my boss falls for it.
- Chaim Frenkel <chaimf at cris.com>
More information about the fedora-list
mailing list