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.

Indeed; in the SATA realm, the spin-down process is better defined in the standards and is fully implemented across the board. There's actually a reason for that difference, but that is unrelated to the matter at hand. Right. That makes sense, since it is most likely that the failures you've seen are not actual drive failures, but rather a phenomenon of the SAS spin-down implementation in these drives. As discussed above, some SAS drives, when spun down, expect an explicit "spin up" command, or else they stay still. In Unraid, that behavior would translate to an i/o error the next time the drive is needed for an i/o. Not "old" disks, mainly (I'm assuming) the fact that only a small fraction of the customers even use SAS drives, so it is looked at as something a bit "eccentric". At least that is my impression. Which is why I developed the plugin in the 1st place. But I wish that as well This thread has it all 🙂 also, if you look at the "exclusions" file in the plugin directory (/usr/local/emhttp/plugins/sas-spindown/) you can find some drives that were notoriously bad in that sense, so they were explicitly excluded from being acted on.

SSDs do not spin down. Look at the bright side though - they do not spin up, either.

Unfortunately not, as there is not much this plugin can do in way of fixing or working around this. I had a brief exchange with @limetechregarding a potential Unraid mod that could help with these types of drives, but it turns out this would require a substantial architectural change to the inner parts of Unraid, which is too complex and hence not in the cards.

Unrelated. If you want to put your server to some sleep mode, you may want to stop the array first.

https://forums.unraid.net/topic/56610-support-linuxserverio-duplicati/page/16/#findComment-1493108

Thanks for reporting this. Could you help with two more data points: (a) What make/model are your SAS drives? (b) When one of them is spun down, and before telegraf makes it spin up again (or when telegraf is disabled for a moment), can you share the output of: sdparm -C sense /dev/sdX replacing /dev/sdX with the device node of the spun-down SAS drive?

Thanks for reporting, happy this post helped you!

I don't have more info as to what wakes your drives up, no. I tried to skim the UD code for obvious clues and came out empty. I still believe something does. If you want to pursue this further, my next suggestion would be that you start Unraid with no plugins except for this one, no dockers and no VMs, and see whether the problem persists. If it does not, add back plugins and containers one by one (or...) and isolate which of them needs to be focused on.

Unfortunately adding extra support for specific drives is impractical. Unraid's kernel code architecture does not allow for issuing explicit spin-up instructions, which is what some of these drives seem to expect. Re drives that "behave", my experience with HGST (aka WD) SAS drives, e.g. the HC5x0 series, has been flawless, with fully reliable spin down and up per Unraid and this plugin.

Thanks for reporting, glad you found it helpful!