On Mon, Sep 04, 2023 at 10:29:52PM -0300, Guilherme G. Piccoli wrote: > 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 don't know how good the multipath support is on btrfs, it's kind of a specific use case, requires a specialized hardware and emulation in VM requires iSCSI hacks which is tedious to setup on itself. So I do not insist on supporting the single-dev from the beginning, we usually start with a more restricted version and then extend the support eventually. > > 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. > > 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. We at least should know how some feature/hardware combinations behave and add protections against using them together if there are known problems. In the case of multipath I'd like to see somebody tests it but as said above for the initial implementation it does not need to support it.
