Hey,

Since I upgraded to 6.11.0 (and also now in 6.11.1), some drive are not spinning down as they were before.

It was disks 7 & 8 while on 6.11.0 and now only disk 8 in 6.11.1.

For 6.11.0, I am not sure, but for 6.11.1, I know that for the first few hours/days, all drives were able to spin down. And after a time, disk8 would not.

 

I checked the usual suspects (appdata, system, dockers, etc.) and to the best on my recollection I made no significant change to my system.

All shares on disk8 are using my cache.

 

However, I see errors on the Disk log information of the problematic drives that are not present on drives that do spin down properly, the Security freeze and Device configuration overlay.

Oct  9 09:13:31 mediahub kernel: ata9: SATA max UDMA/133 abar m2048@0xfb716000 port 0xfb716300 irq 57
Oct  9 09:13:31 mediahub kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Oct  9 09:13:31 mediahub kernel: ata9.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
Oct  9 09:13:31 mediahub kernel: ata9.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
Oct  9 09:13:31 mediahub kernel: ata9.00: ATA-10: ST6000VN0041-2EL11C, SC61, max UDMA/133
Oct  9 09:13:31 mediahub kernel: ata9.00: 11721045168 sectors, multi 16: LBA48 NCQ (depth 32), AA
Oct  9 09:13:31 mediahub kernel: ata9.00: Features: NCQ-sndrcv
Oct  9 09:13:31 mediahub kernel: ata9.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
Oct  9 09:13:31 mediahub kernel: ata9.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
Oct  9 09:13:31 mediahub kernel: ata9.00: configured for UDMA/133
Oct  9 09:13:31 mediahub kernel: sd 9:0:0:0: [sdh] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB)
Oct  9 09:13:31 mediahub kernel: sd 9:0:0:0: [sdh] 4096-byte physical blocks
Oct  9 09:13:31 mediahub kernel: sd 9:0:0:0: [sdh] Write Protect is off
Oct  9 09:13:31 mediahub kernel: sd 9:0:0:0: [sdh] Mode Sense: 00 3a 00 00
Oct  9 09:13:31 mediahub kernel: sd 9:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct  9 09:13:31 mediahub kernel: sd 9:0:0:0: [sdh] Preferred minimum I/O size 4096 bytes
Oct  9 09:13:31 mediahub kernel: sdh: sdh1
Oct  9 09:13:31 mediahub kernel: sd 9:0:0:0: [sdh] Attached SCSI disk
Oct  9 09:14:20 mediahub  emhttpd: ST6000VN0041-2EL11C_ZA1A27S5 (sdh) 512 11721045168
Oct  9 09:14:20 mediahub kernel: mdcmd (9): import 8 sdh 64 5860522532 0 ST6000VN0041-2EL11C_ZA1A27S5
Oct  9 09:14:20 mediahub kernel: md: import disk8: (sdh) ST6000VN0041-2EL11C_ZA1A27S5 size: 5860522532 
Oct  9 09:14:20 mediahub  emhttpd: read SMART /dev/sdh
Oct  9 09:29:23 mediahub  emhttpd: spinning down /dev/sdh
Oct  9 10:49:15 mediahub  emhttpd: spinning up /dev/sdh
Oct  9 10:49:32 mediahub kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Oct  9 10:49:32 mediahub kernel: ata9.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
Oct  9 10:49:32 mediahub kernel: ata9.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
Oct  9 10:49:32 mediahub kernel: ata9.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
Oct  9 10:49:32 mediahub kernel: ata9.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
Oct  9 10:49:32 mediahub kernel: ata9.00: configured for UDMA/133
Oct  9 10:49:32 mediahub  emhttpd: sdspin /dev/sdh up: 1
Oct  9 10:49:32 mediahub  emhttpd: read SMART /dev/sdh

 

What's odd is that I see those errors on the syslog for other ataX.00 but only for the device that cannot spin down on the Disk log information.

It feels like a bug, but I wanted to discuss it here before starting a proper bug report.

For the moment, I only saw that on my old ST6000VN0041-2EL11C drives.

 

My diagnostics have the issue with for the share 'compute' so I add the screenshots.  

 

 

 

PS : the integrity plugin is present but deactivated for months as I move things around, so most probably not the culprit.

 

Does it make a difference if you connect the Seagate drives to the LSI? You can swap with two disks there to the onboard SATA.

Good idea, I'll try during the weekend and report back.

Yesterday the second Seagate drive also started to refuse to spin down.

Oct 14 04:56:48 mediahub  emhttpd: spinning down /dev/sdc
Oct 14 20:02:56 mediahub  emhttpd: spinning up /dev/sdc
Oct 14 20:03:13 mediahub kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Oct 14 20:03:13 mediahub kernel: ata3.00: configured for UDMA/133
Oct 14 20:03:13 mediahub  emhttpd: sdspin /dev/sdc up: 1
Oct 14 20:03:13 mediahub  emhttpd: read SMART /dev/sdc
Oct 14 20:47:43 mediahub  emhttpd: read SMART /dev/sdc

 

I switched both to the HBA, I am able to spin them down for now.

I will monitor and provide an update in a few days.

