1 hour ago, rankaiyx said:

ST32000444SS

have you tried 

 

sg_start -r --pc=3 /dev/sdx this will set to spin down without explicit requirement for a start.

1 hour ago, rankaiyx said:

My "Seagate Constellation ES ST32000444SS" needs NOTIFY (ENABLE SPINUP) to spinup , too.

 

Have you been using the SAS Spindown plugin?

17 hours ago, SimonF said:

have you tried 

 

sg_start -r --pc=3 /dev/sdx this will set to spin down without explicit requirement for a start.

It didn't work.

And I also tried "sg_raw /dev/sdd 1b 00 00 00 30 00", didn't work too.

https://www.seagate.com/files/docs/pdf/en-GB/whitepaper/tp608-powerchoice-tech-provides-gb.pdf

https://man.archlinux.org/man/extra/sg3_utils/sg_raw.8.en

 

"sg_start -S " and "sg_start -s" are valid.

Edited January 27, 20215 yr by rankaiyx

17 hours ago, doron said:

Have you been using the SAS Spindown plugin?

No, my NAS os is Arch Linux.

1 hour ago, rankaiyx said:

It didn't work.

And I also tried "sg_raw /dev/sdd 1b 00 00 00 30 00", didn't work too.

https://www.seagate.com/files/docs/pdf/en-GB/whitepaper/tp608-powerchoice-tech-provides-gb.pdf

https://man.archlinux.org/man/extra/sg3_utils/sg_raw.8.en

 

"sg_start -S " and "sg_start -s" are valid.

What controller are you using. Mine are LSI based and works fine with SEAGATE ST4000NM0023 Constellation ES.3 4TB 7200

No, my NAS os is Arch Linux.

Okay. In general, this thread is for support of the plugin.

This is the infamous 04h/11h status.
When the issue happens, you may want to try
sg_start -rp1 /dev/sdX
and see if it helps.

5 hours ago, SimonF said:

What controller are you using. Mine are LSI based and works fine with SEAGATE ST4000NM0023 Constellation ES.3 4TB 7200

LSI 3081 IT

I have tried a lot of methods, including the previous smartctl 7.2, but it didn't work all the time, so I decided to give up.

I plan to use them as cold backup disks.

4 hours ago, doron said:

Okay. In general, this thread is for support of the plugin.

This is the infamous 04h/11h status.
When the issue happens, you may want to try
sg_start -rp1 /dev/sdX
and see if it helps.

There's no echo, and the hard drive doesn't spindown.

22 minutes ago, rankaiyx said:

I have tried a lot of methods,

Only other suggestion I have is to set the timers in the disks. The disks should spin down after 9000 seconds.

 

sdparm --flexible -6 -l -S --set SZCT=9000  /dev/sdx number is per 100ms

sdparm --flexible -6 -l -S --set STANDBY_Z=1 /dev/sdx

On 1/28/2021 at 4:02 AM, SimonF said:

Only other suggestion I have is to set the timers in the disks. The disks should spin down after 9000 seconds.

 

sdparm --flexible -6 -l -S --set SZCT=9000  /dev/sdx number is per 100ms

sdparm --flexible -6 -l -S --set STANDBY_Z=1 /dev/sdx

Thank you, but this method has also been tried.

The hard drive SZCT is at least 60 minutes(36000), and I used sg_raw to force a timeout, but it didn't work. 

Of course, stanbyz has been set to 1 to enable it.

Edited January 28, 20215 yr by rankaiyx

On 1/27/2021 at 9:32 PM, rankaiyx said:

There's no echo, and the hard drive doesn't spindown.

Actually that command is supposed to spin a drive back up. I suggested you try it once the state you described occurs.

8 hours ago, rankaiyx said:

but this method has also been tried

Did you try setting idle timers also?

Just last week had to increase the capacity of my array and went for 3 x 3TB SAS data drives and a Seagate IronWolf ST10000VN0008 10TB SATA as the parity drive, with a Crucial/Micron RealSSD m4/C400/P400 M4-CT128M4SSD as the Cache. All connected through a new HP220 HBA in IT mode as my Gen8 Proliant board doesn't support NAS.

At first I had issues with the Dynamix cache folders plugin that kept my cpu bouncing between 15-100% and found a thread here that pointed me to uninstall it and fixed the problem. 

 

Then realised I had this issue where the SAS drives were not spinning down, found this thread and istalled the plugin. At first I thought it had cured the problem, but then found for some reason parity and disk 1 were spinning down but not 2 & 3 ? (all on HBA connector 0, Cache on HBA 1)

 

