doron

Ah. This might make the testing somewhat less accurate. If the drives are active during the test (with real data moving, or even just filesystem housekeeping), that activity might spin the drive back up while you're waiting between setting and testing. I presume the plugin is installed? You'd not see a "SAS Assist" message if you fiddle with the drives manually. You should see it if, instead, you'd hit the green button next to one of your SAS drives (that are under UD), to cause the drive to spin down. Have you tried that? Do you see a SAS Assist message then? If you do try that, and the GUI does show a grey ball, then chances are it's spun down properly - you can double check with the sense command (without doing the sg_start thing). Thanks for posting! See my first comment above. If you want to further test, you may want to edit the sas-util script, remove (or comment out) the one line that says "sleep 3s" and try again. I'd be curious to see the results. EDIT: Alternatively, you can just try this: sg_start -rp3 /dev/sdb && sdparm -C sense /dev/sdb and show the results.

Thanks for the kind words. What we've been seeing is kind of hit and miss, so no strict verdict re a certain series of HDDs; you may want to just try. Re the specific issue, some of the Seagate documentation seems to imply that power mode 3 (the mode we're setting the drive into) is implemented as needing an explicit command to spin the drive back up. This does not jive too well with how Unraid is expecting things to behave (basically, it is expected that a subsequent i/o to the drive will implicitly spin it back up). Bottom line, you may want to give it a try and see. You can also use the provided sas-util (bundled with the plugin at /usr/local/emhttp/plugins/sas-spindown/sas-util, or you can take it from here), with the parameter "test", to try and predict how things will work. (Unfortunately, even this test is not 100% accurate - I have at least one happy camper whose SAS drives merrily spin down and up with the plugin, but still fail the test...). If you do, please post (or pm) the resulting file. Happy 2021!

Thanks for reporting - that's good to hear. If you could also run: /usr/local/emhttp/plugins/sas-spindown/sas-util and send over the resulting file (pm me or post), that'd be great.

Sure is... Check out the output file (or see below). Thanks for your help! "controller": { "Slot": "01:00.0", "Class": "Serial Attached SCSI controller [0107]", "Vendor": "Broadcom / LSI [1000]", "Device": "SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor] [0064]", "SVendor": "Broadcom / LSI [1000]", "SDevice": "9200-16e 6Gb/s SAS/SATA PCIe x8 External HBA [3030]", "Rev": "02"

Thanks for reporting! I'm really happy to hear that. Would you mind running /usr/local/emhttp/plugins/sas-spindown/sas-util and send me the resulting file (/tmp/sas-util-out)? (when run without parameters it doesn't do anything intrusive, just reports the HDD and controller(s) models in JSON format) You can pm me or post here (no sensitive info such as serial numbers etc. is shared). Thanks

I've just pushed a new version - 0.8 - of the plugin, supporting 6.9.0-rc1 and its new spin up/down mechanisms. As always, please report issues.

Thanks for doing that. That's great news. Unraid (in kernel upto 6.8 and in userspace in the future) looks at i/o activity to determine spin up of a drive.

Thanks for reporting! Happy to hear it worked well for you.

This is essentially what the plugin does when it tries to spin down SAS drives. So either this does nothing in your setup (combination of hard drive and controller), or something else is going on. Could it be that you have constant i/o against the array - in which case, a spun-down drive will immediately spin back up? Do you see i/o counters (read or write) on the main page moving, during that time?

It's identical to pushing the "spin down" button (when the plugin is installed). If there's no massive i/o going on against it, sure.

(sorry for previous misfire, I was reading on a tiny phone) Does this same drive react the same way to direct spindown? e.g.: sg_start -r --pc=3 /dev/sdd sdparm --command=sense /dev/sdd

@nlcjr, can you restart your rsyslog service, then spindown one drive just once, then read sense with sdparm? e.g.: /etc/rc.d/rc.rsyslogd restart mdcmd spindown 2 (wait a couple of seconds, then...) sdparm --command=sense /dev/sdd

Hmm, that Should Not Occur™. Can you share the log lines you get around the time of the spindown (i.e. including and immediately following the "spindown" message for one of your SAS drives)? Do you see any messages at all with "SAS Assist" prefix? Also, can you share your /etc/rsyslog.conf ?

