Is there a way to check if an USB drive is stopped?

Question

I've written a script to backup my server's HD every night. At the end of the script, I sync, wait a couple of minutes, sync and then I issue sg_start --stop to stop the device. The idea is to extend the lifetime of the device by switching the HD off after ten minutes of incremental backup (desktop disks will survive several thousand on/off cycles but only a few hundred hours of continuous running).

This doesn't always work; I often find the drive still spinning the next morning. Is there a shell command which I can use to check that the drive has stopped (so I can issue the stop command again [EDIT2]or write a script to create a process list when the drive is running so I can debug this[/EDIT2])?

[EDIT] I've tried sg_inq (as suggested by the sg_start man page) but this command always returns 0.

I've tried hdparm but it always returns "drive state is: unknown" for USB drives (attached via /dev/sdX) and when trying to spin down the drive, I get "HDIO_DRIVE_CMD(setidle1) failed: Input/output error".

sdparm seems to support to set the idle timer on the drive (see "Power mode condition page") but the IDLE option has "Changeable: n" and I haven't found an option which tells me the drive power state.

[EDIT2] Note: I can stop the drive with sg_start --stop from the console. That always works; it just doesn't always stay down until midnight. The sever is in the basement (where it's nice and cool) and I'd rather have a way to check whether the drive is up or not from the warm living room :) If I had a command which told me the status of the drive, I could write a script to alert me when it spins up (check every minute) and then I could try to figure out what might be causing this.

If that matters: I'm using openSUSE 11.1.

Answer 1

When you say you've tried hdparm, you haven't said what you have tried. I have some usb hard drives in an enclosure, and some of the commands work for it and others don't, but I guess it all depends on all facets of the transport mechanism.

  hdparm  -S 120  /dev/sda  

Should tell the drive to sleep itself after ~10 minutes of inactivity.

I'm guessing you have already tried this, but its not obvious, and writing this as an answer may help a future reader.

Nothing accesses the drive but the backup script.

This is nice in theory, but I have found on odd occasions this is not enough. There are lots of processes and tasks that if they even look at the drive a spin up may occur if the lookup is for some reason out of the disk-cache.

Common culprits are tools like updatedb scanning all mounts for files, and fam or gamin doing funky stuff to monitor disks for changes.

If in doubt, add a layer of certainty by mounting the device before executing the script, and unmounting it when you are done.

 lsof +D /mountpoint

You should probably parse the output of this as well before attempting to unmount to be sure that nothing is still trying to use it.

, ，

 umount -l /mountpoint 

so if anything accesses it between you doing lsof| greplsof| grep and calling umount , it will still unmount the drive and stop things being able to read it.

Its also possible that HAL and friends are doing wakeups to the drive probing for connect/removal state. I really hope it isn't, but it does that on some device types. It seems an unlikely cause, but I'll consider anything possible.

Try fun stuff like

lsof /dev/devicehere 

and

lsof /dev/devicehere1 

Which appears to get a comprehensive list of all things that would be accessing the handle either directly or indirectly.

Answer 2

You also need to check the mount options and use "noatime" as a mount option, otherwise the kernel still updates the access times periodically. So this may be the cause of your problem too.

Answer 3

If hdparm returns this:

 drive state is:  unknown

And smartctl returns this:

CHECK POWER MODE: incomplete response, ATA output registers missing
CHECK POWER MODE not implemented, ignoring -n option

Then it is not possible to obtain the usb drive sleep status. I tried multiple creative things like the USB power consumption or monitoring file access, but I found nothing to verify the drive's state.

The only solution is to replace the USB SATA adapter (or enclosure) against one with a different USB bridge chip. The one that did not work for me, used the JMicron JMS567 (152d:0578 / 0x152d 0x0578) which could be perhaps updated , but I was not able to test it as the update tool needs an ARM CPU. Now I'm using two different adapters which both use the Asmedia ASM1051E / ASM1053E / ASM1153 / ASM1153E and they passthrough all commands.

You can check the bridge chip of your USB SATA adapter / enclosure as follows:

lsusb -v | grep -E ': ID |idVendor|idProduct'

Which returns something like:

Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
  idVendor           0x174c ASMedia Technology Inc.
  idProduct          0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge

Answer 4

If hdparm -C /dev/sda said drive state is: unknown than it's not supported for your drive and there is no way to tell

Your additional questions (answered by others already)

• what's using a drive?
  • lsof
  • fuser
  • triggers
• how to force a drive to stay sleeping?
  • hdparm
  • umount
  • your device can still be woken when unmounted but likely only by something you do (smartctl, blkid, etc)

Related: you can also automatically pause backup or whatever for an hour if your drives get to hot.

Answer 5

I often find the drive still spinning the next morning.

Couldn't this just be because it was spun up again when the server eg. wrote to a log file or something during the night? You might try sdparm, which can return status information on a drive. But I think it's better to just set the option in your BIOS that lets your HD automatically spin down after an amount of inactivity, it's easier.

Answer 6

Have you tried stopping the drive with the following command:

eject -t /dev/yourHD

This works quite good for my USB hard drives.