limetech

Thank you for the deep dive into inner workings of btrfs. Back when we implemented VM manager we indeed wanted to provide vdisk redundancy via btrfs raid1 profile. Our early testing showed a very obvious performance hit with a COW vdisk vs. NoCOW. This was circa 2016/2017? and we were aware of the discussion and patch set that ultimately arose. Actually my assumption was that btrfs metadata would keep track of which chunks were successfully committed to storage - apparently this is not the case? Also it has always bugged me that btrfs would not maintain checksums across NoCOW chunks. I can't think of a logical reason why this decision would be made in the code. edit: I guess to avoid read/modify/write. Sure, we can change the default to COW for the domains share. I think your testing shows that best performance in this case happens when vdisk files are also pre-allocated correct? Also, changing the default will have no effect on an existing domains share. To get rid of existing NoCOW flags, one must empty the domains share, delete it, and then recreate it. Moving forward into Unraid 6.11 we plan to introduce a "LVM" pool type of up to 3 mirrored devices. This will be used to create logical volumes to be used as vdisks in VM's. This should provide near bare-metal storage performance since we bypass completely any intermediate file system where vdisk (loopback) files are stored.

Sorry to say, the Intel ixgbe driver is causing problems for other people and we will have to revert to in-tree driver. Something on our list to implement for 6.11 is a "system plugin" feature that will let you select via CA third-party modules (drivers) to install very early in system startup, e.g., before networking is initialized. This will permit you to install the Intel driver if that works for you.

The mount options for a btrfs pool are: noatime,space_cache=v2,discard=async We can apply those same options to a btrfs unRAID device - would be better?

Another workaround is to use 'btrfs-encrypted' file system.

Changed Status to Retest

Changed Status to Retest Changed Priority to Minor

I don't see anything like "fixing recursive fault" in the system log.

Changed Status to Open Changed Priority to Minor

Is this going to require upgrading qemu from 6.2.0 to 7.0.0 as well?

Starting in -rc4 we moved from the in-tree ixgbe driver to the Intel ixgbe driver. May or may not be related to this. Please open a separate Bug Report for this. thx

Adding @bonienl resolution here:

fixed in next release

If you have "Use SSL/TLS" set to Auto then all these redirect: http://<ip-address>/ http://<servername>.<local-tld> and https://<servername>.<local-tld>/ => 404 But bear in mind that the <modified-ip>.hash.myunraid.net URL will only work if DNS works, which typically means you need internet access, though the TTL is very long now (7 days I think) so your PC probably will have it cached. The sluggishness, including terminal open delay are tell-tale signs of DNS issues. It looks like you have Network Settings set for both IPv4 and IPv6? Maybe try IPv4 only and see if that helps.

For this one please open separate Bug Report and include diagnostics. That's by design.

No, the plan is to release 6.10 'stable' on the 5.15 kernel and then back to updating to the latest kernel in Unraid 6.11.

We can apply the same "trick" of removing leading and trailing underscores and collapsing all sequences of 2 or more internal underscores to a single underscore. However - will this now cause other people problems? That's the risk/question. Maybe another approach is to run both the stored device id and the udev id through a filter first that removes all spaces and underscores unconditionally and then compare those strings - "should work" right?

Where does it do that? The rule in rules/60-persistent-storage.rules: ENV{ID_SERIAL}="$env{ID_MODEL}_$env{ID_SERIAL_SHORT}", SYMLINK+="disk/by-id/nvme-$env{ID_SERIAL}" Maybe the code that actually generates the symlink using SYMLINK does this?

should be supported now in -rc5 You can try modprobe r8152 and then see if the device is recognized.

If you do this then typing this URL (substituting your server name for 'tower'): http://tower.local or https://tower.local will no longer work.

Kind of a pain, but if you want to revert to 6.9.2 and type same command we can see what's the difference. I've looked through quite a bit of eudev code and there is a function that does exactly this, ie: it strips all spaces from end of string it strips all spaces from beginning of string collapses sequence of one or more internal spaces to a single underscore So if above was applied to ID_SERIAL=TOSHIBA-RD400_ 664S107XTPGV you would get this exact result. But it looks like the udev rules do not use that string directly. Anyway this is very odd.

Please post output of this command: cat /etc/nsswitch.conf

Changed Status to Retest

Changed Status to Retest

Changed Status to Retest

Please post output of this command: /sbin/udevadm info -q property -n /dev/nvme1n1