My SAS drives are HUH721212AL4200 and work perfectly with the plugin. (I do suspect that it's not only the drive model but a combination with the controller model as well.)

Could be some other plugins did. It was done out of necessity...

Perfect. Thx. Indeed. BTW my plugin installs a wrapper for smartctl which reinstates the "-n standby" thingie (until smartmontools.org fix it).

Well, this drive is a SATA SSD: /dev/disk/by-id/scsi-1ATA_TS120GSSD220S_<redacted> It is under ESXi though (RDM), so you may think of it as an exception. It does. Thanks. Sure, here you go. This is with -A: smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === Current Drive Temperature: 26 C Drive Trip Temperature: 85 C Manufactured in week 36 of year 2018 Specified cycle count over device lifetime: 50000 Accumulated start-stop cycles: 739 Specified load-unload count over device lifetime: 600000 Accumulated load-unload cycles: 16374 Elements in grown defect list: 0 And this is with -a (little a): smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HGST Product: HUH721212AL4200 Revision: A3D0 Compliance: SPC-4 User Capacity: 12,000,138,625,024 bytes [12.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca2708b9bf8 Serial number: <redacted> Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Sun Nov 22 02:14:43 2020 IST SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled === START OF READ SMART DATA SECTION === SMART Health Status: OK Grown defects during certification <not available> Total blocks reassigned during format <not available> Total new blocks reassigned <not available> Power on minutes since format <not available> Current Drive Temperature: 28 C Drive Trip Temperature: 85 C Manufactured in week 36 of year 2018 Specified cycle count over device lifetime: 50000 Accumulated start-stop cycles: 740 Specified load-unload count over device lifetime: 600000 Accumulated load-unload cycles: 16375 Elements in grown defect list: 0 Vendor (Seagate Cache) information Blocks sent to initiator = 768214057353216 Error counter log: Errors Corrected by Total Correction Gigabytes Total ECC rereads/ errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 0 0 0 0 60350 60070.756 0 write: 0 0 0 0 7 24002.699 0 verify: 0 0 0 0 811 0.000 0 Non-medium error count: 0 SMART Self-test log Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ] Description number (hours) # 1 Background long Completed - 148 - [- - -] # 2 Background short Completed - 128 - [- - -] # 3 Background short Completed - 22 - [- - -] Long (extended) Self-test duration: 65535 seconds [1092.2 minutes] Note that both spin the drive up.

Thanks. I can work with that. Note btw that in this schema, all SAS drives will be "scsi" but not all "scsi" will be SAS. The only dependable way I found to pinpoint a SAS drive is via smartctl -i, parsing out "Transport protocol" - a field which is returned only for SAS drives (an example pasted below). Found nothing similar in neither /sys nor /dev . I'll use that as a filter in the script, ergo "can work with that". smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HGST Product: HUH721212AL4200 Revision: A3D0 Compliance: SPC-4 User Capacity: 12,000,138,625,024 bytes [12.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca2708b9bf8 Serial number: xxxxxxxx Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Sun Nov 22 00:44:17 2020 IST SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled

Hi @limetech - thanks for the heads up! (hehe I was just reading that other thread when your message came in). This sounds cool and exactly the right approach (the plugin will shrink to a few lines but hey - it was supposed to be a temporary stopgap anyway). Getting rid of the syslog dependency would be a blessing (btw I bumped into a few issues with Unraid's handling of rsyslog config but will deal with it in a separate thread - the plugin has an elaborate work around). One question: Where exactly is the value of <transport> derived from for this exercise? Thanks again for doing this.

Thanks for confirming. (still a weird thing that I have never seen elsewhere but...)

So this happens with the plugin installed; and when you remove the plugin - those "spindown 3"/"spindown 4" messages do not appear (or at least not in quick succession)?! If so, this is puzzling and I would like to try to get to the bottom of it. EDIT: I seem to be unable to reproduce it, and also can't see right now how the plugin will cause repeated "mdcmd spindown" to happen.

Okay that's actually a feature. Since your drives clearly can't be spun down properly, the plugin avoids them (they are on the exclude list). If it can't help, at least it avoids collateral damage... Now, when you say "loops" - is there actually an endless loop of "spindown 3" - "spindown 4" - "spindown 3" - "spindown 4" or is this a result of your hitting the green button a few times in a row? Actually, if all your SAS drives are on the exclude list, there's unfortunately little point for you to run this plugin at this time 😞

Just pushed out version 0.7 of the plugin. There are many changes, a few notable ones listed below. The main method of spinning a SAS drive down remains the same - meaning, that if you had issues (or worse, red x's) following spindown attempts in previous versions, there's a good chance this version will not improve this particular situation, so please test with care. - Adapt the syslog hook to various Unraid configs (between Unraid and Dynamix there are several different forms of syslog configs, which vary among them if you config syslog settings, so there's now a mechanism that will reconfigure the hook per different situations and will dynamically respond to changes in settings). @stigs, I'm guessing this might address your issue as well. - Filter out syslog lines (aka "spam"...) from some SAS devices rejecting ATA standby op (e0) - Introduce an exclusion list, which should gradually contain drive/controller combinations that are known to not respond favorably to spindown command - More consistent log messages and tags - Add new debug and testing tools - Many other changes, major code reorg Enjoy! Please report issues (or success).

Thanks for reporting this. The next 0.7 version should(...) address your case. I'll hopefully push in within the next couple days. When you update to it, please report again.

This is weird - unless this reflects your pushing the green buttons for disk 2 and 3 repeatedly several times in quick succession. Is this what happens? BTW these messages are generated due to Unraid trying ATA spindown commands against a SAS drives. The next version of the plugin (I've been sitting on it for a while, hoping to collect more data on drive/controller combos with which there's failures) filters these messages out from your log.