JorgeB

It's been a known issue with that plugin that affects some users.

This is usually a hardware problem, e.g., bad RAM.

this

Xfs_repair looks successful, was the array started in normal mode after the repair? If yes and it didn't mount please post diags.

Not unless you use the --ignore-times flag, then it will only compare sizes, by default rsync doesn't compare contents.

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/

Make sure "Initial Memory" and "Max memory" in the VM options are set to the same value.

Not a big networking guy, but it does look like a network issue, try different cables/switch/NIC.

Try this: https://forums.unraid.net/topic/51703-vm-faq/?do=findComment&comment=557606

It should always resume from where is was, unless the source/dest files modified timestamp changed.

You should backup and re-format the filesystem.

You can try restoring a few config files at a time to see if you can find the problem or just reconfigure the server, for the array assignments you just need to restore super.dat.

Zfs is not (yet) supported by Unraid, you can post in the plugin support thread, might be able to get some help there.

Can't say, maybe with diags after the problem occurs.

It will be the same, Unraid is Linux, though if you use the latest kernel the btrfs tools might be a little better.

Please post the diagnostics after upgrading.

Log is filled with these: Nov 3 14:58:48 mediahub root: error: /plugins/unassigned.devices/UnassignedDevices.php: uninitialized csrf_token Not sure what they mean though, typical error is wrong csrf_token, which means multiple browser windows open, maybe try temporarily uninstalling or re-installing UD.

Because disks are overheating, if any disk is above the set warning temp when the reported is generated it fails.

Improve disk cooling.

lsscsi in the diags lists all the devices and you can crosscheck with the devices letters for example on the SMART reports, parity2 is sdh: [6:0:0:0] disk ATA WDC WD40EFRX-68W 0A80 /dev/sdg /dev/sg7 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/6:0:0:0 [/sys/devices/pci0000:00/0000:00:1c.7/0000:08:00.0/ata5/host6/target6:0:0/6:0:0:0] [6:1:0:0] disk ATA WDC WD120EMFZ-11 0A81 /dev/sdh /dev/sg8 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=1 timeout=30 dir: /sys/bus/scsi/devices/6:1:0:0 [/sys/devices/pci0000:00/0000:00:1c.7/0000:08:00.0/ata5/host6/target6:1:0/6:1:0:0] [6:2:0:0] disk ATA WDC WD120EDAZ-11 0A81 /dev/sdi /dev/sg9 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/6:2:0:0 [/sys/devices/pci0000:00/0000:00:1c.7/0000:08:00.0/ata5/host6/target6:2:0/6:2:0:0] [7:0:0:0] disk ATA WDC WD120EMFZ-11 0A81 /dev/sdj /dev/sg10 state=running queue_depth=32 scsi_level=6 type=0 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/7:0:0:0 [/sys/devices/pci0000:00/0000:00:1c.7/0000:08:00.0/ata6/host7/target7:0:0/7:0:0:0] These are all the disks connected to the Asmedia controller, and parity2 shares the same SATA port (and multiplier) with two other disks, you can see that because they all are under ata5, the one with ata6 is using the other port.

For now only parity2 was out of sync, this suggests it's not a data disk issue or RAM, or both parity drives would be out of sync, I would start by replacing the Asmedia controller using port multipliers, it's generating some ATA errors and it's also not good for performance, and coincidentally or not, parity2 is connected there, if you use a recommended controller it should also improve performance, last check took almost 3 days which is a lot more than it could be, though you were using the array. P.S. please disable mover logging unless needed to troubleshoot the mover, or it generates a lot of log spam.

Yes.

Use -L

Depends on the use cache setting for the share you're writing to, if set to cache=yes or prefer, then yes, it will overflow to the array, assuming enough space there.

Rebuild will re-start from the beginning, you can run the check before re-starting it, or cancel rebuild if array is set to auto start.