Making harddrive go to sleep and never wake up

[xiando]

I have a brother who likes to use Windows the few times he visits. I have a harddrive just for Windows. It's also got a few other Linux distros on it. I _never_ use or need to use this drive while using Gentoo Linux. I would like to make this harddrive go to sleep and never wake up.

If I do hdparm -y /dev/hdb then it goes 30 seconds and the drive wakes up again.

I would like to figure out what is waking this harddrive up and make it stop. I suspect udev may be the cause and tried to make a file called 81-hide-harddrives.rules with this:

# Try to see if UDISKS_IGNORE helps
# /dev/sdb1: UUID="1CA407EBA407C66C" TYPE="ntfs"
# /dev/sdb2: UUID="026bc529-48ce-40df-9bad-443c10e3ffcd" TYPE="ext4"
# /dev/sdb3: UUID="5ef175bd-1b1b-44a7-95d5-4e3e696e9016" TYPE="ext4"
# /dev/sdb4: LABEL="rootfs" UUID="dcea4dd5-8902-4c33-a990-6a297dce11b4" TYPE="ext4"

ENV{ID_FS_UUID}=="1CA407EBA407C66C", ENV{UDISKS_IGNORE}:="1"
ENV{ID_FS_UUID}=="026bc529-48ce-40df-9bad-443c10e3ffcd", ENV{UDISKS_IGNORE}:="1"
ENV{ID_FS_UUID}=="5ef175bd-1b1b-44a7-95d5-4e3e696e9016", ENV{UDISKS_IGNORE}:="1"
ENV{ID_FS_UUID}=="dcea4dd5-8902-4c33-a990-6a297dce11b4", ENV{UDISKS_IGNORE}:="1"

but the harddrive still wakes up almost immmediately after I ask it to go to sleep.

Please help me figure out wtf is waking this drive up and how to make it stop. I'd rather not have to upen the box and unplug it between my brothers visits.

This drive is NOT listed in fstab. There should be no reason for it to be woken up all the time. I can provide any info requested or run whatever commands people feel will help with this.

[lost+found]

I guess the culprit is not udev but udisks. I noticed the same ghost spin ups, until I ripped off all *kit and u* stuff (except eudev) from KDE. It interferes with hdparm (and smartd, and probably more). I never found a solution to let hdparm and udisks play nicely together though.

[PaulBredbury]

make this harddrive go to sleep and never wake up.

Options:

Code: Select all

hdparm -Y /dev/hdback > /dev/null

Code: Select all

sdparm -C stop /dev/hdback

Where /dev/hdback is a symlink set via a udev rule - must more reliable than relying on e.g. sda, sdb.

[aCOSwt]

I guess the culprit is not udev but udisks.

My guess is that the culprit is not udisks but upower.
I use kde-4.9.5 with the kdelibs emerged USE=+udisks -upower, get 2 disks put into standby at system startup and never noticed any spurious wakeup.

[lost+found]

...and probably more...

U*thing also resets the drive acoustic setting on KDE login, after /etc/init.d/hdparm has run.

Another guess... maybe the SMART feature is set, and the drive is performing tests on it's own (factory defaults?). On big drives that can take hours if not split in parts. At least the drive may spin up.

[xiando]

I guess the culprit is not udev but udisks. I noticed the same ghost spin ups, until I ripped off all *kit and u* stuff (except eudev) from KDE. It interferes with hdparm (and smartd, and probably more). I never found a solution to let hdparm and udisks play nicely together though.

I'm using XFCE4.

Code: Select all

hdparm -Y /dev/hdback > /dev/null

Where /dev/hdback is a symlink set via a udev rule - must more reliable than relying on e.g. sda, sdb.

Well I don't see how a symlink would make a difference, but how would I set the symlink using udev rule?

Also, hdparm -Y gives no different result than hdparm -y: Something wakes the drive up again almost immediately.

...and probably more...

Another guess... maybe the SMART feature is set, and the drive is performing tests on it's own (factory defaults?). On big drives that can take hours if not split in parts. At least the drive may spin up.

It's a very old IDE drive. As said, I don't use it myself so I don't care that it is old and slow. I don't run smartd, so that's not it.

[xiando]

I got tired of trying to figure this out. opened the box, disconnected the drive. atleast that makes it permanently stay off.

[lost+found]

... I don't run smartd, ...

The drive's firmware does the testing. Smartd is optional. I remember u*thing had a file that looked like a list with drive specifications, and if it was SMART capable or not. It may turn it on by default. Still guessing though. To be sure, and just for fun, you can read the logs and settings on the drive:

Code: Select all

# emerge smartmontools
# smartctl -a /dev/sdb

Edit: Sorry, that list I mentioned is from smartmontools. I saw SMART options in the u*thing manuals...

[PaulBredbury]

Well I don't see how a symlink would make a difference, but how would I set the symlink using udev rule?

Example: If I boot kernel 3.9 with my BlackBerry phone connected via USB, the phone is /dev/sda

Just google for tons of example udev rules - here's one.

I use, for secondary drive:

Code: Select all

ACTION=="add", KERNEL=="sd*", ENV{ID_SERIAL_SHORT}=="WD-WXblahblah", SYMLINK+="hdback%n"

And a little trick in an initscript, to identify the root drive:

Code: Select all

if [[ -e /dev/disk/by-id/wwn-0x5001blah ]] ; then
    ln -sfn disk/by-id/wwn-0x5001blah /dev/hdroot
fi