Log was full of:

Jan 31 10:34:28 Tower kernel: mdcmd (162): spindown 1
Jan 31 10:34:43 Tower kernel: mdcmd (163): spindown 2
Jan 31 10:34:43 Tower SAS Assist v0.84: spinning down slot 1, device /dev/sde (/dev/sg4)
Jan 31 10:34:58 Tower kernel: mdcmd (164): spindown 3
Jan 31 10:34:59 Tower SAS Assist v0.84: spinning down slot 2, device /dev/sdf (/dev/sg5)
Jan 31 10:35:12 Tower SAS Assist v0.84: spinning down slot 3, device /dev/sdb (/dev/sg1)
......continously

and you could hear a spindown attempt, followed by an immediate spinup every 30 seconds or so.

Manual spin down seemed to have no effect but all temp displayed *

 

Updated the OS to the Version: 6.9.0-rc2 beta release, instant spindown on all drives (audible confirmation too) on button select and no instant re-spinup. 

 

Question is, do I uninstall this plugin or is it still required?

Log states:

Jan 31 18:56:50 Tower emhttpd: spinning down /dev/sdd
Jan 31 18:56:50 Tower emhttpd: spinning down /dev/sde
Jan 31 18:56:50 Tower emhttpd: spinning down /dev/sdb
Jan 31 18:56:50 Tower emhttpd: spinning down /dev/sdf
Jan 31 18:56:50 Tower SAS Assist v0.84: Spinning down device /dev/sde
Jan 31 18:56:50 Tower SAS Assist v0.84: Spinning down device /dev/sdb
Jan 31 18:56:50 Tower SAS Assist v0.84: Spinning down device /dev/sdf

SEAGATE ST12000NM0027 success
 

3 hours ago, Knights21 said:

and you could hear a spindown attempt, followed by an immediate spinup every 30 seconds or so.

Yes, some processes in 6.8 might lead to disks spinning back up. Can probably be worked around, but if all works well for you in 6.9, no need to go back.

 

Quote

 

Question is, do I uninstall this plugin or is it still required?

Plugin is still required in 6.9-rc2 if you want the SAS drives to actually spin down. 

Edited January 31, 20215 yr by doron

2 hours ago, Raptor said:

SEAGATE ST12000NM0027 success
 

Thanks for reporting!

Would you mind running this command:

/usr/local/emhttp/plugins/sas-spindown/sas-util

and either post of pm me the resulting file?

11 hours ago, doron said:

Yes, some processes in 6.8 might lead to disks spinning back up. Can probably be worked around, but if all works well for you in 6.9, no need to go back.

 

Plugin is still required in 6.9-rc2 if you want the SAS drives to actually spin down. 

Many thanks doron, much appreciated.

 

New job for today, I have a red x against disk 3 🤕

3 minutes ago, Knights21 said:

New job for today, I have a red x against disk 3 🤕

Ouch. Is that a SAS drive?

If so, do you see, in the system log, just before the time of the red x, error messages containing "ASC=0x4 ASCQ=0x11"?

I had this a few times before the event:

Jan 31 23:47:49 Tower emhttpd: spinning down /dev/sdb Jan 31 23:47:49 Tower SAS Assist v0.84: Spinning down device /dev/sdb Jan 31 23:50:04 Tower kernel: sd 1:0:0:0: attempting task abort!scmd(0x00000000b1f693c0), outstanding for 15157 ms & timeout 15000 ms Jan 31 23:50:04 Tower kernel: sd 1:0:0:0: [sdb] tag#5941 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Jan 31 23:50:04 Tower kernel: scsi target1:0:0: handle(0x000d), sas_address(0x5000cca03ec60451), phy(7) Jan 31 23:50:04 Tower kernel: scsi target1:0:0: enclosure logical id(0x500605b008e61e80), slot(8) Jan 31 23:50:04 Tower kernel: sd 1:0:0:0: task abort: SUCCESS scmd(0x00000000b1f693c0)
Then this error text in the early morning:

