doron

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.

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!

Hi @SimonF, thanks for this. Yes, we played quite extensively with the SCSI options etc. What was new to me was the Seagate toolset. So, Basically, things like SeaChest_PowerControl -d /dev/sgX --spinDown SeaChest_PowerControl -d /dev/sgX --transitionPower standby_z SeaChest_PowerControl -d /dev/sgX --transitionPower sleep With each of which cases - (a) Test that the drive indeed spins down (sense) (b) Issue a direct i/o - read, write - against it, see if it spins up or produces 0x4/0x11. Something like that. Again, my base hypothesis is that the behavior will remain the same - require an explicit "move-to-active" command and returning 4/11 without it - but, who knows, we may be surprised. Edit: ./SeaChest_PowerControl -d /dev/sg8 --checkPowerMode ========================================================================================== SeaChest_PowerControl - Seagate drive utilities - NVMe Enabled Copyright (c) 2014-2021 Seagate Technology LLC and/or its Affiliates, All Rights Reserved SeaChest_PowerControl Version: 3.0.2-2_2_3 X86_64 Build Date: Jun 17 2021 Today: Tue Apr 5 23:11:16 2022 User: root ========================================================================================== /dev/sg8 - HUH721212AL4200 - - SCSI Device is in the Standby_Z state activated by host command

Sure, we can do that. Let's validate first - do we know that these drives do exhibit that behavior? I mean, you did report a 1.2 drive (I presume HP branded) getting this problem. Not all SG drives show this - some behave perfectly. If memory serves, for the most part we've seen this happen on Constellation ES.3 series drives (these are 3.5"). Not sure about these newer Exos series.

What you're seeing is probably quite similar to what others are seeing with some brands of drives/controllers. See quite a few posts in this thread (including my post from a minute ago, just above). If you provide some more info on the failure (drive and controller brand/model, syslog lines at the time of the failure) I'd be able to say more about whether this is a similar mishap (intervention required, drive in standby, ASC/ASCQ 0x4/0x11). Or post diagnostics. But I'm assuming it's the same.

Interesting. I was not aware of this Seagate nomenclature. I've peeked at it now; it seems to be dealing with the power states this plugin is also attempting to deal with. Seagate provides a set of tools of its own to interact with these modes. Specifically, to manipulate PowerChoice modes one needs to use a tool called SeaChest_PowerControl. While I did download and play with this tool, I do not have a single Seagate drive here so what's coming is mostly conjecture. If I had to guess, I'd say that this tool basically issues SCSI commands similar to those issued natively by the plugin. In other words, I'd guess it is a different wrapping for the same basic set of commands. In essence, the problem we keep bumping our head into, mainly with some of the Seagate drives, is that we do manage to spin them down into STANDBY_Z mode; however Unraid i/o logic does not expect to have to explicitly "wake" the drive back up. It expects the drive to spin up automagically next time it gets an active i/o issued at it. And it seems that some drives (again, we've seen that mainly with Seagates but not only - the OEM world is complex as it is so no brand wars please), when they get read or write while spun down, they will return an i/o error (ASC/ASCQ 0x4/0x11 resp.) instead of spinning up. They expect an explicit "move back to ACTIVE" command. That in turn makes Unraid red-x them and boom. If anyone has time and some non-array SG drives to work with me on this, as remote hands, I may be able to allocate some time for this. LMK. But the odds of this bet are slim I think - since it is mainly about whether the drive will auto-spin-up, not whether it will spin down successfully.