Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sheddyian]

Summary of long rambling post : How do I make a hard disk spin down when idle under Linux, specifically Raspbian/Debian ?

Detail :

So, I thought I'd use my spare Raspberry Pi as a NAS unit, and shove one or more spare hard disks in to serve to the network, using Samba and maybe NFS or other (mostly to be used from Windows PCs, so Samba..)

So far so good, and in quite a short space of time considering my still newbieness with the Pi, I've got it running, serving out one of the SATA disks I've plugged into the USB port via a cheap ebay adaptor cable.  Disk powered from an old PC PSU, pi from it's own 5v supply at the moment.

Quick speed test, I can copy files to it at very close to 12Mb/second, which is very pleasing as my actual NAS disk enclosure unit struggles to achieve 4Mb/second.  Streaming HD video from the old NAS to another Raspberry Pi running RaspBMC is usually a dismal stuttery affair.

So, goal 1 achieved - faster throughput.

Goal 2 was to be lower power consumption.  The slow NAS unit has no facility for this, the disk spins 24/7, it's using about 30 watss all the time.

So, bung it on a Raspberry Pi (running Raspbian/Debian) that'll be simple, won't it?  Set the disk idle timer to say 30 minutes, it'll spin down and save electric.

Well, after 2 days of trying I've almost given up.  There seem to be many "solutions", and none of them seem to work for me.  Nor for many other people.  If you google for "hd spin down raspberry pi" (or similar), you'll get lots of suggestions, and many more responses saying "yes, but it doesn't work".

Come on, Microsoft have been doing this since at least Windows 95, if not earlier.   

Does anyone here know of a good/reliable/easy-for-idiots-like-me-to-understand way of getting attached hard disks to spin down when idle?

Ian

[roseway]

I've never actually got involved in disk spindown, but I think the difficulty is the number of running processes which can keep the disk alive. You have to check out these processes and stop them or inhibit them from keeping the disk alive. There isn't a one-size-fits-all solution for Linux, because Linux distros vary so much.

Sorry, I know that's no help.

[burakkucat]

Disclaimer -- I use Red Hat Enterprise Linux and not Debian.

However -- If it is just media data files that are stored on that hard disc and your R-Pi is operating from its own SD card, then you should be able to configure that hard disc to "spin down" when it is idle.

Hint -- hdparm. (Possibly man hdparm, if the manual page is installed, will be useful.)

[sheddyian]

In answer to Roseway and B*cat, the Raspberry Pi is running from it's SD card, so all system files are there.  The disks (currently only 1) are only data, so ought to be able to spin down when not being accessed over the net.

I had tried hdparm , and one of the suggested uses was this :

 

Code: [Select]

$ sudo hdparm -S1 /dev/sda1
But it gives this :

Code: [Select]

/dev/sda1:
 setting standby to 1 (5 seconds)
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Which is pretty much the same as other responses to forum posts about "how to spin down idle disks in Linux/Raspberry Pi".  Seems it works on some setups, but fails more often than works.  On mine, it fails 

Ian

