JorgeB

Macvlan call traces are usually the result of dockers with a custom IP address, more info here. For better stability also a good idea to respect max AMD officially supported RAM speed for your config, which is 1333Mhz, not 1600.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

You need to use the latest beta, it can be download from here: https://s3.amazonaws.com/dnld.lime-technology.com/next/unRAIDServer-6.9.0-beta29-x86_64.zip

First check was non correct, second one was correct, no next one should find 0 sync errors.

Yes, cache filesystem is crashing, you need to re-format the pool, some recovery options here if needed.

Yes, overclock and servers not a good combination.

You have to do this, or will need to rebuild the larger disk twice anyway.

Do you mean newer kernel/tools than this beta? df is still working correctly for me: Filesystem Size Used Avail Use% Mounted on /dev/sdf1 1.4T 3.6M 930G 1% /mnt/cache And now the newer btrfs tools in beta29 also support raid5/6: btrfs fi usage -T /mnt/cache Overall: Device size: 1.36TiB Device allocated: 17.06GiB Device unallocated: 1.35TiB Device missing: 0.00B Used: 288.00KiB Free (estimated): 930.15GiB (min: 700.11GiB) Data ratio: 1.50 Metadata ratio: 2.00 Global reserve: 3.25MiB (used: 0.00B) Multiple profiles: no

df reports the correct used and free space for every possible combination (AFAIK) except raid1 with an odd number of devices, but that's a btrfs bug and should be fixed in the near future.

Me too, it could be even better if it was done the same way df does it, but I already made a case for that and apparently it was not good enough.

There was no parity. That's not the problem, problem is that Unraid rejects the disk after a reboot, and worse than that partition is invalid and disk can't be mounted again, it's easy to reproduce if you do the steps I outlined above.

You can only do it with a disabled disk, if it wasn't already you'd need to disable it first, all of that info is in the linked procedure.

Run memtest.

You can use the invalid slot command if you have a spare disk of the same size or larger, I can post the instructions for that. If you can't do it in the GUI disable array auto-start by editing disk.cfg on your flash drive (config/disk.cfg) and changing startArray="yes" to "no".

Best would be to have an appdata backup, then you could restore it, it won't be easy to restore from lost+found folders.

By using the new config with the "trust parity" option, this assuming nothing changed on the array since you added the new parity, still: because of mounting the array without it, even if no data was changed.

New beta was just released:

There's no magic way, you'd need to check folder by folder, "file" command might help identify some of the files.

You shouldn't have done that, it's not possible to successfully sync parity with a failing disk, and now old parity won't be 100% in sync, but it's still your best bet, do a new config with it, check parity is already valid, then do the parity swap.

You need to use the parity swap procedure.

It's not a parity check, it's a parity sync, parity is still invalid, wait for that to finish before doing any heavy i/o on the array.

Post the diags from before rebooting instead.

Great, you should create a thread for updates/support here: https://forums.unraid.net/forum/61-plugin-support/