doron

Like in other cases reported here, seems like something is spinning this drive back up right after it's being spun down. That could be code in UD (scanning?), in which I'm not too fluent. Will try to take a look later. Couple of complement questions - just ruling out different angles: - Do you have other, non SAS drives in your UD? If so, do they spin down properly and stay spun down? - Do you perhaps have this drive mounted with a file system that's being used?

What do you see in the log when you try to spin it down? Do you get a "spinning down" message? Do you get any "SAS Assist" message?

What hard drives do you have in your UD where you experience this?

Thanks for reporting. Indeed, people had mixed success with these Seagate drives. Can you provide some more detail - do the SAS drives spin down and immediately back up? Not spinning down at all? How are you determining that they are not spinning down?

Okay I think I see what's going on. Would you be open to test a bit of code for me, to see if it helps any? (standard disclaimer - this would be untested so expect the unexpected etc.). If you would, I'll send you the instructions privately.

Yes, I should have been more precise with the question at the end. During the time it went without an occurrence, - do you know for a fact that these particular drives actually spun down, at any time, and subsequently woke up successfully? (looking at the diag you sent, your array seems quite busy, so the question might be not as far out as it seems).

Hi @rabidfibersquirrel, I missed your previous posts. Unfortunately the "Spin Down" notion is not defined well enough in the SCSI/SAS realm. So different drives (or drive/controller combos) implement it in subtly different ways. Essentially, the functionality we're after is "temporarily stop the spindle, automatically spin it up the next time I/O hits the LUN". Turns out that the latter part (spin back up automatically, i.e. without getting an explicit "spin up" command) is inconsistent among drive vendors (maybe even firmware versions). So in some cases, better known of them are some series from Seagate and some Toshibas, expect an explicit command to spin back up. Lacking that command, the next read or write against the drive will get an I/O error. Common errors are: Sense=0x2, ASC=0x4, ASCQ=0x2 Sense=0x2, ASC=0x4, ASCQ=0x11 which basically mean that the LUN is ready but waiting to be explicitly initialized/spun up. This is what happened in your case: Once these drives were spun down, the next time Unraid tried to write to them - boom. For a while I was trying to collect data from users with such issues, adding drives or drive/ctrl combos to an "exclusions" database in the plugin, so that the plugin will not try to spin these drives down (but at least not get the drives into the dreaded Red-x). The MG06 is on the list, the MG09 is not (yet?). I can add it in - assuming this behavior is consistent. Is it?

@valiente, can you, after the device spins back up (ie after the SMART message), issue, again, only the last part of the command (the "sdparm -C sense /dev/sdi" part) and post the result?

Are these your only SAS drives? The rest of your drives are SATA? You do realize that this plugin affects only SAS drives; it does not act on non-SAS drives. This seems to indicate that there's activity against /dev/sdi, which wakes it up shortly after spinning down. Always 23-24 seconds later. Have you tried to monitor the disk activity? Can you run this command in its entirety on your console, at a time you believe there should be no disk activity, and post the results? sg_start -rp3 /dev/sdi && sleep 4s && sdparm -C sense /dev/sdi

Can you please send the contents of the files: /usr/local/emhttp/plugins/sas-spindown/drive-types /usr/local/sbin/sdspin and also, run the command: /usr/local/emhttp/plugins/sas-spindown/sas-util and send the output you get, and also the content of the resulting file: /tmp/sas-util.out

Please post some tech details about the issue, at least a syslog excerpt from around the time of auto spin down/up, but much preferably, diagnostics.

In that case yes, the guidance above holds. The "lsblk" filter will list the devices that are candidates for the transaction. The array must be started. The parity drives will not be on that list.

@Teemanyou now have a plugin that takes care of that.

What controller are these drives connected to?

Thanks. So either it's mentioned in your repo, in which case I missed it and I apologize, or it would be good to add this in, as info. Again, many thanks for making this plugin!!

Thanks for making the plugin. Just curious - the repo is binary only? Any reason?