Didn't had to wait too long to see the issue again.  

Different error now on the HBA, same result as the two drives stay spinned up.

 

Oct 15 17:46:34 mediahub  emhttpd: spinning down /dev/sdf
Oct 16 00:53:33 mediahub  emhttpd: spinning up /dev/sdf
Oct 16 00:53:48 mediahub kernel: sd 5:0:2:0: [sdf] tag#1286 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e3 00
Oct 16 00:53:50 mediahub  emhttpd: sdspin /dev/sdf up: 22
Oct 16 00:53:50 mediahub  emhttpd: read SMART /dev/sdf

 

Oct 16 00:32:41 mediahub  emhttpd: read SMART /dev/sdn
Oct 16 00:52:39 mediahub  emhttpd: spinning down /dev/sdn
Oct 16 00:53:51 mediahub  emhttpd: spinning up /dev/sdn
Oct 16 00:54:06 mediahub kernel: sd 5:0:4:0: [sdn] tag#1247 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e3 00
Oct 16 00:54:07 mediahub  emhttpd: sdspin /dev/sdn up: 22
Oct 16 00:54:07 mediahub  emhttpd: read SMART /dev/sdn

 

 

Since it only happens with that Seagate model in either controller it suggests they are not liking something in the newer kernel, look for a firmware update for the drives, failing that you'll probably will need to wait for some kind of fix in a future kernel.

As per Seagate's site :

A field update is not available for this serial number

 

I will see what's the behavior with the 6.x kernel and report then.

 

Thanks for confirming what I was thinking. Hopefully that can help some other users.

I'll provide an update on this issue.

I am now using 6.11.3 for 3 days, 10 hours and the problem did not came back yet.

 

I do have the kernel message with opcode=0x85 on both drives, but they spin down nevertheless.

I'll provide further updates if there is some change.

A final feedback on that issue.

 

No more problem since 6.11.3. I have 26 days of uptime on 6.11.5 and all drives still spin down as needed.

I'll consider that it was probably a kernel or other tool bug that was later fixed.

Hi, same issue here.
Yesterday I installed a brand new Seagate IronWolf 4Tb on my Unraid server (6.12.4). This disk is a replacement for an old seagate Barracuda on a LSI board. Since I installed the new disk I saw that the disk won't spin down as per settings. If I try to spin down the disk manually, it spins up after few seconds but I see no activity on the disk (no reads, no writes and no file opened on file activity plugin report).  With the old disk I experienced no issues on this. Any advice? Thanks

4 minutes ago, unimpressed-outrage2203 said:

Hi, same issue here.
Yesterday I installed a brand new Seagate IronWolf 4Tb on my Unraid server (6.12.4). This disk is a replacement for an old seagate Barracuda on a LSI board. Since I installed the new disk I saw that the disk won't spin down as per settings. If I try to spin down the disk manually, it spins up after few seconds but I see no activity on the disk (no reads, no writes and no file opened on file activity plugin report).  With the old disk I experienced no issues on this. Any advice? Thanks

What version of Unraid are you using ?

 

I still had a occasionnal issues with 6.12.x but since 6.12.4 it seems to be OK.

My old drives do spin down properly even after 1.5 months of up time where before it was working for a time and then it stopped.

 

In my case, I did nothing in particular to 'fix it', it was probably kernel drivers issues that were fixed in one of the last update. But similar symptoms do not always mean the same root cause.

11 minutes ago, ChatNoir said:

What version of Unraid are you using ?

 

I still had a occasionnal issues with 6.12.x but since 6.12.4 it seems to be OK.

My old drives do spin down properly even after 1.5 months of up time where before it was working for a time and then it stopped.

 

In my case, I did nothing in particular to 'fix it', it was probably kernel drivers issues that were fixed in one of the last update. But similar symptoms do not always mean the same root cause.

Hi, I use 6.12.4, as specified in my original post.

I'm struggling with this issue because I have about  30 days to return the disk and take a WD Red. I have other WD Red in my server and had no issue, but this time I was curious to try an IronWolf because I read those are better.

Do you think there is anything I can do? 

2 minutes ago, dagmenico said:

Hi, I use 6.12.4, as specified in my original post.

Sorry, somehow I missed that.  

 

Have you checked your disklog ?

It might show something.

 

Your diagnostics might also provide some information.

 

Someone else can perhaps chime in.

1 hour ago, ChatNoir said:

Sorry, somehow I missed that.  

 

Have you checked your disklog ?

It might show something.

 

Your diagnostics might also provide some information.

 

Someone else can perhaps chime in.

 

It seems that is the SMART read that keeps the disk spinning. I'm I wrong?

I've also checked the SMART configuration for the disk and I confirm is the same as the other disks

 

46 minutes ago, dagmenico said:

It seems that is the SMART read that keeps the disk spinning. I'm I wrong?

The SMART entries in the syslog occur when Unraid thinks the drive has been spun up having previously been spun down.

1 hour ago, itimpi said:

The SMART entries in the syslog occur when Unraid thinks the drive has been spun up having previously been spun down.

Ok so nothing fancy...

 

I attach also the diagnostic for the disks (green the disks that spin down correctly, red the disk with the issue)