doron
Community Developer
-
Joined
-
Last visited
Everything posted by doron
-
I didn't see an indication of EPC being disabled in the referenced post, either. The feature is marked supported but not indicated as enabled/disabled. The feature that was indicated as disabled was "Low Current Spinup". This is a Seagate feature that "smoothes" the spin-up process, so the drive does not vibrate and the bearings do not get too stressed up - and in the way, makes the spin up even longer, which is probably what generates the i/o errors. Are you able to test this one? It is described as SeaChest_Configure_xxxx -d /dev/sgYY --lowCurrentSpinup disable
-
Here is what I came up with (for the SAS Spindown plugin diagnostic utility), avoiding caching: echo 1 > /proc/sys/vm/drop_caches # Make sure Linux not reading from cache dd if=/dev/sdX of=/dev/null bs=4K count=1 skip=$(( $RANDOM * 1024 + 1 )) &> /dev/null
-
Thanks @SimonF. Indeed a relevant thread. The suggested solution (or workaround) is to disable EPC. This will alleviate the issue as described, but may also defeat the purpose of spindown; doesn't disabling EPC feature entirely also disable the various power states we're using to spin down drives? At least that is my reading of the docs. I don't have Ironwolf drives to test this, but if I did I'd disable EPC and then try to spin the drive down (use sdspin in 6.9+ or hdparm previously) and check whether it actually did.
-
@half, thanks for reporting. Does this happen with all 8 drives you have (both HGST and Seagate), or just with one brand? If the latter, - which of them works and which doesn't?
-
Is there any i/o going on against this drive (look at the read/write counters) during that time? If there's none, we'd probably conclude that this drive/controller combo ignores the spindown command. If you want to triple check, you may want to run this sequence in quick succession - when there's no i/o happening against the drive: sg_start -rp3 /dev/sde sdparm -C sense /dev/sde If the output is the same as in the previous test, then it's settled 😞
-
Thanks for reporting, @absolute_badger. Might be that this drive / controller combo ignores the spindown command. Right after you spin down, say, /dev/sde, and get the "Spinning down" message from SAS Assist, can you issue, against the same device: sdparm -C sense /dev/sde and post the output?
-
Another data point: I use option "Gmail with TLS" and port 587. Works well.
-
Yes, this is the dreaded 4/11 state, which basically means the drive is at a state that needs an explicit START command to spin back up, and won't spin up automatically upon i/o. Some combinations of drives (mainly Seagate) and controllers give this - Dell controllers like yours are often (though not always) involved - haven't figured out the exact combos yet. Each report like this one enhances the community knowledge... Yeah, that's painful. This is the holy grail I'm after - which drive/ctrl/firmware combinations end up doing this. Have you checked the f/w version on your controller?
-
Thanks for posting, and for PMing the diagnostics. It appears as if the problem occurs only on drives connected to your second controller (The H221). Is that a correct observation? Have you looked at the firmware of this controller? Unrelated, if you're open to testing something with the array stopped, you may want to run the same "sas-util" with one parameter - "test". If you choose to do that (no pressure...), then please PM me the results.
-
On any hypervisor that does not support booting directly from USB, you can try booting from plopkexec.
-
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.
-
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?
-
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"?
-
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?
-
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.
-
Actually that command is supposed to spin a drive back up. I suggested you try it once the state you described occurs.
-
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.
-
Have you been using the SAS Spindown plugin?
-
After some more testing with @greg0986over PM, turns out the issues stem from their Unraid being at a low version. Some binaries the plugin depends on were not installed before version 6.7.0. Plugin updated (v0.84 pushed out yesterday) to require Unraid 6.7.0 as minimum. Thanks @greg0986for the help in this.
-
Okay two different things. Re the NVME - unrelated to the plugin. You want to specify spindown delay of "never" for those, or Unraid will try to spin them down (as you saw) and fail. Re the other thing (Child terminated), will try to figure this out.
-
So now you didn't get the "child terminated" message?!
-
This might indicate a problem in the syslog hook used to trigger spindown in versions below 6.9. - Can you indicate which version of the plugin is installed? - Are you getting any "SAS Assist" messages in your syslog? - Can you do this, from the Unraid CLI: touch /tmp/spindownsas-debug and then try to spin down a SAS drive and paste the resulting syslog excerpt? After doing that you can just rm /tmp/spindownsas-debug To stop the debug messages.
-
Thanks for reporting. Do you see any "SAS Assist" messages in the log? Indeed.
-
This is in fact applicable to all 6.x versions including stable, just thought it'd be nice if it could be fixed in 6.9 (small effort). Issue: Any filter (or other rsyslog script) you deposit in /etc/rsyslog.d/ does not affect the local syslog files. It does affect remote syslog streams, if configured(*). Reason: /etc/rsyslog.conf, as configured by the webGui scripts, looks like this (excerpt): (...) $Umask 0022 # # Include all config files in /etc/rsyslog.d/ # limetech - ok # $IncludeConfig /etc/rsyslog.d/*.conf ############### #### RULES #### ############### # limetech - everything goes to syslog. $RuleSet local *.debug -/var/log/syslog (...) Note that the "$IncludeConfig" directive precedes the "$RuleSet local" directive. This means that when files from /etc/rsyslog.d/ are included, they are applied within the applicable default RuleSet at that moment - "RSYSLOG_DefaultRuleset". The net result is that under the "local" ruleset, the filters are not applied. If the user configures a remote syslog facility, then another section is added to rsyslog.conf, with "$RuleSet remote", within which the content of /etc/rsyslog.d/ is read again(!), so the filters are applied on remote syslog, but not local. Solution: Place the "$RuleSet local" directive above the "$IncludeConfig /etc/rsyslog.d/*.conf" directive. This needs to be fixed in the Dynamix script (syslog setting UI), since the vanilla Unraid /etc/rsyslog.conf seems to not contain $RuleSet directives at all. Sample patch to /etc/local/emhttp/webGui/scripts/rsyslog_config: --- rsyslog_config 2021-01-09 19:02:20.528996624 +0200 +++ rsyslog_config-n 2021-01-09 19:58:06.434929884 +0200 @@ -14,7 +14,7 @@ # create local ruleset if ! grep -q '^\$RuleSet local$' $ETC; then - sed -ri '/^# limetech - everything goes to syslog.$/a$RuleSet local' $ETC + sed -ri '/^# Include all config files/a$RuleSet local' $ETC sed -ri '/^#?\*\.\* @@?.*:[0-9]+$/a$DefaultRuleset local' $ETC fi (*) Actually, the instantiation is a bit more complex: This issue is created only if the user has, at any time, used the Settings/Syslog Server dialog. As distributed, the Unraid /etc/rsyslog.conf does not have a RuleSet configured, so does not have the issue.
-
Sorry, that was my bad. I forgot you're at 6.8.3 (I'm too deep into 6.9 already). Yeah, 6.9 does this for UD as well. Not sure it's gonna help much, given that your drives refuse spin down 🙂 Very helpful. It's an almost definitive testimonial that these Seagates with this controller would not spin down.
