doron

Thanks @SimonF , that's interesting. It may well be related to some of the cases. I believe the plugin code already avoids smartctl for some of the functions due to something similar, I'll check when I get home. It would be good if the patched smartctl finds itself in the next RC. Sent from my tracking device using Tapatalk

Unfortunately there's not much more I can suggest. Many Seagate drives have demonstrated erratic results wrt standby/spindown. I don't know of a reliable way around it. Sent from my tracking device using Tapatalk

If you do, please report your results here - it may help other users in the future. Sent from my tracking device using Tapatalk

Ah I missed the fact they are all tied to a single controller. In that case we must conclude that the specific drive (ST33000650SS) does not interpret the spin down commands as expected. Unfortunately there is no "standard behavior" re this. Newer Seagate drives tend to do the right thing, quite a few older ones do not. Your drive seems to have been pulled from an Adaptec system, which may or may not have to do with this issue. There's a slight chance that updating the drive's firmware will help, but I can't guarantee it will (or that you won't end up with a bricked drive), so weigh your risk. If you try this, you may want to check out this. I have not tried it, and it seems to be specifically not intended for Adaptec OEM drives, but who knows.

Can you specify the exact model of the drive, and the models of the two controllers - the one that "does the right thing" and the one that does not?

What you bumped into is called "A Bug" 🙂 I got confused for a moment since you are posting about v0.8, which is not posted via this thread, but rather via a plugin - kind of work-in-progress that I started on September and never properly completed. At any rate, I just posted plugin v0.9, with that bug resolved. @Towley, could you please confirm that the problem is resolved? Thanks! The file content is your key once you use a file. If you put "test1" in it, that becomes your passphrase. One important thing to note is the ending newline. Type unraid-newenckey -h and read the last paragraph.

babaa abbab babaa ! Sent from my tracking device using Tapatalk

3d indeed

Quite an elusive issue. My drives are old WD and newer HGST and I don't see that problem at all, neither in 6.9 nor in 6.10-rc1/2. Sent from my tracking device using Tapatalk

Just to clarify, this appears to be unrelated to the plugin, and applies to both SATA and SAS drives. Those drives (mainly Seagates) are spun up soon after being spun down. Seems to be kernel related, though not sure. Sent from my tracking device using Tapatalk

I seem to not be able to reproduce. Can you expand on what was the issue you saw? Can you paste the error here?

Ouch. Shouldn't have happened. Will fix when I get a chance (on the road now). Workaround is to use key files. Place old and new passphrases in key files and do the swap. Mind the ending newline (see doc). Keep the "new" key file safe until you are sure you can unlock interactively! Sent from my tracking device using Tapatalk

You are very welcome - thanks for reporting success.

Do you see a "SAS Assist" message about spinning the drive down, and then immediately thereafter a message about reading SMART? There was an issue that started in 6.9.2 (vs. 6.9.1), where some drives are spinning down and immediately back up. It seems to be a kernel issue, I'm not sure it's been resolved yet. It was reported against both SAS and SATA drives.

If you get the i/o errors mentioned above on an array drive, the drive will need a reboot to resume operation (the message is not a warning). So, no. Sent from my tracking device using Tapatalk

Indeed, @madejackson and @francishefeng59, unfortunately some SAS drives (mostly reported with Seagates but with some others as well) do not respond as expected to the spin-down (aka STANDBY) command and require an explicit wake-up call, which is not really applicable in the Unraid realm (expected behavior: Spin up automatically upon next i/o). The result is typically an i/o error with sense 0x2 and ASC/ASCQ 0x4/0x11, recoverable only upon a reboot. I've made some attempts to map the bad actors (seems to be drive+controller related) and exclude them, but can't say it was an overwhelming success. So this is where we stand right now.

Just installed and everything is looking perfect - thanks again @StevenD! This is awesome.

The latter might be related to different work profiles (e.g. often-written files or folders on this sdg drive, etc.). To eliminate that I'd swap cables / ports with the other ones and see whether issue stays with dev (i.e. sdg) or with drive (i.e. S/N / Unraid slot).

And nothing else has changed?

It appears as though your drive misbehaves per the spin down process. "LU not ready, intervention required" means it is spun down and does not spin up automatically when an i/o is directed at it. This piece is kind of vaguely defined in the SAS protocols and different drive/ctrl/firmware combos provide different results. Your downgrading to p16 might have something to do with that.

Your unassigned drives will probably find themselves listed in /var/local/emhttp/devs.ini in a similar manner. Good luck!

If you can parse /var/local/emhttp/disks.ini you should be on the right track.

Understood. Thanks for all your good work on this.

Any news re this?