doron

Was this done with the plugin installed and the debug set as you described above? (I expected another debug message - it might be that one of the above conditions is not met) At any rate, this seems to show that your drive is not really being spun down.

Good (actually one of those would have sufficed, but that's fine). You may want to try (with the plugin installed, and when there's no i/o against that drive): sdspin /dev/sdb down echo $? sdspin /dev/sdb echo $? and post output.

What version of Unraid are you running? 😀 How did you set the debug on? Did you modify the code or use one of the debug triggers?

You did specify "count=10" which makes that 10 such blocks times 5 iterations...

Note the first line in my suggested code above: echo 1 > /proc/sys/vm/drop_caches # Make sure Linux not reading from cache This causes the kernel to drop all page caches so the chances of reading a cached buffer decrease dramatically. You'd then not need to read 50 (potentially massive) blocks each time... Note all kernel page caches are dropped (cleared), not just one device's, so you don't want to do this too often. (Purists will echo "3" and not "1" but that would be going over the top IMHO).

Probably because: --lowCurrentSpinup [ low | ultra | disable ] (SATA Only) (Seagate Only) 😞

This has not been working since 6.4.0 at least (when bzmodules was introduced). I put some effort into retrofitting it to 6.8 but it ended up not being feasible. With the changes in 6.9 it might be feasible again - I may have a look when I have some time (assuming no one does it sooner 🙂 ). EDIT: I misspoke. I don't see that the 6.9 changes make this approach more feasible. bzmodules is still separate and needs to be pulled from the USB drive before hard drives can be accessed. This means that the only thing that can be read from HDD during bootstrap is the bootstrap code and the kernel data set (bzimage). Since no HDD access is built into that set, further bootstrap must read from USB. If anyone wants to further play with that, there's an unfinished version at https://github.com/doron1/unRAID-bzoverlay . Play at your very own risk 🙂

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.

@limetech- any chance this can be prioritized in? Thanks!

Works just fine for me as well. All RCs and final. You may want to share your esxi version and h/w setup.

Please post diagnostics, or at least the syslog from boot time. It might be a driver issue (perhaps for the IOM6), but this will be visible in the log.

6.9.0-rc2 -> 6.9.0, smooth, no issues. One tiny data point: After the upgrade, I received three notice messages for 3 of my drives: "Notice [TOWER] - Disk 3 returned to normal utilization level" I never saw a warning state while in previous versions. Have the default utilization thresholds changed? Great job, Limetech folks!!

@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?

I've built a workaround in the SAS Spindown plugin, when latter is installed in versions 6.7-6.8. The workaround is complex and rather involved, to make sure it's "safe" even if the user reconfigures the syslog settings in the webGui (e.g. includes a background process that waits on modifications to syslog.conf and, when triggered, reconfigures the filters). While it's done and working quite elegantly, I'd not recommend going that path. This is really quite broken right now, so if it can be fixed in 6.9 it would be great.

No it doesn't! My wording may have been confusing - sorry about that, I now see that my text in parenthesis can be read in two different ways... The encryption key does NOT live on the USB by default - the default is to type in it during array startup. IF one does choose to use a keyfile, AND that keyfile is stored on the USB drive - THEN the rest applies. Hope I'm more clear now... No it does not, see above.

If your primary security concern is the USB drive, and your drive encryption key is not stored on the USB (which is the usual Unraid use case), then yes, this method does mitigate that threat. [An ever-so-slightly-simpler way, if you're already keeping a file per program/docker, is to have that file be a script, which will just output the key/passphrase to stdout (as in "echo" or "printf"). Then, you just include it as "... TOKEN=$(/path/to/script) ]

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 😞

It all depends on your threat model. What is the attack (or leak) scenario you are concerned with? Who is the potential attacker? For some scenarios, I can't see why your solution is better than just keeping the secrets on your USB flash (i.e. somewhere under /boot). For yet other scenarios, it might actually be better. Note btw that the way you currently do it, a "ps" command would reveal the secret - try, in your case: ps ax | grep docker This may or may not be a problem (basically if someone is at the CLI level she can peek into your "keys" share) so again, all depends on your threat model.

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?

At any rate, the SAS Spindown plugin is available for 6.9 (rc and final when available), providing the same functionality. It will remain available until unraid provides this organically.

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.