Can you reproduce the situation when using
hdparm --direct -t device
You should always
use the --direct
option when accessing devices, because it avoids the page cache.
You can also see if
sudo bash -c 'sync ; echo 3 >/proc/sys/vm/drop_caches ; sync'
affects your timings. (It should not affect --direct
timings though, because that should completely bypass the caches anyway.) This command is safe to run at any time; it just flushes all caches and unwritten changes to disk, then clears the caches. It will never discard unwritten changes.
You should make sure you have smartmontools
installed, and check the SMART data:
Running a self-test ( -t short
or -t long
), waiting (without rebooting -- otherwise the disk can be used normally) usually quite some time (you can use smartctl -a device
to see the progress), and then an offline test ( -t offline
) to update all offline attributes, and rerunning smartctl -a device
will tell you more about the physical state of your storage device. Uh, assuming it does have SMART support.
Finally, you could install and run iotop
before testing, to really see if you have background processes (like indexing or other housekeeping stuff, that most Linux distributions do use) accessing storage, just before running hdparm --direct -t
. (Personally, I find hdparm -T
to be quite worthless in practice.)