JorgeB

Going to close this since the name change is apparently a udev issue and the main problem, i.e., the fact that the pool config wasn't saved is a different bug, I now saved the new config and don't really care that the device name includes an extra underscore.

The post mentions to 1st to change power supply idle control, if that setting is not available then disable c-states, I would be very surprised if there's no such setting in the BIOS.

Make sure destructive mode is enable in the UD plugin settings, then click on the red x to delete current partition and you'll be able to re-format. P.S. next time please use the existing plugin support thread.

It's an option in the boot menu:

See here:

Start by running memtest, btrfs is detecting data corruption, there are also several ATA errors.

May 8 21:10:17 ThreadRipper19 kernel: BTRFS: device fsid 067b1393-440b-497e-b688-fb11e9c6611d devid 3 transid 645077 /dev/nvme3n1p1 scanned by udevd (2760) May 8 21:10:17 ThreadRipper19 kernel: BTRFS: device fsid 067b1393-440b-497e-b688-fb11e9c6611d devid 2 transid 291831 /dev/nvme0n1p1 scanned by udevd (2792) As you can see the transid of one of the devices is way off, it should be the same for all pool members, note the other pool below: May 8 21:10:17 ThreadRipper19 kernel: BTRFS: device fsid 565f4d7d-1b62-4a67-9414-ac108e2553f3 devid 3 transid 31253 /dev/nvme1n1p1 scanned by udevd (2741) May 8 21:10:17 ThreadRipper19 kernel: BTRFS: device fsid 565f4d7d-1b62-4a67-9414-ac108e2553f3 devid 2 transid 31253 /dev/nvme2n1p1 scanned by udevd (2727) The difference is so large that it couldn't happen if a device lost a few writes, so likely some corruption happened here, also note that Ryzen with overclocked RAM like you have is known to in some cases corrupt data, so suggest fixing that. You can first try restoring the superblock from backup to see if it helps, do it both both pool devices: btrfs-select-super -s 1 /dev/nvme3n1p1 btrfs-select-super -s 1 /dev/nvme0n1p1 Then reboot and post new diags.

Sorry, can't really help with that, someone else might be able to.

Check filesystem on disk1, ATA errors on disks 2 and 8, disk8 issue doesn't look like a disk problem, could be power/connection related or the controller since it's using a SATA port multiplier and those are a known issue.

Check/replace cables (both SATA and power) on parity and disk1.

You don't have VMs so it's likely container related, you can try running with just some or leave one disable at a time to see if you can find the culprit.

Not sure what you mean by this, number of SATA cables is not a problem except for cable management. Apparently it can be flashed to IT mode but there won't be SMART: https://forums.servethehome.com/index.php?threads/crossflashing-of-lsi-9341-8i-to-lsi-9300-8i-success-but-no-smart-pass-through.3522/ That's incorrect, it can happen with very old controllers/backplanes, with SATA or SAS.

This is no longer needed, as of at least Unraid v6.10-rc4 and later included Samba supports reflinks over SMB by default (for XFS also), and note that as of now (Unraid v6.10.0-rc7) and due to an apparent Samba bug any copy to a share with this enable done using server side copy will crash Samba.

Thanks, that's it, in a way glad I didn't know how it worked, or I would probably still be looking my issue

Cache filesystem is corrupt, you should backup and re-format.

Found the problem, reflinking over SMB is now enable by default with Samba, me adding "vfs objects = btrfs" was causing the problem, it's no longer needed for reflinks, though it's still a valid option, so server side copy making Samba crash with it enable now looks like a Samba bug. Having a second vfs object "fixed" the problem because apparently Unraid only loads the last one, so basically wasn't loading "vfs objects = btrfs", on a related note if I needed to set two or more vfs objects for one share how could I do that? P.S. reflinks over SMB now also work with XFS, assuming it's a relatively recent XFS filesystem with reflink support, so you can just right-click one or more files with Windows explorer and select copy here (or copy/paste) to make reflinks, it works with disk shares and user shares.

May 4 09:45:00 Mongo kernel: macvlan_broadcast+0x116/0x144 [macvlan] May 4 09:45:00 Mongo kernel: macvlan_process_broadcast+0xc7/0x110 [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/

Please post the diagnostics.

That's fine, and preferable IMHO, as long as the use cache is not set to "yes" like it was, or some data would be moved to the array and missing in the docker(s)

Extended test pass so disk is OK, SMART attributes also look healthy.

Try recreating the docker image, not sure it will help but it won't hurt.

Yes, it works normally as long as there's an additional vfs object besides btrfs, though I only tested with two, shadow_copy2 and recycle, and no, no recycle bin plugin installed.

Some NVMe devices have issues with power states on Linux, try this, on the main GUI page click on flash, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (on the top right) and add this to your default boot option, after "append initrd=/bzroot" nvme_core.default_ps_max_latency_us=0 e.g.: append initrd=/bzroot nvme_core.default_ps_max_latency_us=0 Reboot and see if it makes a difference.

After some more testing I found that apparently just need to add any other vfs object, i.e., with this config any copy/move from another share to this share done with Windows explorer Samba crashes immediately: [cache] path = /mnt/cache vfs objects = btrfs comment = browseable = yes public = yes writeable = yes case sensitive = auto preserve case = yes short preserve case = yes It works fine with for example this one: [cache] path = /mnt/cache vfs objects = btrfs vfs objects = recycle comment = browseable = yes public = yes writeable = yes case sensitive = auto preserve case = yes short preserve case = yes @limetech any idea if this could be specific to Unraid and how Samba or its config files are implemented or it's likely a Samba bug?