On 04/09/2023 03:36, Anand Jain wrote: > [...] > We need some manual tests as well to understand how this feature > will behave in a multi-pathed device, especially in SAN and iSCSI > environments. > > I have noticed that Ubuntu has two different device > paths for the root device during boot. It should be validated > as the root file system using some popular OS distributions. > > Thanks, Anand Hi Anand, thanks for you suggestions! I just tried on Ubuntu 22.04.3 and it worked flawlessly. After manually enabling the single-dev feature through btrfstune, when booted into the distro kernel (6.2.x) it mounts as RO (as expected, since this is a compat_ro feature). When switched to a supporting kernel (6.5 + this patch), it mounts normally - udev/systemd are capable of identifying the underlying device based on UUID, and it mounts as SINGLE_DEV. About the iSCSI / multipath cases, they are/should be unsupported. Is multi-path a feature of btrfs? I think we should prevent users from using single-dev along with other features of btrfs that doesn't make sense, like we're doing here with devices removal/replace and of course, with the metadata_uuid feature. Now if multipath is not supported from btrfs, my understanding is that users should not tune single-dev, as it doesn't make sense, but at the same time it's not on scope here to test such scenario. In other words, I'm happy to test a case that you suggest, but no matter how many non-btrfs features/cases we test, we're not in control of what users can do in the wild. Cheers, Guilherme
