doron

Try this: /etc/rc.d/rc.autofan restart

Very good. Now let's hope @bonienl considers adding the code fix into the plugin.

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

@DavidNguyen , meanwhile please keep us posted as to whether disabling the autofan plugin indeed stopped the phenomenon. If you want to test, I can send you a (hacked, unauthorized) code fix for that plugin to try on. Sent from my tracking device using Tapatalk

Hi @bonienl, It seems like this plugin will spin up SAS drives every $INTERVAL minutes. It checks for HD temps, however the test for spun-down status is good for ATA drives and not for SAS drives. I proposed a small code change (pull request onto your repo) to fix this. Thanks for considering it.

Just for the sake of testing, can you disable the System Autofan and System Temp plugins and retry? EDIT: Reading the code of System Autofan, it will definitely spin up SAS drives every $INTERVAL minutes. My guess is that if you disable this plugin, the phenomenon you describe will go away. I will contact the author.

Spinning up a few minutes later would probably be due to some activity against the drive. You may want to check for other plugins, Dockers or VMs that generate periodical I/O against the array. Sent from my tracking device using Tapatalk

Generally speaking, the passphrase is placed in /root/keyfile, but please read the official Unraid docs for the complete picture (there's UI to specify keyfile, etc.)

root@Tower:~# unraid-newenckey -h == unraid-newenckey v0.9, made for Unraid, change encrypted volumes' unlock key. @doron == Usage: unraid-newenckey [current-key-file] [new-key-file] Both positional arguments are optional and may be omitted. If provided, each of them is either the name of a file (containing a passphrase or a binary key), or a single dash (-). For each of the arguments, if it is either omitted or specified as a dash, the respective key will be prompted for interactively. Note: if you provide a key file with a passphrase you later intend to use interactively when starting the array (the typical use case on Unraid), make sure the file does not contain an ending newline. One good way to do that is to use "echo -n", e.g.: echo -n "My Good PassPhrase" > /tmp/mykeyfile root@Tower:~#

Here you go @another_hoarder. To use it, put it anywhere convenient, align permissions (chmod +x generic.wrapper) and then use thusly: generic.wrapper <CommandToBeWrapped> In your case, the command to be wrapped would be smartctl. To remove the wrapper, run the same command again. No warranty, your own risk etc. generic.wrapper

Enabling debug on the plugin will not generate very much output on syslog, if at all (umm, I guess I need to change that). Note however that if you are looking for debug info on spin up, you'd probably not have found it here anyway - the spin ups / SMART reads occur outside of the plugin and unrelated to it. If you want to explore debugging other parts of the system, you might want to wrap smartctl with some debug code, to track calls to it. Let me know if you want to explore that path, I can provide you with a neat little wrapper for that.

rc8 -> stable. No issue. Happy puppy here.

Just upgraded (from rc6). No issues. Thank you!

Updated from rc5. No issues. Looking good, great work.

That may be related to the "smartctl -n" issue spinning up drives. You may want to check 6.10-rc5, which per @SimonF includes an updated version of smartctl which has this issue solved (haven't seen it in the release notes btw).

(sorry for the deleted post) I just pushed out a newer version of the plugin (also with a more a-la-mode version numbering scheme). Should fix this issue - let me know if it does.

Is the time span between spindown and "read SMART" always the same (about 1 min)? Does the same thing happen both when you let the drive spin down "naturally" (i.e. following the Unraid spin down delay) and when you force spin down from the GUI? Could you perhaps have some folder that lives mainly on these drives and sees frequent I/O? Have you tried to upgrade to some 6.10 RC? BTW all my SAS drives are HGST (HUH721212AL4200) with an (onboard) LSI controller and they remain spun down nicely.

In the case above, it seems that the spin-up (read SMART) happens more than a full minute after the spin down. This might be a result of normal I/O (e.g. read) against the array.

Thanks again @SliMatfor setting up the testing lab! It is very much appreciated. Unfortunately the results did not lead to a breakthrough - the controller / drives setup absolutely refused any attempt to put the drives into a "standby_z" (spindown) state. Net-net, I added the HP SAS controller to the exclusion list of the plugin. Thanks!

Wow, thank you for setting all this up! Greatly appreciated. (Continuing via pm.)

Okay this might be a stupid question but sometimes we stumble on these things (I know I do): Are you 100% sure that the USB stick indeed has a volume label of UNRAID?

Sorry, I guess my Hyper-V ignorance is showing... (the screenshot you provided doesn't show the Unraid side.) Anyway, what version of Unraid are you loading? Is it latest (6.10.0-rc4)? I peeked at the kernel 5.15.30 xhci-pci driver and support for your controller seems to be included there, but older versions might not have it (which is one guess as to why Unraid does not see your USB stick). Also - if you have another - different - USB controller on your mobo, which you can free up and use for this, maybe that would also be worth a try.

At this point I'd try to pass the USB device rather than the controller. Sent from my tracking device using Tapatalk

If you use a VMDK copy of the USB, try to 1. Change the label of the VMDK volume to something other than UNRAID 2. Verify that the VM indeed sees both the virtual drive and the USB stick. Sent from my tracking device using Tapatalk

Sounds good. Thanks for your help!