Disk standby timer is broken

[Phillip Susi]

udisks' / gnome-disk-utility's support for the drive standby timer is broken. If the standby timer is set to at least 10 minutes ( which is the minimum on many drives ), every 10 minutes udisks tries to update the smart status of the drive, which resets the standby timer.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Eder Bastos (riskbreaker927)]

With the related fix installed from psusi's PPA installed, my hard drive remains active/idle regardless of what timeout is set in gnome-disks, although when I log into Unity after a reboot, my hard drive audibly spins down and then immediately back up. I also get an error report from the udisks2 package, which has been submitted.

[Phillip Susi (psusi)]

Does it work if you use hdparm -S to set the standby timer, or if you use hdparm -y to force standby, does the disk stay in standby for long?

[Martin Pitt (pitti)]

> when I log into Unity after a reboot, my hard drive audibly spins down and then immediately back up.

That sounds consistent with my objection in https://code.launchpad.net/~psusi/ubuntu/trusty/udisks2/fix-standby/+merge/206951 and on devkit-devel@. I don't think that E2h is the command that we actually want for setting the standby timeout.

[Phillip Susi (psusi)]

You're right.. that wasn't it... I'll have to keep digging.

[Phillip Susi (psusi)]

Ok, so the problem is that udisks tries to update the drive's SMART status every 10 minutes. This will wake the drive and reset its standby timer. It does check to see if the drive is already asleep first, and skips the check if it is, but that doesn't help if the standby timer is > 10 minutes. It also seems that my Western Digital drives also refuse to standby in under 10 minutes; setting it to 5 minutes still makes it wait just over 10. This is why my patch to switch to the STANDBY command appeared to fix it at first: by immediately putting the drive into standby, it made the SMART updates be skipped.

You can verify this by killing the udisksd process and you can see the drive does spin down after just over 10 minutes.

The proper fix for this is to add another check to see if there has been any IO since the last SMART update according to the kernel performance counters, and if not, skip the update.

[Eder Bastos (riskbreaker927)]

In theory then, could a short-term workaround be to disable SMART on the drive in gnome-disks?

[Phillip Susi (psusi)]

I didn't think it had an option to do that.

[Eder Bastos (riskbreaker927)]

It does: the option is available at the top right of the dialog that shows up when you press Ctrl+S while highlighting the drive in question.

Also, confirming that disabling SMART does allow my Western Digital drive to sleep, though I haven't timed how long it takes for that to occur.

[john reid (reidjr)]

Can confirm that the SMART polling by udisk2 every 10 mins appears to reset the sleep timer on all of my disks: So all disks are kept awake by SMART polling where sleep timer > 10 mins. As previously stated later WD disks have a minimum sleep timer of 10 mins ( hdparm -S120 /dev/sdx) defaults to 10 mins for any value of S below 120. Therefore you need to choose betwen SMART monitoring and sleep.

Device Model: SAMSUNG HD154UI
Device Model: SAMSUNG HD154UI
Device Model: SAMSUNG HD204UI
Device Model: ST2000DL003-9VT166
Device Model: WDC WD40EZRX-00SPEB0

|Polling does not WAKE disks, so setting sleeptimer to less than 10 mins allows all above disks apart from WD to spin down. Following successful spindown they stay down. 12.04 seems to rely on smartmontools and smartd, and has a default of 30mins, so I had not seen this till upgrade to 14.04.

[john reid (reidjr)]

--- udiskslinuxprovider.c 2014-05-02 13:54:46.826781083 +0100
+++ udiskslinuxprovider.c.30minpoll 2014-05-02 13:55:54.034178153 +0100
@@ -465,8 +465,8 @@
   g_list_free_full (udisks_devices, g_object_unref);
   udisks_info ("Initialization complete");