I found the problem and a fix has been posted (plugin). Essentially, LUKS/cryptsetup limits typed-in passphrases to 512 bytes, and silently truncates anything longer; but only with typed-in passphrases, not with phrases passed via key files. So basically if you type in an 800-byte string, your actual key is made of just the first 512 bytes of that. If you pass the same 800-byte key via a key file, all 800 bytes are used to generate your key, which is obviously different. The update makes the tool's behavior consistent with cryptsetup and WebGui. Typed/pasted passphrases are truncated at 512 bytes, keyfiles are used as they are. Thanks @skobixfor helping with this!

Indeed. Something doesn't add up, however you can now rest assured this is fixable (worst case I'll guide you through doing this using bare tools - now that we know you can open the box). But I need to figure out what's messing this up. Can you please do this (with your actual key of course): echo '123@your!key' > k1 echo -n '123@your!key' > k2 cryptsetup luksOpen --test-passphrase --key-file k1 /dev/md1p1 cryptsetup luksOpen --test-passphrase --key-file k2 /dev/md1p1 and let me know which of them, if any, worked (i.e. gave no error message as in the previous test)?

Don't be. We need to track this down. I presume you tried this both with and without the "-n" flag? If not, please do. When you start the array, how exactly are you providing the passphrase? Are you copying it from a file? From the 1Password application? How exactly are you pasting it? (I'm asking about when the passphrase is actually accepted and works for you.) Another thing to try, meanwhile: cryptsetup luksOpen --test-passphrase /dev/md1p1 cryptsetup luksOpen --test-passphrase /dev/md1p1 you will be prompted for your passphrase; try to provide it exactly the same way you provide it when you start the array.

My apologies. Please use single quotes, not double quotes.

(EDITED: I misspoke below, now corrected for future readers) First of all, if you have a working passphrase (i.e. you can unlock the array with your current key), do not reformat. No reason to - you have access to the encrypted array. We just need to figure out what's going on. That would depend on exactly how you copied your passphrase into the text file. Often has to do with the trailing newline char, but not always. Read on. Ah. Probably not the best way to go about this 🙂 Line feeds, new lines, potato/potato. (Actually Notepad++ can be told to create Unix style files but never mind that). Okay. This is just because you have not quoted the string, and some characters trigger the shell's builtin functions. Not to worry. For starters, please try three things, in order of your own preference: 1. Use an editor on the Unraid Linux console to generate the keyfile. You can use vi or nano (probably the latter would be more accessible if you're less familiar with the Linux CLI). Save it, then try it with the unraid-newenckey tool. 2. Use the echo command above, but quoting your passphrase with single quotes. Like so: echo -n '123My!Pass!Phrase?' > keyfile 3. If #2 above does not unlock, try the same command but drop the "-n" flag. Chances are, one of these will work. Please report back (if it works, let me know which one it was).

Your array should be able to survive the move from bare metal to VM intact, provided your hypervisor allows for HDD and/or HBA passthrough (I believe all of them do). "Without too much fuss" - now that's a relative notion... depends on your pov. You will need to pass the full devices thru (and not have them virtualized!), take great care to maintain the original order, etc. It's doable, I've done it (as did quite a few others), it just needs to be done carefully. Bottom line: 1. It's doable. 2. Amount of fuss - "it depends". 3. Not Supported. Unraid does not officially support virtualized configurations. Many people - myself included - have been running this way for many years and it's been rock solid, but you do need to be aware of that - e.g. if you open a support case, Limetech will expect to be able to replicate the problem on bare metal.

That text means that the plugin enhances the built-in sdspin function, which handles SATA drives spin down, with SAS support. sdspin was introduced around version 6.9.0 of Unraid. Sent from my tracking device using Tapatalk

Can you provide some details about your hba and your SAS-SATA connector? Sent from my tracking device using Tapatalk

You may want to check your cooling. Depending on physical environment etc., a properly cooled drive that's spun up but idle would not typically average at these temps. Sent from my tracking device using Tapatalk