doron

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.

In practically all cases I've looked at, when a drive does in fact spin down and then spins back up it means that something is accessing it. Could be user access, could be plugin, could be anything - but someone is issuing i/o. If your drive is wiped and out of the array, could it be Unassigned Devices? To test that, I'd actually format it and put it back into the array, empty. Also, I'd disable as many plugins as I can, just for the investigation. Then, add them one by one. A bit tedious perhaps but might reveal the culprit.

Okay this is actually good - it means the drive does go into spindown when the command sends it there. Question now is what wakes it up 30sec later. This is for you to figure out. It might be related to the unassigned devices situation, but I'm not sure.

Understood. Still, something is waking them up 30 secs later and causing Unraid to issue a SMART read. Let's put that aside for a moment and check whether your drives are even spinning down at all. Can you run the following line on your console and paste the output: sg_start -rp3 /dev/sdx ; sleep 3s; sdparm -C sense /dev/sdx

Many Seagate drives appear not not work well with this plugin - i.e., not to respond to the "spin down" SAS wire instruction with a temporary spindle spindown; however, from your log excerpt it appears that the issue is different - something in your Unraid setup keeps issuing i/o against the drive. The message unraid emhttpd: read SMART /dev/sdx is an indication of an i/o being issued, 30 seconds after the drive was sent to sleep. Suggest you explore who is keeping the drive busy, and check whether you can silence that entity. Might be another plugin, docker, VM, a remote access to one of your shares etc.

Thanks for reporting! Would you be so kind as to run this on your console (when the plugin is installed - you can remove it immediately thereafter): /usr/local/emhttp/plugins/sas-spindown/sas-utiland post: The console output The file /tmp/sas-util-out If you prefer, you can send these to me privately. (BTW your English is surely 100x better than my control of your language 😜)

Thanks for reporting. Glad to hear it is working well for you!

Thank you for reporting this, and thanks for the kind words. Your success is my reward, so I'm just happy the post helped you.