7 minutes ago, doron said:

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?

Just attempted it again within about 5-10 seconds of activating the spin down and it sends that same response.

Im not sure if its something about these drives in particular? They are referbs but theyh have this OOS designation on the referb label I havent seen before. Its how they show up under the serial ID in unraid as well.

Edited April 29Apr 29 by Ezekial66

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

12 minutes ago, doron said:

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

A combination of the indicator in the unraid GUI, and the drive light indicators on my SuperMicro JBOD chassis.

So I'm not sure if this is a problem that others are hitting, but I have noticed that since 7.3.0 this plugin seems to have stopped working. In fairness I only have a single SAS drive in my array but even clicking the spin down icon will just spin the icon for a minute and the drive never spins down. The logs do say "SAS Assist v2024.11.25: Spinning down device /dev/sda" but it never seems to actually spin down.

Might be a bug, might be my specific setup I'm not sure. The plugin did seem to work with 7.2.x though.

EDIT TO ADD: I did a bit of troubleshooting when I had a moment. It appears that all the "normal" SAS spindown commands like sdparm just don't work on that disk. Not sure what has changed... might be something at the kernel level. Probably not something you can fix unfortunately and it might be my controller... maybe a driver issue? Who knows?

Edited May 20May 20 by Sinister Crayon

Hi,

ive stumbled upon this plugin while trying to force my SAS drives to sleep, but they seems to be insomniac.

They are WD Ultrastars connected to LSI SAS 9300-16i with an IT firmware floating around the unraid forums.

4 other SATA drives on the same LSI card will sleep.

Unraid wont even try to attemp sending the command to them, which I dont understand.

It will send the wake up command, just like to the NVME caches, but no sleeps.

What could I try before we add them to no sleepy list?
Thanks

Edit:

After investigating mDNS caused by Home Asistant docker, I have left that docker offline
And the SAS drives spun down. I am confused why, as that docker does not have access to Array, but also Glad that after a year ive finaly managed to make them spin down

Edited June 3Jun 3 by Horrigan49

I have a SAS HUS726060AL5210 using the spin down it works. It spins up fine when I am using it and then spins down nicely but sometimes during some spin up's I get errors on unraid for that drive. Its some what random. If i try to reproduce the error I cant seem to by spinning it down and using something to spin it back up. E.g. Network Share/Plex/Manual all seems to work. Only thing I can see if it try's to run a smart test on the drive whilst its not spinning but some times its fine. Not 100% sure

Edited June 25Jun 25 by Funmonkey100

I am experiencing a similar issue to that the above poster. I have an unraid server I've had for a while that I've swapped the SAS card and drives at the same time. After doing some troubleshooting (replacing cables, repalcing the SAS card, changing spin up time outs on the card and upgrading the firmware) I am now getting the following error messages in the unraid log files:

Jun 25 09:06:35 Tower kernel: sd 0:0:2:0: [sdb] tag#3806 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s

Jun 25 09:06:35 Tower kernel: sd 0:0:2:0: [sdb] tag#3806 Sense Key : 0x2 [current] [descriptor] 

Jun 25 09:06:35 Tower kernel: sd 0:0:2:0: [sdb] tag#3806 ASC=0x4 ASCQ=0x1c 

Jun 25 09:06:35 Tower kernel: sd 0:0:2:0: [sdb] tag#3806 CDB: opcode=0x88 88 00 00 00 00 03 80 0f 17 00 00 00 00 08 00 00

Jun 25 09:06:35 Tower kernel: I/O error, dev sdb, sector 15033374464 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Jun 25 09:06:35 Tower kernel: md: disk1 read error, sector=15033374400

Jun 25 09:06:35 Tower kernel: sd 0:0:3:0: [sdd] tag#3808 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s

Jun 25 09:06:35 Tower kernel: sd 0:0:3:0: [sdd] tag#3808 Sense Key : 0x2 [current] [descriptor] 

Jun 25 09:06:35 Tower kernel: sd 0:0:3:0: [sdd] tag#3808 ASC=0x4 ASCQ=0x1c 

Jun 25 09:06:35 Tower kernel: sd 0:0:3:0: [sdd] tag#3808 CDB: opcode=0x88 88 00 00 00 00 03 80 0f 17 00 00 00 00 08 00 00

Jun 25 09:06:35 Tower kernel: I/O error, dev sdd, sector 15033374464 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Jun 25 09:06:35 Tower kernel: md: disk4 read error, sector=15033374400

