Hard drives in USB 3 enclosure spin down upon immediate command but not after timed delay

Support & Help Requests Hardware
#1

I guess this has been asked many times before and has many different possible fixes as I have viewed on Google. I have an external drive bay with two drives in it via USB3. SMART works and manually typing hdparm -y /dev/sdx shuts the drives down and they restart when accessed but neither hd-idle or hdparm -sx /dev/sdx work automatically. Any ideas on how or if this can be done? I would like them to run for 10 or 20 minutes when accessed. Since hdparm -y works I wonder what is the problem with the other commands.

Here is an example -

$sudo -C hdparm /dev/sda:
drive state is: standby

But drive is running.

$ sudo hdparm -y /dev/sdb
/dev/sdb:
issuing standby command
$ sudo hdparm -y /dev/sda
/dev/sda:
issuing standby command

Both drives are stopped.

$ sudo hdparm -C /dev/sda
/dev/sda:
drive state is: standby
$ sudo hdparm -C /dev/sda
/dev/sda:
drive state is: standby

and both still say standby.

#2

You're issuing the wrong command. The correct command to issue is sudo hdparm -S 120 /dev/sda or sudo hdparm -S 240 /dev/sda for a 10-minute or 20-minute standby timer, respectively. Obviously the commands should work for /dev/sdb as well.

The command you were issuing is marked in the hdparm man page as "VERY DANGEROUS" (not my emphasis!). The command you were issuing tells the drives to start up at initial power-on in standby mode, instead of immediately spinning up; assuming the extra x in your command line was not a number and instead was a literal lowercase 'x', that sets the drive up for hotswapping, which is also marked as "DANGEROUS". (So in other words, if your hardware or kernel were buggy like a lot of older hardware and software, you could have locked up your whole system with these commands until you forcefully rebooted, and hence lost your standing work as well; I have experience with this!)

