3

I have a SATA docking station (actually part of my PC case) and use it frequently. One of my SATA disks is a WD Caviar SE16 WD2500, a 250GB 7200 RPM SATA3 hard drive. The docking station is connected to a SATA port marked as external in the UEFI.

When I plug it in and get whatever I want, I'll issue sudo hdparm -Y /dev/sdd on my terminal and it immediately goes to sleep mode.

Only, after a random amount of time (ranging from 2 minutes to a couple of hours), it comes back up.

My other drives don't exhibit this behavior and stay in sleep mode until I try to access files from them again.

I'm positive I'm not accessing the drive, nor is any userspace process in my system.

How do I diagnose this, and more importantly, how do I make sure it stays asleep?

4

Well, there can be uncountable reasons for drives to wake up.

For example, I had this issue with my new WD80EZAZ drives. Turns out a simple smartctl -a wakes them up (just query SMART data, not even running any tests). This was not the case with my old WD20EARS drives, you could query them while not spinning just fine. So I had to add -n standby to my smartd.conf to ignore the drives while in standby.

Other popular reasons are filesystems, for example ext4 with lazy init might periodically access the drive. You can set /proc/sys/vm/block_dump or use other tools to find out, or use mount -o loop,ro for a read-only mount to rule out periodic (write) access by the filesystem itself.

If you have an invalid /etc/fstab entry, specifying an UUID that does not exist, this can also lead to all drives being scanned for the missing UUID, waking everything up in the process. It's why you sometimes see people use /dev/disk/by-uuid/the-thing instead of UUID=the-thing as that prevents additional scanning: the by-uuid symlink either exists or it doesn't, unlike findfs it does not traverse all drives every single time.

Also check dmesg for regular bus resets or other such issues. A wonky cable can also cause odd side effects.

Unfortunately there's no easy answer to this problem and it can be difficult to pinpoint the exact cause.

1
  • thanks for that /proc/sys/vm/block_dump tipp, it's a livesaver when debugging hdd wakeups!
    – bernstein
    Apr 17 '20 at 1:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.