Identifying why my mounted HDD won't sleep

[electrotwelve]

I'm a Raspberry Pi newbie and I have been experimenting for a few days now. My primary use is to use the Pi as a file server within my home network. I mounted my external HDD and setup Webmin with Samba and Netatalk for file sharing between the Pi, my Window 7 machines and my Macbook Pro.

I soon realized that my HDD would never spin down and enter sleep mode. I then installed ownCloud and the HDD not sleeping continued. I then shutdown (powered down not sleep or hibernate) machines on my network one by one to find out which machine might be keeping the drive awake. As it turns out the Macbook was the problem. I subsequently stopped the Netatalk service and bingo, the drive went to sleep. Since then I've been using ownCloud exclusively for file sharing on my network.

Here is where we come to the problem. The drive going to sleep is very erratic. At one point I power-cycled the Pi and now the drive won't sleep again. I tried Iotop to see if there any processes writing to the disk and thus preventing it from sleeping but there were none. Tried the technique of turning off all machines on my network that have ownCloud installed and still the drive wont sleep. What am I missing here? Here is how the drive is mounted in /etc/fstab:

Code: Select all

UUID="XXXXXXX"      /cloud    defaults,noatime,uid=33,gid=33,umask=007      0       0

I've also tried hdparm -B127 -S120 /dev/sda1 and here is the output I got. I believe that means hdparm is not working (?)

Code: Select all

/dev/sda1:
 setting Advanced Power Management level to 0x7f (127)
SG_IO: bad/missing sense data, sb[]:  70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 setting standby to 120 (10 minutes)
SG_IO: bad/missing sense data, sb[]:  70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 APM_level	= 127

[Heater]

I would rather that none of my drives ever went to sleep, ever.

Why is this a problem?

[asandford]

Due to the fact that both your hard drive and the onboard network (100MB/s) will be sharing the same USB2 interface then you may have to lower your expectations of using the Pi as a file server.

However, as already stated, you don't wan't it to sleep as both Win7 and Mac will access the share frequently to update the state and have decent response times (for example: would you want the drive to spin up from sleep when watching a film?)

[electrotwelve]

Well I do see the point about the drive not sleeping but the drive becomes very hot when its not sleeping. With my WD 1TB drive the wake up times are pretty fast. The last time I accessed the drive from sleep it came up in less than 2s.

Didn't know that the ethernet and usb shared the same channel. I see why a 700 MB file took more than 5 minutes to transfer.

[Heater]

electrotwelve,

Didn't know that the ethernet and usb shared the same channel. I see why a 700 MB file took more than 5 minutes to transfer.

I think you just discovered why attaching huge drives to a Pi is an exercise in futility.

[electrotwelve]

Yeah. Its still serving its purpose though. I mostly use it to share my Kicad and programming libraries between machines on the LAN and I don't have to keep carrying data on USB drives to copy updated libraries across machines. Before owncloud became the only file sharing method, I tried some media streaming and that worked pretty well without pauses or jitters.

[epoch1970]

I think the Pi as a file server is quite acceptable. It is considerably more capable than a Pogoplug which had it heyday.
I have one Pi powered and connected to an external USB switch, with 2 3TB mobile drives in tow. Works fine (and sleeps well.)
In my experience it is a bit difficult to find the cause of a non-sleeping drive, and lsof rarely helps. What I would do is observe if the behaviour is the same with network up or network down. Then try to stop services selectively and see if there is a change.

I don't know if this works on the Pi specifically but usually setting laptop-mode and possibly commit helps, for system drives. Eg

Code: Select all

$ cat /etc/sysctl.d/01-alix.conf
# Values taken from laptop-mode script.
vm.laptop_mode = 5
vm.dirty_expire_centisecs = 60000
vm.dirty_writeback_centisecs = 60000
vm.dirty_ratio = 60
vm.dirty_background_ratio = 5
# We could use 1 ?
vm.swappiness = 5
# We have noatime,commit=600 in /etc/fstab and /etc/default/grub
# And hdparm settings for the HDD

$ cat /etc/fstab | grep commit
LABEL=SYS-150415	/               ext3    noatime,errors=remount-ro,barrier,data=ordered,commit=600 0       1

$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-4.1.0-rc1-alix-serverload-11 root=UUID=b56778ec-1234-5678-9abc-ecf504e7aa9b ro console=tty0 console=ttyS0,38400n8 reboot=bios rootflags=noatime,data=ordered,barrier,commit=600 noresume selinux=0 apparmor=0 security= init=/lib/sysvinit/init

$ cat /etc/default/hdparm | sed -n '10,11p'
harddisks="/dev/sda"
hdparm_opts="-a2048 -S30 -B96"

[electrotwelve]

In my experience it is a bit difficult to find the cause of a non-sleeping drive, and lsof rarely helps.

Yep thats true. I think with ownCloud the drive sleeps well. Sometimes when it doesn't and you can't figure out why, I simply access the drive once and then close any open Explorer/Finder windows that are accessing the drive. That seems to do the trick.

[epoch1970]

Many causes, I'll dump a few:
- file indexing services if the machine is a desktop
- file servers that keep their idle connections open too long (I think the default idle tm on netatalk is 12hrs...)
- recent macs doing the darkwake/power nap thing every 15 minutes (to play nice with sleep-proxy)
- filesystems or OS committing to the HDD too frequently

I'd try using autofs (I don't know the ersatz feature available in systemd, I'm talking about the real thing, autofs v5) to dismount automatically. A dismounted drive does sleep, usually.
More radical, and useless if the drive is really needed anyway, you could have a deamon/cron watch /proc/diskstats, /proc/mounts, and decide to forcibly put to sleep the drive if it's in fact idle.

Or try with another drive/make, because firmwares are part of the equation...