I have an external HDD (Buffalo HD-LBU3) that requires APM be set to 127 (or lower, presumably) to spin down; with the default of 128 it never spins down. Setting this via the Rockstor spindown interface works, in that the -B 127 is issued and the drive later spins down, but the setting isn’t persisted to the generated systemd unit. Then after a reboot, of course, the drive won’t spin down.
This happens because this error check in the service generation confirms a 0 return code and empty stderr. That’s reasonable. However, my drive issues error text even though it is successfully doing what was requested:
[23/Jan/2026 16:27:42] ERROR [system.osi:1622] non zero return code or error from hdparm command ['/usr/sbin/hdparm', '-q', '-B127', '/dev/disk/by-id/usb-BUFFALO_External_HDD_0109000019E8-0:0'] with error ['SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 7f 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', ''] and return code 0
I’m not sure whether this should be considered an issue. My question is whether it would make sense to handle specific error messages as spurious so that this setting could be persisted, or something like that. For now, I can create my own service to issue the APM command, but it might be useful to handle this case if some types of drives can handle APM even though they give error text.
Reading up more on it, it seems that for USB connected devices it happens sometimes that the hdparm commands are not passed through correctly. I assume, if you were to run hdparm -i ... you would get a similar error message?
I am wondering how the system identify it as a spurious error - just because of the return code being zero? Would one have to identify it on the message itself (i.e. SG_IO: bad/missing sense data). If that is indeed the only one, that could potentially
be caught and discarded …
Unlike manufacturers like e.g. Seagate, buffalo doesn’t have linux based tools to manage the apm/spindown outside of a windows based set up.
I think -i only gets cached information from the kernel, though, so I’m not sure it would cause a similar error. So, I tried -I which is the same but talks directly to the drive. No error there either, though:
/dev/sda:
ATA device, with non-removable media
Model Number: ST3000DM001-9YN166
...snip...
Checksum: correct
However, -S gives a very similar error to what I posted above for -B:
It still works, though. Rockstor doesn’t currently check for the presence of stderr when adding -S, which allows it to work regardless of the spurious error.
I’m not sure. The most useful information I’ve seen is in this thread but I’m not sure what to do with it.
It’s possible that other people would see the SG_IO message and the command doesn’t work with their drive, though I would hope it doesn’t return 0 in that case…
If you’re up for it, may be you could install sdparm as pointed out in the thread you linked to and see whether that will work without any errors. May be this opens the door to see whether this can be a replacement/additional way to manage that type of setup. Or, at least have a discussion about the upsides/risk on changing direction in that space.
Sure. I installed sdparm, read a bit, and tried it out, but I didn’t have any luck with parameters related to APM / standby. Here’s what I tried:
I was able to query the drive with commands like sdparm --long, sdparm --long --all, and sdparm --long --enumerate. A bunch of drive information is available (error counts, etc.).
Then I tried SCSI commands capacity, ready, start, and stop, all of which worked as expected. I also tried sense given the “sense data” error from hdparm, but it only returns a header line with no data and a 0 return code.
Next I found that sdparm --long --enumerate --all lists more, including several STANDBY parameters and SCT (which is referenced in several pages on this topic) but sdparm --get on those parameters only gives an error like “STANDBY not found in Power condition mode page”, so maybe --all lists all known parameters even if they’re not available on the given drive. (I also tried retrieving the flags with --flexible -6 which is commonly referenced, but there was no change.)
Nothing ever showed an error like the SG_IO sense data one, but I also didn’t find anything useful for power management.