(obviously, 1 second standby is not useful, but it's for testing - any variation of timing parameter (eg 30 minutes) gives the same error)

[burakkucat]

Oh.    So it might be a driver problem. 

Have you checked that the OS is fully up-to-date?

Also, it might be worth to take a look at hdparm -B value . . .

[neilius]

Shot in the dark but are you sure the USB disk is at /dev/sda1? It may be sdb or sdc depending on how many other devices are plugged in. Could try the same hdparm command but directing it toward those other device identifiers. Or the USB adaptor doesn't support that command?

[burakkucat]

Shot in the dark but are you sure the USB disk is at /dev/sda1? It may be sdb or sdc depending on how many other devices are plugged in. Could try the same hdparm command but directing it toward those other device identifiers. Or the USB adaptor doesn't support that command?

Good points. As for the first, a straightforward sudo fdisk -l would provide the information.

[sheddyian]

Thanks for the responses.

I'm confident the device is /dev/sda1, and here's what I think is the proof of that

Code: [Select]

pi@oldpi ~ $ sudo fdisk -l

Disk /dev/mmcblk0: 16.0 GB, 16012804096 bytes
4 heads, 16 sectors/track, 488672 cylinders, total 31275008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf57a

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192     2833984     1412896+   e  W95 FAT16 (LBA)
/dev/mmcblk0p2         2834432    31209471    14187520   85  Linux extended
/dev/mmcblk0p3        31209472    31275007       32768   83  Linux
/dev/mmcblk0p5         2842624     2965503       61440    c  W95 FAT32 (LBA)
/dev/mmcblk0p6         2973696    31209471    14117888   83  Linux

Disk /dev/sda: 160.0 GB, 160041885696 bytes
81 heads, 63 sectors/track, 61254 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2a7ed278

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   312581807   156289880   83  Linux
pi@oldpi ~ $

mmcblk0 is the SD card, which has a number of partitions on it as it's got the Raspberry PI "noobs" system that allows you to easily boot into a recovery mode.

/dev/sda1 is the hard disk in question.

I had a thought, and wondered if I should be using /dev/sda  not /dev/sda1 in the command.

Well, I tried

Code: [Select]

sudo hdparm -S1 /dev/sdaand got the same error as I did with /dev/sda1

It does seem that maybe the controller doesn't support it, but I'm pretty sure it spins down as expected when used under Windows (I've had this adaptor for some time and used it in a variety of ways in the past).  I intened to reconnect it to a Windows PC and see what it does.

Because the disk is formatted with ext4 I probably can't test the whole usb adaptor AND disk in the same configuration, I won't be able to mount the ext4 partition in Windows.

Ian

[roseway]

I had a thought, and wondered if I should be using /dev/sda  not /dev/sda1 in the command.

That's certainly the case. sda1 is just one partition on the disk, but sda refers to the entire disk.

[sevenlayermuddle]

I have failed to get disks to spin down properly using hdparm on recent fedoras.  Part of the problem, iirc (may be wrong), is that hdparm instructs the disk's own firmware to spin down when idle.  All well and good but on fedora (other Linux's too perhaps)  there is some other system deamon that gathers SMART disk stats at intervals, and that process generates disk accesses that are detected by the disk as 'activity', and stops the spin down.

I did find a separate and (rather crude) "spin down" add-on package that runs as its own process, polling for disk access and manually spinning down disks when not in use.  It works well.

Not sure of accuracy of above, it's late, and my memory is short.  But there is at least  some truth in it, I'm sure.   

[burakkucat]

Have you tried any variations on the following?

hdparam -B b-value -S s-value /dev/sda

Where b-value is in the range 1 to 127.

[sevenlayermuddle]

Have you tried any variations on the following?

hdparam -B b-value -S s-value /dev/sda

Where b-value is in the range 1 to 127.

Yes.

So far as I recall, short spindown timeouts (up to a few ninutes) sometimes worked, longer timeouts never worked.   playing with '-B' made no difference.

If the OP wants to persevere with hdparm, one possible next step is to enable disk io debug using 'block dump', see http://www.linuxinsight.com/proc_sys_vm_block_dump.html

Another thing in particular that is worth trying, depending on which file system type is in use, is to mount the disk with 'noatime' which prevents some of the 'access' times being written.

But I emphasize, nothing worked for me, I had to give up on hdparm.

[sheddyian]

Bit of an update here, as I think I've got it working using hdparm 

I'd added a 2nd disk, later still I swapped this for a 2nd 250Gb disk that's identical to the 1st.

I then found that hdparm -S24 would work on one disk (and it would correctly spin down after 2 minutes) but the command returned the error I mentioned above for the other disk.  A bit odd as the disks are the same!

I wondered about the USB to SATA adaptors, and ordered two new ones from ebay.

Having connected those up, I now find the hdparm -S24 works correctly on both disks, and they both appear to spin down happily after 2 minutes of idle time.

So it would appear it was the fault of one of my USB - SATA adaptors 

Need to do some proper testing to make sure that spinning down isn't going to cause other ill effects to file transfer, but I'm pleased to note that electricity consumption drops from 32 watts to 15 watts once both disks have spun down. 

Ian

[burakkucat]

  :clap2: