when restarting my server I often (most of the time) end up with 1 or 2 of the disks in the array being disabled. this, of course, means I have to redo the parity (which takes about 10 hours).

 

the drives in question are 8x 6TB SAS Drives (model: ST6000NM0095). I'm also using the "Spin Down SAS Drives" plugin by Doron in order to allow unraid to spin down my SAS drives.

 

I have already tried replacing 2 of the disks that this happened to, but the drives showing issues weren't the same ones every time (though I did notice that there was always a parity disk among the disabled disks so far).

 

I've also noticed that when I start a parity check manually while the disks are spun down all but 2 of the 8 disks get exactly 1024 errors and then don't get any more, unless I pause/cancel the check, spin the disks down again and restart the parity check (which adds an additional 1024 errors).

Admittedly these drives are used and pretty old (they all have roughly 3.5 years power on time), but I still wouldn't expect 8 out of ten drives to show the same behaviour, though I'm not ruling out the possibility.

 

also, I'm not getting any notifications about SMART, but I've heard people say that SMART isn't really great at determining (imminent) drive failure for spinning disks.

 

any help or advice would be greatly appreciated!

I've also attached logs

unraid-diagnostics-20250416-1748.zip

As a first step, I would recommend retesting without the SAS spin down plugin, since the issue happened after a spin down attempt:

 

Apr 16 17:21:04 UnRAID SAS Assist v2024.11.25: Spinning down device /dev/sde
Apr 16 17:21:04 UnRAID SAS Assist v2024.11.25: Spinning down device /dev/sdd
Apr 16 17:21:04 UnRAID SAS Assist v2024.11.25: Spinning down device /dev/sdf
Apr 16 17:21:04 UnRAID SAS Assist v2024.11.25: Spinning down device /dev/sdc
Apr 16 17:21:21 UnRAID kernel: sd 1:0:46:0: [sde] tag#2666 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s
Apr 16 17:21:21 UnRAID kernel: sd 1:0:46:0: [sde] tag#2666 Sense Key : 0x2 [current] 
Apr 16 17:21:21 UnRAID kernel: sd 1:0:46:0: [sde] tag#2666 ASC=0x4 ASCQ=0x1c 
Apr 16 17:21:21 UnRAID kernel: sd 1:0:46:0: [sde] tag#2666 CDB: opcode=0x7f, sa=0xb
Apr 16 17:21:21 UnRAID kernel: sd 1:0:46:0: [sde] tag#2666 CDB[00]: 7f 00 00 00 00 00 00 18 00 0b 20 00 00 00 00 00
Apr 16 17:21:21 UnRAID kernel: sd 1:0:46:0: [sde] tag#2666 CDB[10]: 00 00 00 c0 00 00 00 c0 00 00 00 00 00 00 00 20
Apr 16 17:21:21 UnRAID kernel: I/O error, dev sde, sector 192 op 0x1:(WRITE) flags 0x0 phys_seg 4 prio class 0
Apr 16 17:21:21 UnRAID kernel: md: disk29 write error, sector=128
Apr 16 17:21:21 UnRAID kernel: md: disk29 write error, sector=136
Apr 16 17:21:21 UnRAID kernel: md: disk29 write error, sector=144
Apr 16 17:21:21 UnRAID kernel: md: disk29 write error, sector=152

 

Alright, will report back once I've removed the plugin and recalculated parity (so tomorrow). thanks for the quick reply!

I've just finished parity again after removing the spindown plugin. since then I've performed a few reboots and started and stopped the array a few times and have been unable to recreate the issue. This points to either the plugin itself being the issue or unRAID not liking these drives being spun down. Feels great to have some clarity about this! I was kind of expecting the spindown not to be the issue since the problem often occured after a restart, but I suppose it might have been bacause the drives were spun down as I initiated the restart.

 

it almost feels like the drives are just giving errors because they're trying to read too soon after spinning up, but I don't really know.

the problem with this for me is that having these drives spinning 24/7 is decently expensive. spinning the drives down saved about 60 watts as compared to having them spinning while idling, which comes out to around €140 a year, just to spin some drives that would spend about 99% of their time not actually reading or writing.

 

Is there any solution that would let me still spin down these drives? I would obviously prefer not to have to replace these drives with different drives, though it really is starting to seem like that might be the only real solution...

I would recommend asking in the SAS plugin support thread, there may be a known issue with this drive model, problem with SAS drives is that spin down support is not as well tested as with SATA, since they are usually used with servers that are always on