Zerginator

I had the problem this week on two completely different UnRaid servers. Only thing in common, I am just using unbalanced to move files on both servers, as I migrate disks from XFS to BTRFS. So might have something to do with unbalanced. Even though I until now usually ran into this problem on one server as soon as I start using virtual machines.

Wow! I have the same issue since 2 years, resulting in having to reboot and check the whole array every some weeks. I was able to recreate for some time that it happens every time I use a virtual machine, but even without it happens every some months. But the symlink recreation is a lifesaver. Works just like a charm. This really is a strange issue.

Thank you, I will try that

I cannot get the script working anymore with Unraid 6.12.8. I finished with successfull after about 30 seconds, leaving the array with in a state with unmounted drive that prevents clean shutdown of the array and enforces a "unclean shutdown detected" parity check. After reboot / array restart the drive is back with the clear-me folder inside.

Same issue happens when using the "clear_array_for_shrink" userscript or removing a disc from the array manually without partity rebuild as to the official guide, as you have to unmount a drive to zero it out. Afterwards the array cannot be stopped, as it gets stuck at trying to unmount the already manually unmounted drive.

Yes, everthing is working perfectly now. Stopping and starting according to temperature works perfect after the fix.

A reboot also fixed the settings window.

Thanks for the suggestion. But that opposite is generally the idea. To have a server that is always on for image uploading, syncthing, webdav, vpn and whatsoever, that is build for low energy consumption (only 2,5" ssd with cache disks, so they are mostly spun down) in a small case. I use the SilverStone SST-CS280 case that is a brilliant micro ATX Case with 8x 2,5" hotswap). Only the cooling is bad, as there is no active fan for the hdds, and using 15mm 5TB disks means they are nearly touching each other leading. The whole setup with a good Core i7 CPU is idling at around 25W consumption and all services (more that 30 docker containers) are always available. I have another server with good cooling, a lot of CPU and graphics power and storage that is only activated on demand.

Yes, everything works just as expected now! The plugin is a have for me, as this server is a low noise/low power always on unit with 2,5" drives. It runs all the daily need containers, and the disks are running perfectly cool in normal usage. 2,5" Laptop disks are just not built for the 24 hour continuous use cycle that happens during a parity check and overheat, so it is the perfect solution for this case. Additional rebuild time does not matter much, as it is dual parity. Maybe the settings issue is gone after reboot, I will report here, when the rebuild is finished.

Just paused correctly at 3° below warning temperature. I noticed a change in the settings to yesterdays version (from beginning of Octobert) the crontab custom settings are not hidden anymore now, when not set to custom. Screenshot of still open tab from before update: Screenshot of settings after update:

I am quite sure it did not work for a long time. I always got lots of disk overheated and critical overheat warnings during partity checks at last during the last 1-2 years. But it paused nevertheless, before it got a real problem (as I see from the code it also has a check for critical temperature). I just happened now, that I had set critical to high accidently, what caused two disks to actually die. Thats when I started to realize that it never should have reached critical at all with the plugin active.

Sure, I will update as soon as you have pushed it and give it a test run.

This is what the PHP Settings error log tells me:

This is the line where the temperature value is triggered

Parity check tuning is not stopping anymore on disk overheat. Everything is activated, but the array rebuild just keeps going. Led to 4 completely overheated disks with Smart failure, as disks are very slowly overheating after some hours and cooling cannot be improved unfortunately