doron

Community Developer
  • Posts

    582
  • Joined

  • Last visited

  • Days Won

    3

doron last won the day on September 20 2020

doron had the most liked content!

2 Followers

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

doron's Achievements

Enthusiast

Enthusiast (6/14)

102

Reputation

1

Community Answers

  1. Suggest you add one more line after that: /etc/rc.d/rc.autofan restart Sent from my tracking device using Tapatalk
  2. All these folders are re-created each time you reboot Unraid (technically, all plugins are re-installed on boot). The filesystem you are seeing is in memory. So, yes the hack needs to be replaced each boot. Good news is that author of autofan has finally picked up my fix and hopefully he will make it into an official fix. Sent from my tracking device using Tapatalk
  3. Sorry for my confusion. Can you post the output of: ls -la /usr/local/emhttp/plugins
  4. See previously in this thread. The autofan plugin has a bug that causes SAS drives (only) to be spun up periodically (every few minutes - basically, the polling interval).
  5. Don't be. Mystery solved. Indeed, Autofan is doing that. It has a bug which causes SAS drives to be spun up every few minutes. Scroll back in this topic for a full discussion. I actually offered a software fix (pull request pending) but the plugin author hasn't responded.
  6. The "read SMART" thing is essentially Unraid's response to the drive spinning up, rather than the cause of that spin-up. Note that in your case there seems to be a time gap between the spin-down and "read SMART" messages - like 30 seconds etc. - which usually indicates there's actually some disk activity that spins them up. From the log snippet you provided, it seems as if only some of the drives spin back up, but not all. If that is indeed the case, I'd probably look for a share or folder that lives specifically on these drives, and try to figure out who accesses this share/folder. Just a thought.
  7. One solution is using something like Veracrypt. Essentially, it creates an encrypted virtual drive. You create this drive once - any size - with a decent passphrase or key, and then mount it on the client machine (Windows, Linux, MacOS etc. - even FreeBSD 🙂 ). On Windows, you will see it as a drive letter. You can create any number of these as you like - and mount more than one, simultaneously. One big v-drive to back them all up, or several smaller ones. Without the passphrase, you will not be able to access the contents.
  8. Release Candidate. Kind of better than Beta, not yet GA.
  9. Doesn't look like you necessarily have an issue - more like there's i/o activity against your drives. Could be either access to data from a client, or a plugin / docker etc. Note the SMART message is not a trigger - it's a response to Unraid seeing (or believing) the drive being spun up. More importantly, note there's a time gap between your spin-down and the SMART messages - a few minutes. That may well reflect normal drive activity.
  10. Took a peek, seems like the media_build process pulls older versions of some kernel code, specifically mceusb.c. Check out e.g. here.
  11. Hi @ich777 , I see that the latest release (for 6.11.0--rc4) does not contain the tbsos drivers. Is there a problem with them for that kernel? I can't upgrade to rc4 without the tbsos drivers 😞 Thanks!!
  12. Just to make sure, can you start your server without plugins "Network Stats" and "Recycle Bin" and see if the issue persists?
  13. Thanks @trurl. Much appreciated and apologies for that. Your findings are aligned with the initial description (btw, being author of SAS Spindown plugin, I have some mileage of intimacy with these drives 🙂 ). Trying to prioritize the burning situation here, I'd like to put aside, for the moment, the reason for parity2's failure (I'll deal with it later), and focus on the operational, Unraid-specific question: At this state, am I right in assuming disk3 is indeed fully rebuilt? Will stopping the futile "rebuild" process right now, doing a New Config without parity2 and with "parity assumed valid", return the array to a stable, protected state? (then, I will deal with parity2 and probably rebuild it, but I will have a protected array). Thanks!
  14. D3 is the one that's invalid (as you say, this is expected). Q is disabled (DISK_DSBL). Here. Thanks.
  15. Yes, that's what it started doing, but Q is DSBL right now so it just reads stuff and writes nothing. Recommendation? (a) Just wait for it to finish doing nothing for the next ~20 hours and then rebuild Q or (b) do a New Config assuming D3 is indeed good vis-a-vis P (taking Q out of the game)? BTW I do think this is a bug worth addressing. But currently I'm with the operational questions.