- /* schedule housekeeping for every 10 minutes */
- provider->housekeeping_timeout = g_timeout_add_seconds (10*60,
+ /* schedule housekeeping for every 30 minutes */
+ provider->housekeeping_timeout = g_timeout_add_seconds (30*60,
                                                           on_housekeeping_timeout,
                                                           provider);
   /* ... and also do an initial run */

Changes regular polling to 30mins, allowing sensible spindown times on WD

[Rocko (rockorequin)]

I confirm John Reid's patch to udisks2 allows my WDC WD40EZRX-00SPEB0 to spindown into standby after 10 minutes (Ubuntu 14.04, udisks-udisks2-2.1.3. The patch actually failed so I applied it manually).

But exactly at the 30 minute mark it spins back up into idle mode, even though gnome-disks says that the last check was 30 minutes ago. So it appears that polling _is_ in this case waking up the drive and I need to do more than just assign a sane polling interval to udisks. Any idea why this would be?

[Rocko (rockorequin)]

Following on from my previous comment, the drive is most definitely spun up again by udisks2 polling at 30 minutes, even though udisks2 doesn't read the SMART data at this point. I recompiled udisks2 to use a far more reasonable polling time of 24 hours and now the drive stays spun down like it should.

[john reid (reidjr)]

Rocko,

Slightly OT

I see a variety of behaviour., based on the disks.

On 14.04 with the 30min polling patch: If you set the spindown to 15 mins and poll at 30, all of my disks spin down and stay down ( see list above).

 If you set the spindown to 5 and polling to 10, I have problems with the WD not being able to be set to less than the polling frequency ( as discussed original problem).

However I also see problems when poilling is within 1-3 min or so of the spindown on the Seagate drive. I havnt tried to work out exactly whats happening, or exact timings . But the seagate doesnt seem to cache anything hdparm doese either. so hdparm -C will wake it.
In summary, The 3 samsung drives stay down, but the seagate spins up if polled too soon after its spindown.

[Rocko (rockorequin)]

John, just to confirm, do you find the WD acts like the Samsung drives? It looks like I have exactly the same one, the WDC WD40EZRX-00SPEB0, and that's the one that always wakes up whenever it is polled (and I tested this on 30 minute poll intervals, which means it had been spun down 20 minutes but still woke up). But I think from what you said that yours doesn't wake up when it's polled, so long as it is given more than ten minutes to spin down between polls.

Apart from setting a saner default polling interval in udisks2, perhaps it would be a good solution to have a configuration setting in gnome-disks (or at least in udisks2's conf file) that allows you to set the polling interval. I don't mind my drive waking up once a day for a check, but every 30 minutes just seems silly.

[Phillip Susi (psusi)]

If hdparm -C wakes the drive, then the drive is broken.

[Martin Pitt (pitti)]

I reviewed and cleaned up Phillip's patches and committed them upstream, thanks!

http://cgit.freedesktop.org/udisks/commit/?id=10fb36a
http://cgit.freedesktop.org/udisks/commit/?id=65c901f

[Martin Pitt (pitti)]

Reverted upstream, as David Zeuthen objected to this. Quoting:

1. Checking if a disk is asleep does not wake up the disk (unless its
firmware is broken).
2. It's not atypical to have disks without any IO for _days_. We still
want to check SMART status for disks in this case.

If people have disks with broken firmware there are other ways to have
udisks not read their SMART status.

[Rocko (rockorequin)]

What is the recommended way to stop udisks from reading the disk's SMART status? I tried turning it off with gnome-disks several weeks ago but this setting didn't persist across reboots.

[Phillip Susi (psusi)]

udisks' / gnome-disk-utility's support for the drive standby timer is broken. If the standby timer is set to at least 10 minutes ( which is the minimum on many drives ), every 10 minutes udisks tries to update the smart status of the drive, which resets the standby timer.

Reported in Ubuntu: https://bugs.launchpad.net/bugs/1281588

As David Zuthern noted in a private message, my initial patches to fix this also prevent ever updating smart data on disks that are never used, even if they do not have a standby timer enabled. I will fix them to be contingent on a standby timer and post updated patches here soon.

[Phillip Susi (psusi)]

I'm updating the patches to address David's concern that it stops SMART updates on disks without the standby timer enabled that are never accessed. Hopefully get this sorted in a few days.

[Phillip Susi (psusi)]

Created attachment 101544
0001-Fix-standby-timers.patch

Ok, here is an updated version that bypasses the no io skip check when the standby timer has not been enabled. I verified that it keeps reading the smart stats on an idle drive when you disable the standby timer in gnome-disks.

[Zeuthen (zeuthen)]

I'll take a look.

[Zeuthen (zeuthen)]

(Sorry for being slow. Will post feedback soon.)

[Phillip Susi (psusi)]

Bump...

If you don't have time to review/test the patch yourself, are you satisfied with my description of the changes to the point that you would not have a problem with Martin Pitt reviewing and pushing it now?

[Phillip Susi (psusi)]

Hi David, it has now been six months of waiting for an ACK ;)

[Martin Pitt (pitti)]

Thanks for the updated patch! I looks good to me, I pushed it with some minor cleanups (variable names, PATH_MAX).

[Martin Pitt (pitti)]

Fix committed upstream: http://cgit.freedesktop.org/udisks/commit/?id=46da39c15f3

[Launchpad Janitor (janitor)]

This bug was fixed in the package udisks2 - 2.1.4-1

---------------
udisks2 (2.1.4-1) experimental; urgency=medium

  * New upstream bug fix release.
    - Avoids waking up disks from standby through SMART updates.
      (LP: #1281588)
    - Drop 00git_test_fixes.patch and libsystemd.patch, included upstream.
  * Bump Standards-Version to 3.9.6 (no changes necessary).
  * Add missing python3-dbus autopkgtest dependency.
  * integration-test: Skip double mount check for NTFS. Patch cherry-picked
    from upstream git.

 -- Martin Pitt <email address hidden> Thu, 18 Dec 2014 14:07:40 +0100

[Ian McMichael (ian-sigma-uk)]

Is there any chance of a backport to 14.04 LTS for this patch?

[Rocko (rockorequin)]

Or of a backport to 14.10? It's currently only available for 15.04.

[Rocko (rockorequin)]

udisks2 2.1.4-1git3 doesn't fix the problem for me - the drive in question never goes into standby. If I increase the housekeeping to 24 hours (as per comment #11), the drive goes to sleep as normal.

[partyzan543 (partyzan543)]

Ебаные погромисты сука малолетние, какого хуя ваше ебаное поделие постоянно дергает винт? Какого хуя Вашей говносистеме там надо пока я не попросил?

Solved is aptitude purge udisks2.

Проще монтировать диски руками, чем слушать как эта ебань постоянно головками шурудит

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[svasiljev (svasiljev)]

Latest Xenial with udisks2 2.1.7-1ubuntu1 is affected by this bug - service resets standby timer of external WD MyBook.

[Paul Cullum (paul-cullum)]

This behaviour still seems to be present in 17.04. I have a secondary drive (ST3500418AS) that is isn't mounted and should remain asleep. It doesn't go to sleep unless I force it with "hdparm -Y /dev/sdb". There is something that happens every 10 minutes that will wake up the drive.

I think there is something wrong with libatasmart because just checking the state seems to change the state (Heisenberg?). Running "hdparm -C /dev/sdb" will actually wake the drive up.

[Phillip Susi (psusi)]

hdparm -Y puts the drive to SLEEP, not STANDBY. In SLEEP mode, no commands at all, including hdparm -C can be issued, so even trying that causes it to be woken up. Use hdparm -y instead.

I had tried patching the kernel to emulate the check power status command in software when the kernel knows it has ordered the drive to SLEEP to avoid this, but I don't think the patch was accepted upstream and I kind of forgot about it.

Also try killing your udisks task and see if that allows the drive to auto standby.

[Mohammad Kazemi (mokazemi)]

I'm experiencing this bug on Ubuntu 20.04.1
It seems something is trying to access my disk, exactly every 10 minutes. I reported it as a new bug +bug 1899361