doron

While you're testing, can you, right after the sdspin /dev/sdb down command, issue sdparm /dev/sdb -C sense and post the results? This typically tells you whether the spin down actually affected the drive.

Interesting. I can't reproduce this issue here - I'm at 7.3.4 as well, and at FCP v2026.10.12. Are you at the current version of FCP? Perhaps @Squid would be able to shed some light on this?

Basically, what Simon Said. The entire "spin down" notion is not defined well enough in the SAS (a SCSI flavor) standards. SAS drives are made primarily for data center and enterprise use, focusing on 24x365 operation for storage (cold storage is managed differently). There are low level SAS commands that imply "stop the spindle rotation temporarily and park the heads", but they are sort of half-baked in terms of the wider ecosystem (e.g. it is not well defined how exactly the drive will resume rotation). Therefore, different drive makers, firmware versions and even HBA firmware versions implement it differently. Ranging from (a) completely ignoring it, via (b) acting on it but requiring an explicit resume command, through (c) acting on it and resuming implicitly upon the next read/write issued against the drive. Due to how Unraid is designed, only drives that are implementing the latter "mode" perform as expected for Unraid spin up/down config. This, in sharp contrast with how SATA drives implement this - those are marketed for home/SOHO installation in which usage is not 24x7 and energy economics take precedence. Throughout the years of developing and maintaining this plugin, I've seen no improvement in the behavior of SAS drives in this context; on the contrary. Even some vendors who "got it right" in previous models, started shipping firmware with inconsistent spin up/down performance. It's just how the industry is.

I don't know that it does not, or why it wouldn't. Do you see a new issue after migrating to 7.3.3? If so, please report. (the Reddit post you point to is quite ancient, and I have not bumped into it until now)

Thanks. Can you, please -- cat /usr/local/emhttp/plugins/sas-spindown/drive_types sdparm -ip di_target /dev/sdh and, if you're into the sg_start things, while there's no known i/o activity against the drive -- sg_start -v -rp3 /dev/sdh && sleep 2s && sdparm -C sense /dev/sdh and paste the output you're getting on all of these?

When a SAS drive is supposed to be spun down, can you -- Share the lines you see in the log? Issue this command: sdparm -C sense /dev/sdX (replacing sdX with the applicable device name) and post the output?

Apologies for missing this post. Can you expand on that? What is the SCSI code you are seeing and where? When a SAS drive is supposed to be spun down, can you -- Share the lines you see in the log? Issue this command: sdparm -C sense /dev/sdX (replacing sdX with the applicable device name) and post the output?

Ah! Dual parity drives. I should have thought about that scenario as well. Yes, for two parity drives you have read-compute-write, hence two parallel reads of same sector make sense. That'd be great. Thanks.

If the i/o eventually completes, the timeout could be transient and the controller firmware gets over it once the drive is fully spun up. As with the other poster, I might try updating the f//w and see if it reduces the amount of messages. There might be some in-firmware parameters for not-ready timeouts, but I haven't looked this up.

Okay. The logs you shared indicate an error on two drives at the same time, reading the very same sector number. This might indicate you were doing parity rebuild or check (were you?), and/or a controller issue. Sorry, I missed your edit addition. This obviously points to the controller; the fact that you don't get a red x also indicates it's a transient error report that is self-healing - e.g. a short timeout on the HBA firmware to report that the drive is not ready, but the drive does eventually become ready and the i/o completes. I'd try to update the controller's firmware; other than that, vigorous testing on a different platform with other drives seems like the only other thing I can recommend in this situation.

With Seagates, this is unfortunately more common. Same question as to the other poster above - after this happens, does the drive return to normal operation?

This is somewhat unusual, I don't recall getting such issues on HGST drives, they usually play well with the SAS Spindown plugin. One question - what happens after these messages are spewed? Things go back to normal? You're not getting the Unraid rejection of the drive (red x) or anything else that's unusual, except for these lines in the log?

@Ezekial66 how do you determine the drive has not spun down?

The Seagate drives are renowned for not always playing well with the mechanism we use to spin SAS drives down. That said, how do you determine they are not spinning down? The sense data you provided seems to indicate the drive is trying to idle down via an internal timer, a feature that's independent and unrelated to what we do. Can you, right after asking the drive to spin down via the UI, run that sense command and see if it outputs anything different?

I wasn't aware of that either :-) So, time to wrap up this plugin. Thanks for playing.