Derek Taubert wrote:
>From iostat -k 10:
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 2428.64 2422.46 667.66 24273 6690
sda 36.84 23.72 1667.87 237 16662
sda 2440.60 2434.90 616.00 24349 6160
The read rate is curious (should be 0)...
Top shows 1% user, 3% system, 93% wait.
It seems some kind of read IO is in progress. Can you repeat the test
on an unused/idle (iostat -k 10 shows all zeros...) drive? The above
result actually looks good if you consider both read and write sides.
I think that 3MBytes/sec total for a drive that can read at 50MBytes/sec
on the same system is quite bad, especially since we're talking about
a linear write test.
True, I was referring to both reads and writes. If both are in progress
and they're apart on disk, the result looks normal.
The result doesn't seem to indicate any problem in libata or any storage
related kernel subsystem. I would track down the reader first.
This drive has only been partitioned; there is no filesystem on it. So,
it certainly isn't mounted anywhere. There honestly isn't _anything_
other than the dd going on to sda1, and that's the only partition on
sda.
Hmmm...
2) hdparm -C for all 4 drives always shows "drive state is: standby"
even when I'm certain that the drives are active.
hdparm -C says the same thing for my drive. I think it's safe to
ignore. Hmmm... it needs to be tracked down. Maybe some problem in
HDIO ioctl implementation in libata.
It's a "nice to have" for using smartd. ie: don't spin the drives up to
poll the failure attributes, but they should be checked if the drive's
already active.
I don't really understand what you mean. Can you elaborate?
I'd really like some assistance debugging the write performance issue.
The "hdparm -C" issue would be gravy...
Please track down the reader.
Before running dd (fuser -v /dev/sda1 shows nothing):
[--snip--]
Can you try 'dd if=/dev/zero of=/dev/sdX bs=4M count=1'?
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
