JorgeB

You can do a new config then check "parity is already valid" before array start.

If no checksum errors were found you can have confidence that the data is OK, so just correct parity.

Looks clean so far.

Check/replace cables on disk1, also check filesystem on disk2.

So far I haven't found any corruption signs on Dell Servers with these NICs, so it *might* be safe to use vt-d, see below how you can do that: https://forums.unraid.net/bug-reports/stable-releases/after-i-upgraded-to-6102-my-network-interfaces-dissappeared-r1956/?do=findComment&comment=19584

You need to either disable vt-d or unblacklist the NIC, Dell servers appear to not have the corruption issue, so it *might* be OK to use the NIC, you can to that by doing this: https://forums.unraid.net/bug-reports/stable-releases/after-i-upgraded-to-6102-my-network-interfaces-dissappeared-r1956/?do=findComment&comment=19584

If you don't have a NIC that uses the tg3 driver you can, if you have one it might be safer for now to leave disable, at least until we get to the bottom of exactly what causes the problem.

bnx2 is fine, even tg3 with Dell might be fine, at least didn't find any issues with one so far.

You don't have a NIC the uses the tg3 driver, so unrelated to this, could be a network config issue.

You can also just disable vt-d by adding 'intel_iommu=off' to syslinux.cfg, see how to here.

As you mention the GPUs are being detected, you should post this in the Nvidia plugin support thread.

If you have doubts how to check if your hardware is affected or workaround this please post the diagnostics.

With v6.9.x it won't even ask you to create a password, and can't see how it would ask for the old password after just copying the key.

That is a 1st gen Seagate SMR drive, never had one but remember reading write performance isn't great, 2nd gen Seagate drives like the ST8000AS0002 usually perform well enough with Unraid, the ones I have are about as fast as normal CMR drives for most cases, Toshiba and WD SMR drives (and possibly other Seagate models) don't perform as well, I have an array with Toshiba drives that frequently slows down to 5MB/s for writes.

Do you need a HBA for the 15 drives or will you also be using onboard SATA?

All should work the same, assuming they are flash to IT mode.

Already replied in the other thread you posted, please don't post about the same thing in multiple threads, and like mentioned we need the diagnostics to see the hardware, they can be from v6.10.1

It can be, since vt-d is now disable delete and re-create the docker image and monitor to make sure no more corruptions are found.

Please post the diagnostics, they can be from v6.10.1

I would suggest creating a new bug report in the stable releases section, and don't forget the diagnostics.

Cache device dropped offline: May 28 03:35:21 uNAS kernel: ata1: hard resetting link May 28 03:35:27 uNAS kernel: ata1: link is slow to respond, please be patient (ready=0) May 28 03:35:56 uNAS kernel: ata1: COMRESET failed (errno=-16) May 28 03:35:56 uNAS kernel: ata1: limiting SATA link speed to 3.0 Gbps May 28 03:35:56 uNAS kernel: ata1: hard resetting link May 28 03:36:01 uNAS kernel: ata1: COMRESET failed (errno=-16) May 28 03:36:01 uNAS kernel: ata1: reset failed, giving up May 28 03:36:01 uNAS kernel: ata1.00: disabled May 28 03:36:01 uNAS kernel: ata1: EH complete Check/replace cables.

And this posted above doesn't work for you? https://forums.unraid.net/topic/119502-bzimage-checksum-error/?do=findComment&comment=1108354

Taking a more careful look the problem is that you started a balance, and since it wasn't able to finish because of the no space issue it's resuming after rebooting: May 28 09:49:37 Tower kernel: BTRFS info (device sdo1): balance: resume -dusage=90 -musage=90 -susage=90 You can try this: -stop the array -on the console/terminal type: mkdir /x mount -o skip_balance /dev/sdo1 /x Should take a few seconds to mount, once you get the cursor back type: btrfs balance cancel /x umount /x If the above commands complete normally start the array normally and post new diags.

Pool is complete full and those errors are because it's running out of space, reboot to clear the read only status and you should be able to move some data elsewhere.

It's not a problem with the NVMe, but it's generating correctable PCIe errors, unlikely they are related to the issues but you should still to get rid of them, if it's not possible at least suppress the errors to stop spamming the log.