JorgeB

-Tools -> New Config -> Preserve current assignments: All -> Apply

Then unassign one of the parity drives, if that's what you want; should leave parity1 in use.

Start the array to begin parity sync, and you can then also format disk7 at any time.

The OOM event was apparently caused by a Docker container that had a hard memory limit of 768 MB, and it reached it exactly, it wasn't a system-wide out-of-memory event.

Looks like this one: docker/b7215cfc67841485fb9a58cbb88ebde431e9206868bcc0364923718121f566c8

You are supposed to use a URL, not a local path, but see the release thread, there are some workarounds posted there

You can reimport the pool:

on main click on the first device for that pool and then "remove pool"
back on main, create a new pool with the same name and 6 slots
assign the 6 maan pool devices, leave the filesystem set to auto
start the array to import the pool

Make sure this has been taken care of: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-819173

If that does' help, enable the syslog server and set the persistent syslog to be saved to a share, then post that after the next crash.

A full recovery seems unlikely to me, since, besides the missing device, the pool has write errors with one other device, and the pool was not fully redundant, possibly because of that:

Jul 2 11:07:25 Tower kernel: BTRFS info (device nvme0n1p1): bdev <missing disk> errs: wr 1873035, rd 89663673, flush 0, corrupt 1, gen 0
Jul 2 11:07:25 Tower kernel: BTRFS info (device nvme0n1p1): bdev /dev/sdb1 errs: wr 58, rd 0, flush 0, corrupt 120, gen 0
Jul 2 11:07:25 Tower kernel: BTRFS warning (device nvme0n1p1): chunk 1104150528 missing 1 devices, max tolerance is 0 for writable mount
Jul 2 11:07:25 Tower kernel: BTRFS warning (device nvme0n1p1): writable mount is not allowed due to too many missing devices

You can try these recovery options here to see if you can save some of the data, but likely the pool will need to be reformatted in the end

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-543490

It's not logged as a disk problem, looks more like power/connection issue, Check/replace cables, also any power splitters in use?

The boot pool is using both devices, but the data partition is only using one of them, if you are OK with formatting the data partition, it should be possible to start the array after clicking the 1st pool device and then "erase pool" (any data on the data partition would be lost), if there's data there, you would need to mount that filesystem manually, copy its data, then reformat.

If you need to mount the filesystem manually, this should work.

mkdir /x
mount -t btrfs /dev/nvme0n1p4 /x

You can then access the data under /x

That is not possible; something is missing, once a disk is emulated, only a rebuild (or new config) will fix it.

Diags show you are using a controller with SATA port multipliers; those were never recommended, but they are basically unusable with the latest Unraid releases due to a kernel change/regression. My recommendation would be to replace it; otherwise, downgrade to 7.2.4. Another option that may help with 7.2.5+/7.3.x is to disable NCQ with a kernel parameter by adding this to the kernel options:

libata.force=noncq

Then reboot

Only the first time, then it's kept in memory; only after a reboot will it ask for it again. If using a keyfile, you can delete it after the array start (next to array stop button) and in that case, it will ask for it after an array stop.

You are using a Docker folder with the native zfs driver, that is a known issue. My recommendation would be to recreate it as a Docker image, since even when not doing that, Docker folders can, in my experience, have strange issues, but if you really want a folder, recreate it using the overlay2 driver.

You just add a slot and assign a device; don't change anything else, Unraid will automatically mirror the original device after array start

The compression you set for the pool will be the default for any dataset you create there; it will be inherited, but if you create a dataset using a specific compression, that is the one used (instead of inheriting the pool default)

The removal should be done with the array running, since the pool must be imported.

I don't see any obvious isses lçogegd, but all the pool cfg files were reset, possibly a flash drive issue, or just an issue with its filesystem, pretty sure it was unrelated to the upgrade, especially since you were already on 7.3.x

The pool is raidz2, you can see that on the zpool output.

Based on your screenshot, looks like the supposed devices are not assigned. Try re-importing the pool with all devices; make sure you export it first with zpool export hdd, then

on main click on the first device for that pool and then "remove pool"
back on main, create a new pool with the same name and 13 slots
assign all the the pool devices together, including the logs and cache devices (without creating any subpools, they will be created automatically during import), leave the filesystem set to auto
start the array to import the pool

If that fails, please post the diagnostics.

OK, the sizes match the expectation; I think the code is not accepting the 4k/1M layouts because parity2 is disabled.

Try this:
unassign parity 2 and you should be able to start the rebuild (if not, unassign and reassign disk 4 as well).
After the rebuild finishes, reassign parity2 (you may need to delete it's partition first, don't remember if Unraid will recreate a new one if there's an existing one, since 1 MiB aligned partition will no longer work; if you need to wipe it, you can use wipefs -a /dev/sdX)

It's fine until you have to rebuild a data disk; a rebuild will create a new 4K aligned partition, it woudl work with 7.3.x if all disks are the same size, which is the case, but both parity drives were enabled.

For the CPU you can upgrade to 7.3.x, for the mb a plugin would be required, assuming it supports your board.

You would need to create the boot pool with the smallest one first (or both at the same time).

You can do that by booting another flash drive (after copying the current config there), then removing the boot pool and rerunning the wizard to recreate it.

Yep, SMART test failed, so it should be replaced.

Jul 9 11:21:41 F4-424 emhttpd: cmdStart: already starting

This is typically a plugin issue; see if it happens in safe mode.

Assuming the data has been copied or it's not important, you should be able to remove it by clicking the pool device and then "Remove Pool"

Fist updatye to 7.3.1, then
on main click on the first device for that pool and then "remove pool"
back on main, create a new pool with the same name and 2 slots
assign the pool device good pool devices from zfs status (look at the device IDs, sdd and sdf, no the previous assignments, and if you rebooted, these ids can change), leave the filesystem set to auto
start the array to import the pool, it should be imported degraded
If yes, you can then stop the array and assign the new device.

Errors come from disks 7 and 8, do they share anything in common, like a power splitter? If not, replace the cables for both.

If you have the diags from the replacement would be interested in seeing them, but to fix the issue, open a terminal window and type:

zpool detach flash 14843927469164253652