Feb 1 04:20:20 Tower kernel: blk_update_request: I/O error, dev sdb, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 Feb 1 04:20:20 Tower kernel: blk_update_request: I/O error, dev sdb, sector 732965640 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0 Feb 1 04:20:20 Tower kernel: md: disk3 read error, sector=732965576 Feb 1 04:20:20 Tower kernel: md: disk3 read error, sector=732965584 Feb 1 04:20:20 Tower kernel: blk_update_request: I/O error, dev sdb, sector 732965640 op 0x1:(WRITE) flags 0x20800 phys_seg 1 prio class 0 Feb 1 04:20:20 Tower kernel: md: disk3 write error, sector=732965576 Feb 1 04:20:20 Tower kernel: blk_update_request: I/O error, dev sdb, sector 732965648 op 0x1:(WRITE) flags 0x20800 phys_seg 1 prio class 0 Feb 1 04:20:20 Tower kernel: md: disk3 write error, sector=732965584 Feb 1 04:20:50 Tower kernel: blk_update_request: I/O error, dev sdb, sector 64 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Feb 1 04:20:50 Tower kernel: md: disk3 read error, sector=0 Feb 1 04:20:50 Tower kernel: blk_update_request: I/O error, dev sdb, sector 64 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0 Feb 1 04:20:50 Tower kernel: md: disk3 write error, sector=0

14 minutes ago, Knights21 said:

I had this a few times before the event:

Jan 31 23:47:49 Tower emhttpd: spinning down /dev/sdb Jan 31 23:47:49 Tower SAS Assist v0.84: Spinning down device /dev/sdb Jan 31 23:50:04 Tower kernel: sd 1:0:0:0: attempting task abort!scmd(0x00000000b1f693c0), outstanding for 15157 ms & timeout 15000 ms Jan 31 23:50:04 Tower kernel: sd 1:0:0:0: [sdb] tag#5941 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Jan 31 23:50:04 Tower kernel: scsi target1:0:0: handle(0x000d), sas_address(0x5000cca03ec60451), phy(7) Jan 31 23:50:04 Tower kernel: scsi target1:0:0: enclosure logical id(0x500605b008e61e80), slot(8) Jan 31 23:50:04 Tower kernel: sd 1:0:0:0: task abort: SUCCESS scmd(0x00000000b1f693c0)

 

Which make/model are your SAS drives? Better, can you run:

/usr/local/emhttp/plugins/sas-spindown/sas-util

and either post of pm me the resulting file?

Yes SAS.

sde     | HUS723030ALS640       | 1000:0087:1590:0041   |  n/a  | 
sdf     | HUS723030ALS640       | 1000:0087:1590:0041   |  n/a  | 
sdb     | HUS723030ALS640       | 1000:0087:1590:0041   |  n/a  | 
 

Edited February 1, 20215 yr by Knights21

@doron you should add a donation link to your signature, I totally wanna buy you a coffee or beer for this plugin. My system uses a mixture of SAS and SATA drives and with how inexpensive SAS drives are on the retired server parts market I've got more SAS than SATA, I just hated how they never spun down. You have helped me save money in electric (can see that I'm saving about 100 watts of power on average now), so the last I can do is throw you a few dollars ❤️

10 hours ago, AnnabellaRenee87 said:

@doron you should add a donation link to your signature, I totally wanna buy you a coffee or beer for this plugin. My system uses a mixture of SAS and SATA drives and with how inexpensive SAS drives are on the retired server parts market I've got more SAS than SATA, I just hated how they never spun down. You have helped me save money in electric (can see that I'm saving about 100 watts of power on average now), so the last I can do is throw you a few dollars ❤️

Thank you so much for writing this - I'm really glad you're finding it helpful.

 

Your post is my reward, really. If you want, you can pay it forward - put those dollars in a charity of your choice.

Edited February 2, 20215 yr by doron

Quote

sdd     | ST12000NM0027 | 1000:0072:1028:1f1c   |  n/a  | 
sde     | ST12000NM0027 | 1000:0072:1028:1f1c   |  n/a  | 
sdf     | ST12000NM0027 | 1000:0072:1028:1f1c   |  n/a  | 

 

sas-util-out

 

I got red X in my SAS drive today as well

 

log file showed  before red X showed up

Feb 13 15:23:58 kernel: sd 9:0:1:0: [sdd] tag#3049 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s
Feb 13 15:23:58 kernel: sd 9:0:1:0: [sdd] tag#3049 Sense Key : 0x2 [current] [descriptor] 
Feb 13 15:23:58 kernel: sd 9:0:1:0: [sdd] tag#3049 ASC=0x4 ASCQ=0x11 

 

 

and /usr/local/emhttp/plugins/sas-spindown/sas-util showed 

 

sde | ST6000NM0034 | 1000:0072:1028:1f1c | n/a |
sdd | ST6000NM0034 | 1000:0072:1028:1f1c | n/a |

 

 

anything to help to solve the problem? I need to uninstall the plugin and rebuild my array today 😢