My source for this information (https://linux.die.net/man/8/hdparm):

I hope that solves the problem; keep me posted on your success or failure.

1 Like
#3

I will explain this again.... The hdparm -y setting immediately shuts the drive down so yes it should be used only for testing or if you know the drive is not doing something. Best to make sure nothing is open to the drive and sync before doing it. The hdparm -S xxx does NOT work. It says it does but they never spin down. Here is an example -

$ sudo hdparm -S 120 /dev/sda1

/dev/sda1:
setting standby to 120 (10 minutes)

$ sudo hdparm -S 120 /dev/sdb1

/dev/sdb1:
setting standby to 120 (10 minutes)

$ sudo hdparm -S 120 /dev/sdd1

/dev/sdd1:
setting standby to 120 (10 minutes)

Nothing happens and now for some reason the hdparm -y is not working either.

The controller is a JMicron -

Bus 002 Device 003: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

And I suspect the issue is with it. I did have the same drives plug into a wavlink dock that I believe also uses the JMicron chip and it shutdown via the external SW in 10 minutes. No commands were issued from Ubuntu.

So I guess this is not going to work.

#4

Oh, when you originally wrote the command lines you used the lowercase -s option to hdparm. I got a little confused there.

OK, now I see another problem: You're trying to set standby settings on a partition, not a drive. Specify /dev/sda, not /dev/sda1. The latter will never get you anywhere since it doesn't make sense to spin down a partition -- what would be the dynamics of that? Part of the disk platters breaking off and shutting down while the rest of the platters continue spinning, now unbalanced? :rofl: Sorry if the joke was the last thing you wanted to hear right now -- I can only hope you agree it's at least kind of funny.

So, to summarize: Try doing sudo hdparm -S 120 /dev/sda, not sudo hdparm -S 120 /dev/sda1.

1 Like
#5

SOLVED! The problem is, and I think this effects many, that hdparm is not the right program to use for scsi disks which the tipoff is SDX! Here is a link to the right way to do it and this worked for me.

https://lists.debian.org/debian-user/2015/08/msg00125.html

You obviously have to load sdparm.

Here is a snippet of what I did but see the above link for details. I am using the partID and my drives are 100ms intervals. This sets and then shows the result.

cat set_spindown

sudo sdparm --flexible -6 -l --save --set SCT=9000 /dev/disk/by-partuuid/04b242af-01
sudo sdparm --flexible -6 -l --save --set STANDBY=1 /dev/disk/by-partuuid/04b242af-01
sudo sdparm --flexible -6 -l --get SCT /dev/disk/by-partuuid/04b242af-01
sudo sdparm --flexible -6 -l --get STANDBY /dev/disk/by-partuuid/04b242af-01

sudo sdparm --flexible -6 -l --save --set SCT=9000 /dev/disk/by-partuuid/000b3af9-01
sudo sdparm --flexible -6 -l --save --set STANDBY=1 /dev/disk/by-partuuid/000b3af9-01
sudo sdparm --flexible -6 -l --get SCT /dev/disk/by-partuuid/000b3af9-01
sudo sdparm --flexible -6 -l --get STANDBY /dev/disk/by-partuuid/000b3af9-01

What tipped me off to this was the following -

$ sudo hdparm -B127 /dev/sda

/dev/sda:
setting Advanced Power Management level to 0x7f (127)
SG_IO: bad/missing sense data, sb[]: 70 00 0b 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
APM_level = not supported

Yes not supported - it is a scsi drive! I would think not many drives today would use hdparm which was designed for older ata drives.

1 Like
#6

So these are not SATA drives simulating SCSI hardware, like the kernel does these days, but real SCSI drives (maybe SAS)? OK. I can believe that. Good to hear that you solved it.

#7

NO, they are ATA connected drives but when run on USB3 via the bridge are seen as scsi.

Even when running smartctl you need to specify -sat

$ cat smart_test.sh
sudo smartctl -t short -d sat /dev/$1

#8

Also pertinent to this is that anything that periodically accesses the drives can start them up even when nothing obvious is going on. If you are running smartctl this is the fix I found for that -

I am pretty sure Debian installs and runs smartd by default to keep an eye on your disks' SMART status. The regularity with which the disk is spinning up certainly points to something like that.

First, run /etc/init.d/smartd status to check whether smartd is running. If it is, that might be it. If not, it's something else, and you can disregard this answer.

Second, check /etc/smartd.conf and /etc/defaults/smartmontools. The best way to have a normally-powered-down disk in a smartd configuration is to list it manually in /etc/smartd.conf but with a -n switch given. For example:

/dev/disk/by-id/wwn-0xXXXXXXXXXXXXXXXX -a -l error -l selftest -n standby,10,q -m root@localhost

The -n (or --nocheck) is described in the smartd(8) and smartctl(8) man pages. standby here specifies don't check the drive (which may spin it up) if the drive is in standby mode (spun down), and ,q means don't write an informational log message saying that the check was skipped (which itself may cause the drive to spin up). You can also add ,N to this where N is an integer specifying the maximum number of consecutive checks to skip. In the example above, after ten checks are skipped the drive will be checked anyway, regardless of its current power state.

Do systemctl restart smartd after updating the file.

I found it best to stop smartctl altogether to see if that stops the false startups.

systemctl stop smartd

Subsequently you can start it again after the test - systemctl start smartd

If it stopped the false starts then you need to craft config lines as above to ignore the test when in standby mode.

#9

UAS, actually: USB Attached SCSI. :slight_smile:

Yes, even though they aren't actually SCSI drives.

The reason I mention this is because it has genuine value for one unusual scenario: USB3 thumb drives. Ones that support UAS (rather than the poorly-designed / badly outdated original USB protocol) can be around 10x faster for RIOP use than generic USB3 drives, even if the peak transfer rates are the same, simply from better queuing/command protocols.
It's pretty much irrelevant on a PC, but if you're using one as a filesystem (for e.g. a Pi etc) it can make a huge difference. :slight_smile:

1 Like