[Plugin] Spin Down SAS Drives


doron

Recommended Posts

6 hours ago, Dustiebin said:

I have been having this issue but with my SATA drives.

 

I have 4 SATA and one SAS all off the same HBA card.

Doesn't look like you necessarily have an issue - more like there's i/o activity against your drives.

Could be either access to data from a client, or a plugin / docker etc.

 

6 hours ago, Dustiebin said:

 

This 'app' actually keeps my SAS spun down it is only my SATA's that are getting spun back up with the same SMART trigger.

Note the SMART message is not a trigger - it's a response to Unraid seeing (or believing) the drive being spun up.

 

More importantly, note there's a time gap between your spin-down and the SMART messages - a few minutes. That may well reflect normal drive activity.

Link to comment
19 hours ago, doron said:

Doesn't look like you necessarily have an issue - more like there's i/o activity against your drives.

Could be either access to data from a client, or a plugin / docker etc.

 

Note the SMART message is not a trigger - it's a response to Unraid seeing (or believing) the drive being spun up.

 

More importantly, note there's a time gap between your spin-down and the SMART messages - a few minutes. That may well reflect normal drive activity.

Thanks for the response. 

I have turned off all dockers, removed most apps (the fan one, temp one, sleep etc) and still get the issue. 

I will check the file activity app and see what may be triggering all drives but one to spin back up. 

 

Will update with my results. 

Thanks again

Link to comment
  • 2 weeks later...

