JorgeB

Look in the syslog for the list of correct file(s), delete/restore them from a backup, then run another scrub to confirm 0 errors and reset the stats, then keep monitoring the pool; if new errors show up, there's still a problem.

Nvidia is still using a driver; it could be just the order they are initiated with both kernels. Try binding the GPU to vfio-pci

If the GPU is still being passed there it would explain the issue, see if the hardware IDs didn't change; they can change with a kernel update.

Missing files and filesystem corruption is possible, but typically only after the filesystem is not mounting and you repair the filesystem; in this case, xfs_repair, if the corruption is bad enough, can move some lost files/folders to lost+found, never seen that happen without logged signs of corruption and the user then runing xfs_repair.

Both are set to array only, so the mover won't touch them. Also, note that you need to disable the Docker and VM services first.

You can try reseating them, or testing just two, then the other two.

Not in the diags posted: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484] (rev a1) Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:3909] Kernel driver in use: nvidia Kernel modules: nouveau, nvidia_drm, nvidia Unraid is likely using the monitor output, hence the blinking cursor.

Unlikely that is a drive problem; once you believe the issue is resolved (note that it could also be an old issue, and the stats were never reset), scrub the pool, and post the results.

A pool pass minimum, more if possible.

Please post the diagnsotics.

Is the monitor connected to the Nvidia GPU?

That behavior seems strange to me, but it's such a large pool, so it may be different than I expect. I've also done some tests, and sometimes when resilvering multiple devices, it doesn't do any parallel resilver; other times, it does parallel for all; sometimes only a couple of the devices are resilvered in parallel, but not all, still I don't know why the difference; investigating. In any case, my recommendation for now would be to just let it finish.

If actual files are missing, something or someone must have deleted them.

First thing is to check filesystem on the emulated disk6, and make sure you don't rebuild it on top of the old disk for now

Best to disable mover logging, to avoid log spam, unless you are having some issues with the mover.

btrfs is detecting data corruption, start by runing memtest

Server rebooting by itself is almost always a hardware problem, or bad power.

May 20 04:49:23 Chimaera rc.nginx: Starting Nginx server daemon... May 20 04:49:30 Chimaera rc.nginx: Nginx server daemon... Failed. Nginx is failing to start, reboot in safe mode and post new diags.

Enable mover logging, run the mover and post the diagnostics.

It will format the data partition from the boot pool only (and the other unformatted devices, of course).

Upgrade again, and if it stops spinning down once more, post the diagnostics, mostly to see the hardware.

Different number of errors suggests a RAM problem, note that memtest is only definitive if it finds errors, if you have multiple sticks try using the server with just one, then run at least two correcting checks, if the 2nd one still finds errors, try with a different one, that will basically rule out bad RAM.

Unless there was an unmountable disk or pool, it could not have been the upgrade; if the files are really missing, there are typically two reasons: the server is exposed to the internet and was hacked or there's a container/plugin that removed them while doing some maintenance.

They don't have any controller log info before the errors, which is pretty weird.

Btrfs is detecting data corruption on both devices. Start by running memtest, but I see you have a 13700K; it could also be the Intel 13/14 gen issue.