Jun 25 09:06:36 Tower emhttpd: read SMART /dev/sdd

Jun 25 09:06:36 Tower emhttpd: read SMART /dev/sdb

Jun 25 09:06:36 Tower emhttpd: read SMART /dev/sdf

Jun 25 09:06:36 Tower emhttpd: read SMART /dev/sdc

The array works perfectly if i don't spin the disks down and starts no issues at boot time. The issue happens whenever a disk spins up and it happens almost immediately. I have run disk verification on all the drives before putting them into the array. The card I'm using is an LSI 9305-16i using the firmware from 45 drives. The drives are all Dell Branded Seagate Exos X16 16TB drives with part number ST16000NM010G.

Looking at the error (as I understand it) its asking the drive to spin up and then for data almost immediately resulting in a disk not ready reply that is causing the error. I'm not sure if this is correct?

My old server used 12TB SAS drives from Dell and a 9211 card and I didn't have any issues like this.

Any assistance is greatly appreciated. I am wondering if a fresh install of unraid would be the best thing or if I'm likely to have this issue again?

Additional Note: I've kept the 16tb drives and gone back to the 9211-8i with a SAS expander and I have no such issues (from a quick test). So it appears to be something with 9305 cards and I don't understand what or how to further diagnose it. Any help on this would still be appreciated.

Edited June 27Jun 27 by metalwolf

On 6/25/2026 at 3:27 AM, Funmonkey100 said:

I have a SAS HUS726060AL5210 using the spin down it works. It spins up fine when I am using it and then spins down nicely but sometimes during some spin up's I get errors on unraid for that drive.

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?

On 6/26/2026 at 9:30 PM, metalwolf said:

I am experiencing a similar issue to that the above poster.

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?

3 hours ago, doron said:

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?

I've had it both ways sometimes it just shows up as an error and the drive works but sometimes it kicks the drives out. The drive itself works fine and the smart data of the drive shows no increment of the issue counters. In my recent testing I've stopped the array as soon as it showed 1 error to prevent it kicking a disk out.

As mentioned going back to the 9211-8i and sas expander I get no issues at all. I have another pc I am going to set up with the raid controller and a couple of 16tb drives (spares) with an unraid demo license for testing. if theres anything you want me to try let me know, I need to format a couple of the disks with for the 520 vs 512 issue first.

I'm reluctant to put the card back in my main array until I figure out if its solvable.

3 hours ago, doron said:

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?

Just getting errors but everything is working ok.

13 minutes ago, metalwolf said:

I've had it both ways sometimes it just shows up as an error and the drive works but sometimes it kicks the drives out. The drive itself works fine and the smart data of the drive shows no increment of the issue counters. In my recent testing I've stopped the array as soon as it showed 1 error to prevent it kicking a disk out.

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.

13 minutes ago, metalwolf said:

As mentioned going back to the 9211-8i and sas expander I get no issues at all. I have another pc I am going to set up with the raid controller and a couple of 16tb drives (spares) with an unraid demo license for testing. if theres anything you want me to try let me know, I need to format a couple of the disks with for the 520 vs 512 issue first.

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.

14 minutes ago, Funmonkey100 said:

Just getting errors but everything is working ok.

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.

1 hour ago, doron said:

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.

Hi,

Just to fill in a few additional blanks. The cards running the latest firmware (I got it from 45drives guide on updating the card). There were other disks a few seconds earlier i clipped the last few as they were all the same. My test was to stop all my docker containers, spin down the array and start up a single container (plex). After a few seconds it started spinning up disks, so I'm assuming it was writing and they are the parity drives.

I did follow a few other guides that had me increase the time the card should wait for the drive to be ready to 30 and 45 seconds for the two sections but this did nothing. Thinking back, it may have made things worse as the errors originally when i tried to fix it weren't showing up immediately on spin up. I might still have the errors somewhere....

I do have another identical card (running on an older firmware) that i had different issues with (1 disk reported thousands of errors - but i think the card wasn't to blame on this.

I will give it a go with both cards and report back anything i find in case its helpful for someone else.

Edited June 28Jun 28 by metalwolf

6 minutes ago, metalwolf said:

After a few seconds it started spinning up disks, so I'm assuming it was writing and they are the parity drives.

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.

6 minutes ago, metalwolf said:

I will give it a go with both cards and report back anything i find in case its helpful for someone else.

That'd be great. Thanks.