I would expect cat /dev/sdd >/dev/null to give approximately the same amount of data each second if the disk does nothing else.

But on this USB disk I see:

Device       rkB/s     wkB/s  %util
sdf         628.39      0.00   2.12
sdf       29696.00      0.00 100.40
sdf       21368.00      0.00  72.40
sdf           0.00      0.00   0.00
sdf       19208.00      0.00  65.20
sdf       29184.00      0.00  99.60
sdf       13952.00      0.00  47.20
sdf           0.00      0.00   0.00
sdf       27264.00      0.00  92.80
sdf       29312.00      0.00  99.60
sdf        6016.00      0.00  20.00
sdf        5112.00      0.00  16.80
sdf       29824.00      0.00  99.20
sdf       27272.00      0.00  92.80
sdf           0.00      0.00   0.00
sdf       13560.00      0.00  46.00
sdf       29192.00      0.00  99.60
sdf       19456.00      0.00  66.40
sdf           0.00      0.00   0.00
sdf       21888.00      0.00  74.40
sdf       29568.00      0.00  99.60
sdf       11008.00      0.00  36.80
sdf         760.00      0.00   2.80
sdf       29448.00      0.00  99.60
sdf       29816.00      0.00  99.20
sdf        2432.00      0.00   8.40
sdf        8072.00      0.00  28.80
sdf       30208.00      0.00 100.40
sdf       24459.41      0.00  81.98
sdf           0.00      0.00   0.00
sdf       16768.00      0.00  56.40
sdf       29440.00      0.00  98.80
sdf       17536.00      0.00  58.40

If I move the USB disk to another system I see the same behaviour. When it pauses it make the sound as if it is seeking ("drrrrr") followed by a short break and another ("drrrrr").

Why? And how can I make it stop?

  • 1
    Did you mean cat /dev/sdf?
    – Jeff Schaller
    May 13, 2020 at 13:26

2 Answers 2


How is the external drive connected and which type of disk is it?

I have several 2.5 inch external USB hard disk drives which click if there isn't enough power available from the USB port they are connected to. Some operations work, while others fail – and the drive usually starts to make click sounds. Maybe the long S.M.A.R.T. self test triggers something that makes it actually use less power (like delayed heads motor action)?

But it's all a big "maybe" really.

I once, but this is a very very long time ago, had two very similar SCSI drives from the same vendor. One of them always worked fine. The other failed reproducibly after a fixed time period in idle (no I/O for some time, just spinnig). The symptom then was that I/O completely stalled. Every read or write would fail and only a restart solved the stalled I/O. My personal "fix" was to write a simple shell script that would create a temporary file, put some ramdom data in it and delete it again, and made a cron job run it every 15 minutes. This solved the problem for me (the drive wouldn't go into "idle" for this long, so it would not stall completely), but it really only worked around the symptom, because to this day I still don't know where the original fault actually came from in the first place. I found no differences for the two drives (other than both were slightly different models from the same series). Also using hdparm (I think actually it was sdparm for SCSI drives) they were identical as far as I could tell. Even switching the connectors (one of them had the SCSI terminator attached) and the SCSI IDs didn't change anything.

Long story short: I don't know. You may also consider the possibility that the drive's controller is simply malfunctioning. S.M.A.R.T. doesn't always reveal faulty hardware.

  • It is clear that the drive is not completely dead: Reading the entire disk completes without error. But I just tested writing: It will only accept 900 KB/s. That is by no means normal, so I will regard this as your last observation: The drive's controller is malfunctioning. I even tried taking the drive out of its USB case and connect it with a known good USB-sata converter and got the same result. This means the drive will be fine for WSRF (write slowly, read fast) data (e.g. a logfile), but not for data that needs to be written fast (and definitely not for production data).
    – Ole Tange
    May 13, 2020 at 16:21
  • Yes, it looks like it. And such a drive is by no means reliable anymore, it could fail at any moment, so do not use it for anything "important"... ;-)
    – luttztfz
    May 13, 2020 at 16:54

It it unclear what causes it. But it stops if I run:

sudo smartctl -t long /dev/sdd

The test does not have to complete: The very second the test starts, I get (as expected):

Device       rkB/s     wkB/s  %util
sdd       36864.00      0.00 100.00
sdd       37376.00      0.00  99.60
sdd       37752.00      0.00  99.60
sdd       37256.00      0.00  99.60
sdd       37496.00      0.00  98.80
sdd       37512.00      0.00 100.00
sdd       37752.00      0.00 100.40
sdd       38912.00      0.00 100.00
sdd       37888.00      0.00  98.80
sdd       38024.00      0.00  99.20
  • Sounds like it's some power management feature (in the USB enclosure or disk firmware) putting the drive to sleep aggressively. Try disabling various autosuspend timers using hdparm if supported.
    – TooTea
    May 13, 2020 at 12:59
  • Is this supposed to answer your question(?) It belongs to the question's side IMHO. May 13, 2020 at 13:00
  • @LinuxSecurityFreak it seems to me that it has increased the %util, which was performing poorly in the question. "Unclear what causes it" leaves open the "why?" part of the question, but the smartctl command appears to answer the "how can I make it stop?" question.
    – Jeff Schaller
    May 13, 2020 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .