Source
r/linuxquestions•
CodenameLambda

Excessive disk sleep

On my main Arch system some applications (especially ldconfig when running pacman, but now Firefox has begun to sometimes idly wait and so has nvim) just freeze for half a minute or so and are displayed by htop as having the "disk sleep" state.

It getting worse over time and me not having seen any issue like this elsewhere makes me believe that this might be a hardware issue (I've run this system for quite some time, including some disk intensive workloads), but I'm not entirely sure. (I don't have any data on there that isn't either properly backed up, elsewhere or just installed software, so I don't really fear any data loss either)

If anyone has any clue what exactly might be happening, any help would be appreciated. Thanks!

EDIT: I should clarify that my main drive is an SSD. iotop often shows jdb2/sdb1-8 being semi-active, and sometimes reaching 99% IO for some reason, which I'm currently further investigating. Thanks for all the help so far!

EDIT: Turns out jdb2 always does IO after disk writes happen, while the original application that does the writes is not listed as doing actual IO, which makes sense. I assume aggressive caching could potentially be the culprit here, esp. considering that I have quite a lot of RAM for Linux to cache such operations before actually doing them.

Posted Sep 2, 2020, 11:58 PM UTC · edited

57
edman007•

What you're seeing is just slow drive access. Ordinarily I'd say it can be caused by having high amounts of writes to a disk, syncing the drive can freeze the io in that situation.

I'd check your actual IO, if it's low I'd be very concerned about a failing drive, so check it's SMART status with smartctl

2
CodenameLambdaOP•

That makes it sound like it could also be a configuration issue, I'll have to check that (this system was set up with Apricity back when that still existed, I don't know what defaults they used).

smartctl doesn't show anything that would indicate disk failure, so that's at least good.

1
is_reddit_useful•

When hard drives encounter read errors, often they retry for a long time, causing such freezes. An increasing amount of such freezes would mean the drive is deteriorating. As long as the reads eventually succeed without timing out, this can happen without seeing actual errors, though some SMART attributes might provide clues.

Another thing that can cause freezes is heavy disk activity even when the drive is healthy. That happens most frequently if running out of RAM and swapping a lot.

The most obvious difference between the two is the way the drive sounds. Healthy heavy activity has lots of random seeking sounds, while long retries can be silent or just have a repetitive ticking sound or something like that. Also, with healthy heavy activity there is typically at least a bit of flicker of the drive activity light, while during long retries the light is lit continuously.

2
CodenameLambdaOP•

It's an SSD (which admittedly I should've clarified in the post), so there are no sounds to speak of.

Thanks anyway!

2
is_reddit_useful•

SSDs might cause long delays when they're failing too, but they're more difficult to diagnose.

1
glesialo•

Your post reminded me of a problem I had many years ago. Here are my notes about it:

*******************************************
Head parking in Western Digital Green HDs
**********************

Western Digital Green hard drives have a serious issue when used in Linux as a main drive or as a NAS drive.
The problem is due to a feature called IntelliPark. Which parks the heads on the drive after 8secs of drive inactivity.
Many Linux installations write to the file system a few times a minute in the background (eg. writing logs). As a result,
there may be 100 or more load cycles per hour, and the load cycle rating (the drives are good for 300,000 Load/unload cycles)
may be exceeded in less than a year. This problem also makes the drives very unresponsive and makes your system feel
slow as the heads need to be unparked when you try and load something.

Check Load_Cycle_Count (as root):
  smartctl -A /dev/sda | grep "^193"
    193 Load_Cycle_Count        0x0032   088   088   000    Old_age   Always       -       337763
      If the Load cycle count exceeds a few thousand, you're affected by the idle3 timer problem.
      (337763: Rather late than never :-( )

To solve the problem:
  Install (with Synaptic) idle3-tools
  Check timer setting:
    idle3ctl -g /dev/sdb
      Idle3 timer set to 80 (0x50)
        Confirms that timer is set to 8 seconds (80)
  Disable timer:
    idle3ctl -d /dev/sdb
      Idle3 timer disabled
      Please power cycle your drive off and on for the new setting to be taken into account. A reboot will not be enough!
  Power down/up system and check again:
    idle3ctl -g /dev/sdb
      Idle3 timer is disabled

*******************************************
2
CodenameLambdaOP•

My main drive is an SSD (which admittedly I should've clarified in the post), so I don't think that is related to the issue.

Thanks anyway!

2