PeteAsking

Cool, glad it worked out for you man. Hopefully it can work nicely in the meantime and when you upgrade to sata etc it all goes smoothly too. Enjoy the rest of the day running Unraid

No worries. The drives are running over USB so we will just have to be patient. Hopefully we can speak again in 24 hours time with some good news

Maybe do a memtest just to be safe its not ram, its unlikely but no harm in doing a quick check?

No probs. I hope it completes. Let us all know the outcome so we can all learn from it

If you are connecting to the internal (lan) address via ssh then for sure its being routed via the openvpn tunnel. As no ports are open on the router I imagine this is how you connect.

Still sounds secure to me. Openvpn is pretty good.

Sounds pretty secure to me

Yes this would be better and also improve the speed of the disks as they will currently all run and be limited to the speed of the parity disk - in this shared bandwidth mode would possibly be a bottleneck. If you can move it to the SATA channel then likely speed will improve and possibly also fix your issue. You should test it as it avoids purchasing anything additional or new.

No problem, since this wont change anything I am wondering if we can suggest some other way of fixing the issue. Is the parity drive separate or also in the USB enclosure? It would be better if the parity disk was on its own channel somehow rather than also being in the enclosure. (Even if just on its own in the other USB port).

In disk settings make sure its set to read/modify/write (default) rather than reconstruct write. If you never changed this then its already set like that.

This might be unrelated but in that setup check you are not using turbo write as it will slow down disk speeds overall as they are on shared bandwidth. If you are not using that feel free to ignore me

Thank you.

Try toggling the Setting to performance then powersave in the ca tweak plugin and see if it fixes it for you also. If it does then its the same thing for a bunch of people

“Watch lscpu”

The seagate has a high seek error rate but I dont really understand how to interpret that, maybe someone else knows if thats normal or bad: Seek_Error_Rate POSR-- 085 060 045 - 352968323

I do not know what commands the ca Tweaks community app runs to set this feature, but that would be a suitable workaround if it is not considered a problem and needing of a fix

It is strange. It must be some sort of bug. I have also noticed that since doing this and having it set to powersave correctly now, my drive temperatures have dropped 2-3 degrees each so this is something I will have to do each reboot for now. Luckily I dont reboot often. -P

I also cannot reboot my Unraid machine. I am currently doing a power off and then using WOL to turn it back on as a workaround. This requires a seperate device to complete this though.

Hi, I just tested this on 6.8.1 after rebooting (tweaks CA plugin had powersave set as governor). After reboot I logged in and ran “watch lscpu” This allowed me to watch CPU frequency and assess it compared to expected fluctuations. The values were higher than I expected. Via gui CA plugin I then changed to performance, saved. Noted lscpu output did not change. Set back to powersave and saved. Noted lscpu output now scales back CPU more aggressively. This action must be performed each reboot to gain power savings. p

Thank you @bastl

Hello, I am confused as to how this is functioning. Does it function like Veeam Backup where it snapshots then creates a backup (and there are two files during this period) and at the end of the backup it writes back the changes to the original disk from the delta file so we are left with just one disk file again, or is it creating additional disk files each time the backup runs and never writing the changes back so we just have a single disk image each backup and are ending up with multiple files over time? Sorry if this is already answered but it was not clear to me. P