doron

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

@Nexal, is there any chance you have a duplicate IP address on your (v)LAN? Someone else using Unraid's assigned IP address?

This might indicate an issue. Can you, on the Unraid console, issue this command: hdparm -y /dev/sdf and post the output? (note the small y, not uppercase Y...)

@zen , please add some more info re this problem. Do they never spin down? Spin down then up again? Logs?... (Edit - sent out prematurely): the plugin is not supposed to interfere with SATA spin down, at all. That said, stuff can happen - but, you said that removing it did not remove the issue, so chances are your issue is elsewhere. Sent from my tracking device using Tapatalk

@Elmojo @Toibs finding who issues i/o activity against your drives can be tricky at times. If you eliminated network drive activity against your shares, try to stop all plugins, Dockers and VM's and see what happens. Then, add them back one by one. You might be able to find the culprit this way. Sent from my tracking device using Tapatalk

@_cjd_some stress is certainly understandable in such situation 😉 At any rate you may have bumped unto an Unraid bug (or feature). It might be good to have the script recommend a server reboot once done.

Thanks @_cjd_ for reporting this. I'm not sure I understand what actually went wrong? Why did the stress happen in the 1st place? Sent from my tracking device using Tapatalk

@Elmojo right, yet it does sometimes take it around two minutes until it spins back up. So, probably activity. Sent from my tracking device using Tapatalk

@Elmojo, from looking at your data, it does seem that your internal ZFS pool (the one we're discussing) is in fact being accessed a short while after being spun down. You can see that the "SMART read" messages (a great indication of a drive being spun up) show up about 1-2 minutes after the respective spin down messages. This, in most cases, indicates some sort of disk activity. The question whether the drive in fact spins down can be answered as follows: 1. Open both a UI and a CLI terminal window, have both ready 2. Push the UI button to spin the drive down, after noting its dev name 3. Immediately thereafter (don't wait too long), issue, on the CLI terminal, this command: sdparm -C sense /dev/sdX replace sdX with the actual device name. If the drive is spun down, you will see the word "standby" somewhere on the sense data.

Thanks @Elmojo . One further question: which are the zfs devices? Re the SMART thing, this is in fact a *result* of the drive being spun up, rather than the cause, so, no... Sent from my tracking device using Tapatalk

Some quick questions: 1. Under normal operation, are you seeing log messages with "SAS Assist" prefix? 2. When you manually spin down your zfs pool, are you seeing any? Can you post them? 3. Can you post the output of ls -la /dev/disk/by-path (Or, you can just post diagnostics) Sent from my tracking device using Tapatalk

Let's break this into parts: If the re-spin happens within a few minutes (rather than a couple of seconds), then it's almost certain that either (a) someone is issuing i/o against the drive or (b) some plug-in has waken up and is spinning the drive up, either rightly or erroneously (we've seen both - e.g. an old version of the autofan plugin used to do the wrong thing when inquiring about the drives, which would wake up all SAS drives). Have you looked at your plugins? Can you disable them all and try? Then, if the issue goes away, you can add them back one by one. Ah. That is unrelated to the above and seems to indicate an issue with that script. It may be incompatible with your controller, other firmware or kernel version. I'll look into that later but the actual plugin code is unrelated (and does not use this method to detect SAS drives - proof is: You do get the "SAS Assist" messages, meaning that the plugin has indeed acted on your SAS drives). Ah, Dell servers. Gotta love them (I do, actually), but they have so many firmware layers that you can sometimes lose track of who did what... I do hope it is not some firmware code that causes the drives to spin up. I wouldn't bother with the IT mode thing; you do have it in HBA mode which is what we need. We've seen issues with Seagate drives not spinning down. However, having them spin up after a few minutes is not one of them.

And, per the subject of this thread, can you check whether there's power in pin 3? Not being familiar with this enclosure, - could it be the culprit? (if the drives are SATA and the backplane is dual SAS/SATA, as your backplane seems to be, then essentially there shouldn't be a need to go for a SAS controller.)

Which drives are you using? What backplane?