JorgeB

Yes, it was a correcting check, run two consecutive correcting checks without rebooting, if the second one still finds errors there's likely a hardware issue, most commonly is bad RAM, but could also be controller/disc related.

By looking at the syslog, any sync errors will be logged as "incorrect" for non correcting check, and "corrected" for a correcting check.

Some (or a lot) of the data in disk3 is likely corrupt, if you have backups, yes delete everything and restore, so you know everything is OK, if you don't some corruption might be better than no data at all, you should really understand how parity in Unraid works, things would make more sense. https://wiki.unraid.net/Parity#How_parity_works

Perfectly normal, up to a few thousand can be normal, depends if the array was writing during the shutdown. Auto-parity check after an unclean shutdown is always non correct.

Parity would be still be (mostly) valid if there weren't any writes to the array after you started rebuilding disk5.

Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Yes, If you can restore the data from backups.

You can try this but it will only work if parity is still valid: -Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments and assign any missing disk(s) if needed, including the new disk you want to rebuild, replacement disk should be same size or larger than the old one -IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked) -Stop array -Unassign disk6 -Start array (in normal mode now), ideally the emulated disk will now mount and contents look correct, if it doesn't you should run a filesystem check on the emulated disk -If the emulated disk mounts and contents look correct stop the array -Re-assign disk6 and start array to begin.

Shame, it was worth a try.

The problem was not xfs_repair, it was the rebuild:

If disk2 is the unassigned 4TB Seagate you should be able to mount it outside the array, if it looks fine you can do a new config with it, note that disk3 will likely have some corruption due to the read errors during the rebuild.

https://forums.unraid.net/bug-reports/stable-releases/683-shfs-error-results-in-lost-mntuser-r939/ Some workarounds discussed there, mostly disable NFS if not needed or you can change everything to SMB.

User shares performance with small files has noticeable decreased with each new release, I posted a comparison about that somewhere but can't find it right now, since you've gone from v6.3 directly to v6.9 I would expect it to be more noticeable.

Looks more like a cable/connection problem, Samsung SSDs are notoriously picky with SATA cable quality, try replacing or swapping it.

It doesn't, it has to do with RAM cache for writes. Those are the defaults.

The diags you posted are after rebooting so we can't see exactly what happened, but the rebuild is not doing fine, you only have one parity drive, if there were errors during the rebuild in another disk the rebuilt disk will be corrupt, and by the description looks like disk2 dropped offline, so there would be a lot of corruption.

Yes.

Start by upgrading to latest, also check this if you haven't yet.

No one before complained of the same, and I just tried on a new VM using the newest VirtIO driver ISO and still works, so you must be doing something wrong: Double check the procedure

It does for me using the virtio-scsi driver, try with that one, driver is inside the amd64 folder.

Sorry if this was already suggested, I don't remember, but there have been some reports where it helps for servers with lots of RAM, install the Tips and Tweaks plugin and set "vm.dirty_background_ratio" to 1 and "vm.dirty_ratio" to 2, then test to see if it makes it any better.

This was caused by the quite common controller issue with some Ryzen boards, looks for a BIOS update, it's been reported to help, if not consider getting an add-on controller.

Not for disks, unless with many of them on some 12Gb HBAs using expanders .

For writes yes, for reads they would still be SSD fast.

Nov 7 10:54:15 Home-Server kernel: macvlan_broadcast+0x116/0x144 [macvlan] Nov 7 10:54:15 Home-Server kernel: macvlan_process_broadcast+0xc7/0x10b [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/