Just upgraded to 6.10.3 (Yeah, I know I wasn't a fast adopter here) 

 

Anyways I'm getting the same issues with SAS HD's (WD's) that look like they're not spinning down.  It Seems like the smart read is spinning them up.   Anyway to set smart read setting time interval?  I'm going to try to shut off dockers this weekend to see if that solves it.   No issues w/ SAS not spinning down on 6.9.

 

Sep 6 16:15:21 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdd Sep 6 16:15:35 Skynet emhttpd: spinning down /dev/sde Sep 6 16:15:35 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sde Sep 6 16:15:47 Skynet emhttpd: spinning down /dev/sdg Sep 6 16:15:47 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdg Sep 6 16:16:00 Skynet emhttpd: spinning down /dev/sdi Sep 6 16:16:00 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdi Sep 6 16:16:14 Skynet emhttpd: spinning down /dev/sdl Sep 6 16:16:14 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdl Sep 6 16:16:27 Skynet emhttpd: spinning down /dev/sdn Sep 6 16:16:27 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdn Sep 6 16:16:40 Skynet emhttpd: spinning down /dev/sdt Sep 6 16:16:40 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdt Sep 6 16:16:54 Skynet emhttpd: spinning down /dev/sdu Sep 6 16:16:54 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdu Sep 6 16:17:09 Skynet emhttpd: spinning down /dev/sdy Sep 6 16:17:09 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdy Sep 6 16:17:23 Skynet emhttpd: spinning down /dev/sdz Sep 6 16:17:23 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdz Sep 6 16:18:00 Skynet emhttpd: read SMART /dev/sdc Sep 6 16:18:14 Skynet emhttpd: read SMART /dev/sdd Sep 6 16:18:27 Skynet emhttpd: read SMART /dev/sde Sep 6 16:18:41 Skynet emhttpd: read SMART /dev/sdg Sep 6 16:18:54 Skynet emhttpd: read SMART /dev/sdi Sep 6 16:19:07 Skynet emhttpd: read SMART /dev/sdl Sep 6 16:19:21 Skynet emhttpd: read SMART /dev/sdn Sep 6 16:19:35 Skynet emhttpd: read SMART /dev/sdt

Link to comment
4 hours ago, cbr600ds2 said:

Anyways I'm getting the same issues with SAS HD's (WD's) that look like they're not spinning down.

The "read SMART" thing is essentially Unraid's response to the drive spinning up, rather than the cause of that spin-up.

Note that in your case there seems to be a time gap between the spin-down and "read SMART" messages - like 30 seconds etc. - which usually indicates there's actually some disk activity that spins them up.

From the log snippet you provided, it seems as if only some of the drives spin back up, but not all. If that is indeed the case, I'd probably look for a share or folder that lives specifically on these drives, and try to figure out who accesses this share/folder. Just a thought.

Link to comment
18 hours ago, doron said:

The "read SMART" thing is essentially Unraid's response to the drive spinning up, rather than the cause of that spin-up.

Note that in your case there seems to be a time gap between the spin-down and "read SMART" messages - like 30 seconds etc. - which usually indicates there's actually some disk activity that spins them up.

From the log snippet you provided, it seems as if only some of the drives spin back up, but not all. If that is indeed the case, I'd probably look for a share or folder that lives specifically on these drives, and try to figure out who accesses this share/folder. Just a thought.

 

Here's a weird thing - a few of the drive's has nothing on it.  I guess I'll do some checking later

 

Link to comment
19 hours ago, doron said:

The "read SMART" thing is essentially Unraid's response to the drive spinning up, rather than the cause of that spin-up.

Note that in your case there seems to be a time gap between the spin-down and "read SMART" messages - like 30 seconds etc. - which usually indicates there's actually some disk activity that spins them up.

From the log snippet you provided, it seems as if only some of the drives spin back up, but not all. If that is indeed the case, I'd probably look for a share or folder that lives specifically on these drives, and try to figure out who accesses this share/folder. Just a thought.

 

OK - with docker turned off - they shut down and then restarted like normal

 

Sep  8 21:39:27 Skynet emhttpd: shcmd (2389481): /etc/rc.d/rc.avahidnsconfd restart
Sep  8 21:39:27 Skynet root: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped
Sep  8 21:39:27 Skynet root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon:  /usr/sbin/avahi-dnsconfd -D
Sep  8 21:39:27 Skynet avahi-dnsconfd[1249]: Successfully connected to Avahi daemon.
Sep  8 21:39:27 Skynet emhttpd: shcmd (2389500): /etc/rc.d/rc.docker stop
Sep  8 21:39:28 Skynet avahi-daemon[1240]: Server startup complete. Host name is Skynet.local. Local service cookie is 4005251448.
Sep  8 21:39:28 Skynet avahi-daemon[1240]: Service "Skynet" (/services/ssh.service) successfully established.
Sep  8 21:39:28 Skynet avahi-daemon[1240]: Service "Skynet" (/services/smb.service) successfully established.
Sep  8 21:39:28 Skynet avahi-daemon[1240]: Service "Skynet" (/services/sftp-ssh.service) successfully established.
Sep  8 21:39:36 Skynet kernel: docker0: port 1(vetha4c41c8) entered disabled state
Sep  8 21:39:36 Skynet kernel: vethc1a2034: renamed from eth0
Sep  8 21:39:36 Skynet avahi-daemon[1240]: Interface vetha4c41c8.IPv6 no longer relevant for mDNS.
Sep  8 21:39:36 Skynet avahi-daemon[1240]: Leaving mDNS multicast group on interface vetha4c41c8.IPv6 with address fe80::30de:2ff:fe28:5b03.
Sep  8 21:39:36 Skynet kernel: docker0: port 1(vetha4c41c8) entered disabled state
Sep  8 21:39:36 Skynet kernel: device vetha4c41c8 left promiscuous mode
Sep  8 21:39:36 Skynet kernel: docker0: port 1(vetha4c41c8) entered disabled state
Sep  8 21:39:36 Skynet avahi-daemon[1240]: Withdrawing address record for fe80::30de:2ff:fe28:5b03 on vetha4c41c8.
Sep  8 21:39:36 Skynet kernel: docker0: port 2(veth356cd27) entered disabled state
Sep  8 21:39:36 Skynet kernel: veth8dee808: renamed from eth0
Sep  8 21:39:36 Skynet avahi-daemon[1240]: Interface veth356cd27.IPv6 no longer relevant for mDNS.
Sep  8 21:39:36 Skynet avahi-daemon[1240]: Leaving mDNS multicast group on interface veth356cd27.IPv6 with address fe80::b021:e2ff:fe8b:ecb7.
Sep  8 21:39:36 Skynet kernel: docker0: port 2(veth356cd27) entered disabled state
Sep  8 21:39:36 Skynet kernel: device veth356cd27 left promiscuous mode
Sep  8 21:39:36 Skynet kernel: docker0: port 2(veth356cd27) entered disabled state
Sep  8 21:39:36 Skynet avahi-daemon[1240]: Withdrawing address record for fe80::b021:e2ff:fe8b:ecb7 on veth356cd27.
Sep  8 21:39:36 Skynet root: stopping dockerd ...
Sep  8 21:39:37 Skynet root: waiting for docker to die ...
Sep  8 21:39:38 Skynet avahi-daemon[1240]: Interface docker0.IPv6 no longer relevant for mDNS.
Sep  8 21:39:38 Skynet avahi-daemon[1240]: Leaving mDNS multicast group on interface docker0.IPv6 with address fe80::42:95ff:fed6:62b.
Sep  8 21:39:38 Skynet avahi-daemon[1240]: Interface docker0.IPv4 no longer relevant for mDNS.
Sep  8 21:39:38 Skynet avahi-daemon[1240]: Leaving mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1.
Sep  8 21:39:38 Skynet avahi-daemon[1240]: Withdrawing address record for fe80::42:95ff:fed6:62b on docker0.
Sep  8 21:39:38 Skynet avahi-daemon[1240]: Withdrawing address record for 172.17.0.1 on docker0.
Sep  8 21:39:38 Skynet emhttpd: shcmd (2389502): umount /var/lib/docker
Sep  8 21:39:38 Skynet emhttpd: spinning down /dev/sdc
Sep  8 21:39:38 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdc
Sep  8 21:39:49 Skynet emhttpd: spinning down /dev/sdd
Sep  8 21:39:49 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdd
Sep  8 21:40:01 Skynet emhttpd: spinning down /dev/sde
Sep  8 21:40:01 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sde
Sep  8 21:40:14 Skynet emhttpd: spinning down /dev/sdg
Sep  8 21:40:14 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdg
Sep  8 21:40:26 Skynet emhttpd: spinning down /dev/sdi
Sep  8 21:40:26 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdi
Sep  8 21:40:38 Skynet nmbd[1207]: [2022/09/08 21:40:38.148858,  0] ../../source3/libsmb/nmblib.c:923(send_udp)
Sep  8 21:40:38 Skynet nmbd[1207]:   Packet send failed to 172.17.255.255(138) ERRNO=Network is unreachable
Sep  8 21:40:40 Skynet emhttpd: spinning down /dev/sdl
Sep  8 21:40:40 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdl
Sep  8 21:40:53 Skynet emhttpd: spinning down /dev/sdn
Sep  8 21:40:53 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdn
Sep  8 21:41:06 Skynet emhttpd: spinning down /dev/sdt
Sep  8 21:41:06 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdt
Sep  8 21:41:18 Skynet emhttpd: spinning down /dev/sdy
Sep  8 21:41:18 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdy
Sep  8 21:41:32 Skynet emhttpd: spinning down /dev/sdz
Sep  8 21:41:32 Skynet SAS Assist v2022.08.02: Spinning down device /dev/sdz
Sep  8 21:42:22 Skynet emhttpd: read SMART /dev/sdc
Sep  8 21:42:36 Skynet emhttpd: read SMART /dev/sdd
Sep  8 21:42:49 Skynet emhttpd: read SMART /dev/sde
Sep  8 21:43:02 Skynet emhttpd: read SMART /dev/sdg
Sep  8 21:43:15 Skynet emhttpd: read SMART /dev/sdi
Sep  8 21:43:28 Skynet emhttpd: read SMART /dev/sdl
Sep  8 21:43:42 Skynet emhttpd: read SMART /dev/sdn
Sep  8 21:43:54 Skynet emhttpd: read SMART /dev/sdt
Sep  8 21:44:08 Skynet emhttpd: read SMART /dev/sdy
Sep  8 21:44:21 Skynet emhttpd: read SMART /dev/sdz
Sep  8 21:44:26 Skynet autofan: Highest disk temp is 104F, adjusting fan speed from: 155 (60% @ 1715rpm) to: 125 (49% @ 1486rpm)

Log size:  
5000
TextErrorWarningSystemArrayLogin
 

now I'm completely stumped hahaha

Link to comment
5 hours ago, cbr600ds2 said:

Sep  8 21:44:26 Skynet autofan: Highest disk temp is 104F, adjusting fan speed from: 155 (60% @ 1715rpm) to: 125 (49% @ 1486rpm)

(...)

now I'm completely stumped hahaha

Don't be. Mystery solved. Indeed, Autofan is doing that. It has a bug which causes SAS drives to be spun up every few minutes. Scroll back in this topic for a full discussion. I actually offered a software fix (pull request pending) but the plugin author hasn't responded.

Link to comment
On 6/19/2022 at 3:28 AM, doron said:

Okay @DavidNguyen, here goes.

 

Again, please note this is not sanctioned by the plugin author and should be considered a hack, just for testing.

Also note that I didn't package it back into plugin format, which means that the change will be lost upon reboot.

 

Attached please find the modified script "autofan".

 

Steps to activate:

- Place the script in /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/

- chmod 755 autofan

- Go to settings, Fan Auto Control, set the function to "Disable", then Apply

- (Make sure process "autofan" is not running)

- Set function back to "Enable", then Apply

 

You should now have autofan function without offending your SAS drives.

 

Please report success / issues.

autofan 13.01 kB · 4 downloads

 Pardon what I'm sure are some extremely stupid questions, but is this a directory you need to make? I cant seem to find where this is to drop the script into. I dont see anything like this when I browse either my shares, my boot flash drive or my cache disk. I assume the plugins are installed in the config folder of my boot flash drive, but I don't see where this directory would be or would be created (I assume this is all going on the flash drive).

 

 

furthermore can I use the userscripts plugin to automate having this run everytime I boot up? I see discussion few posts after this "hack" to fix autofan was posted but unfortunately that is greek to me as well. I dont shut down very often, but I like to streamline where I can as I am such a novice I try to get it running in a fire and forget sort of way.

Link to comment
2 hours ago, Mors said:

 Pardon what I'm sure are some extremely stupid questions, but is this a directory you need to make? I cant seem to find where this is to drop the script into. I dont see anything like this when I browse either my shares, my boot flash drive or my cache disk. I assume the plugins are installed in the config folder of my boot flash drive, but I don't see where this directory would be or would be created (I assume this is all going on the flash drive).

 

 

furthermore can I use the userscripts plugin to automate having this run everytime I boot up? I see discussion few posts after this "hack" to fix autofan was posted but unfortunately that is greek to me as well. I dont shut down very often, but I like to streamline where I can as I am such a novice I try to get it running in a fire and forget sort of way.

You need to put in  /usr/local/emhttp/plugins/dynamix.system.autofan/script it should exist if you have autofan installed.

 

you can add cp and a chmod +x to the go file to install at boot or use a user script.

Link to comment
3 hours ago, SimonF said:

You need to put in  /usr/local/emhttp/plugins/dynamix.system.autofan/script it should exist if you have autofan installed.

 

you can add cp and a chmod +x to the go file to install at boot or use a user script.

 

So excuse my ignorance, but I used Krusader to search for the "emhttp" folder, because thats where I can't seem to go any further.

 

image.png.e8d2fe334d884e3243d30774ffca8538.png

Link to comment
19 hours ago, doron said:

Don't be. Mystery solved. Indeed, Autofan is doing that. It has a bug which causes SAS drives to be spun up every few minutes. Scroll back in this topic for a full discussion. I actually offered a software fix (pull request pending) but the plugin author hasn't responded.

Ahhh -   if I disable autofan then bios will control the fan right?  

 

I was reading your script "hack" and I was wondering if I got this right - then I would have to do this everytime I started the array?  Can it be added to the userscripts plugin? 

Edited by cbr600ds2
more color
Link to comment
7 hours ago, Mors said:

 

So excuse my ignorance, but I used Krusader to search for the "emhttp" folder, because thats where I can't seem to go any further.

 

image.png.e8d2fe334d884e3243d30774ffca8538.png

I think this will be the root fs of the docker not of the host. you may need to add a mapping for the host root.

 

Open a terminal and run  ls /usr/local/emhttp/plugins/dynamix.system.autofan/script

 

Link to comment
3 hours ago, cbr600ds2 said:

Ahhh -   if I disable autofan then bios will control the fan right?  

 

I was reading your script "hack" and I was wondering if I got this right - then I would have to do this everytime I started the array?  Can it be added to the userscripts plugin? 

You can add as a Userscript or I add in my go changes I am testing. I have a temp dir on the boot drive I add files into

 

cp /boot/temp/file /usr/local/emhttp/plugin/pluginname/....

chmod +x /usr/local/emhttp/plugin/pluginname/.... if it need to be executable. 

 

root@computenode:~# cat /boot/config/go
#!/bin/bash
# Start the Management Utility
#sed -i 's/disableLeaveAlert=true/disableLeaveAlert=true -t fontsize=20/' /etc/rc.d/rc.nginx

#cp /boot/temp/ArrayOperation.page /usr/local/emhttp/plugins/dynamix/
#cp /boot/temp/parity_list /usr/local/emhttp/plugins/dynamix/nchan/
#cp /boot/temp/mover /usr/local/sbin
#chmod +x /usr/local/emhttp/plugins/dynamix/nchan/parity_list
#chmod +x /usr/local/sbin/mover
#cp /boot/temp/smartctl_type /usr/local/sbin
#chmod +x /usr/local/sbin/smartctl_type
#cp /boot/temp/sdspin /usr/local/sbin
#chmod +x /usr/local/sbin/sdspin
#cp /boot/temp/smartctl_test /usr/local/sbin
#chmod +x /usr/local/sbin/smartctl_test
cp /boot/temp/cli64 /usr/local/sbin
chmod +x /usr/local/sbin/cli64
cp /boot/temp/mover.php /tmp
chmod +x /tmp/mover.php

/usr/local/sbin/emhttp &
root@computenode:~# 
 

  • Like 1
Link to comment
10 hours ago, SimonF said:

I think this will be the root fs of the docker not of the host. you may need to add a mapping for the host root.

 

Open a terminal and run  ls /usr/local/emhttp/plugins/dynamix.system.autofan/script

 

image.png.696c3b6470f8e22af3bd58004d0fcd3d.png

 

And just to be like confirming I am not an idiot (hopefully), I have both SAS spin down and Auto Fan installed and enabled. You can even see the SAS only not spinning down in my gui.

image.png.910d14096a60ed2472e84c5e4a73517b.png

Those are 2 shucked WD drives, they spin down with no issue.

image.thumb.png.9bd1b5611b626715b837d54b53f0aec7.png

image.thumb.png.e7eb29f6944180dba413ea57dff32be7.png

 

and a picture of my log, the only activity I have is the temp being polled. image.thumb.png.1a1bc3bf1b1fad408aca2ad54b46bb7b.png

Edited by Mors
clarification
Link to comment
2 hours ago, Mors said:

I realized 60 seconds after posting you would ask, and I edited with more info.

See previously in this thread. The autofan plugin has a bug that causes SAS drives (only) to be spun up periodically (every few minutes - basically, the polling interval).

Link to comment
6 hours ago, doron said:

See previously in this thread. The autofan plugin has a bug that causes SAS drives (only) to be spun up periodically (every few minutes - basically, the polling interval).

Yea, I am not confused about any of this. You'd have to read my comments to understand what my issue is, but basically I do not have the directory to put the modified script into, to then fix auto fan (or so it appears to me, I am a linux novice).

Edited by Mors
clarification
Link to comment
3 hours ago, Mors said:

Yea, I am not confused about any of this. You'd have to read my comments to understand what my issue is, but basically I do not have the directory to put the modified script into, to then fix auto fan (or so it appears to me, I am a linux novice).

Sorry for my confusion.

Can you post the output of:

ls -la /usr/local/emhttp/plugins

 

Link to comment
14 hours ago, Mors said:

I realized 60 seconds after posting you would ask, and I edited with more info.

Sorry missed the s off the end.

 

root@Tower:~# cd /usr/local/emhttp/plugins/dynamix.system.autofan/
root@Tower:/usr/local/emhttp/plugins/dynamix.system.autofan# ls
FanSettings.page  README.md  default.cfg  icons/  images/  include/  scripts/
root@Tower:/usr/local/emhttp/plugins/dynamix.system.autofan# ls scripts/
autofan*  rc.autofan*
root@Tower:/usr/local/emhttp/plugins/dynamix.system.autofan# 

 

Edited by SimonF
Link to comment

So everything is working now, I assume somewhere along the way (beyond the typo in SimonF's post, which I didn't catch either) I assume I must have had a typo myself. Though I find it very strange that I can't browse to the folder in Krusader, I am sure I have a setting not checked somewhere.

 

The big thing was finally seeing something about the MC command, which might be second nature to all your Linux guru's but until I remembered that is how you easily navigate and do things like put this script in the folder I felt like I was taking crazy pills a bit. One of those things where there is just so much info, and so many spaceinvader videos, that finding what you're looking for, and I spent a semi long googling and searching around these forums, can end up being quite daunting since you get a lot of relevant but not specific info.

 

Anyways, thanks to both @SimonF and @doron . If I can trouble you for one more question, now that I see what I did, why would you need a script or anything further to make this work everytime on boot? Since we replaced the already used script with your new code, wont this just automatically run on boot since Autofan uses this script?

Link to comment



If I can trouble you for one more question, now that I see what I did, why would you need a script or anything further to make this work everytime on boot? Since we replaced the already used script with your new code, wont this just automatically run on boot since Autofan uses this script?


All these folders are re-created each time you reboot Unraid (technically, all plugins are re-installed on boot). The filesystem you are seeing is in memory. So, yes the hack needs to be replaced each boot.

Good news is that author of autofan has finally picked up my fix and hopefully he will make it into an official fix.

Sent from my tracking device using Tapatalk

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.