| Message ID | 20230831001544.3379273-1-gpiccoli@igalia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Supporting same fsid mounting through the single-dev compat_ro feature | expand |
On 8/31/23 08:12, Guilherme G. Piccoli wrote: > Hi folks, this is the third round of the same fsid mounting patch. Our goal > is to allow btrfs to have the same filesystem mounting at the same time; > for more details, please take a look in the: > > V2: https://lore.kernel.org/linux-btrfs/20230803154453.1488248-1-gpiccoli@igalia.com/ > > V1: https://lore.kernel.org/linux-btrfs/20230504170708.787361-1-gpiccoli@igalia.com/ > > > In this V3, besides small changes / improvements in the patches (see the > changelog per patch), we dropped the module parameter workaround (which > was the 3rd patch in V2) and implemented the fstests test (as suggested > by Josef): https://lore.kernel.org/fstests/20230830221943.3375955-1-gpiccoli@igalia.com/ 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 > > As usual, suggestions / reviews are greatly appreciated. > Thanks in advance! > > > Guilherme G. Piccoli (2): > btrfs-progs: Add the single-dev feature (to both mkfs/tune) > btrfs: Introduce the single-dev feature > > btrfs-progs: > common/fsfeatures.c | 7 ++++ > kernel-shared/ctree.h | 3 +- > kernel-shared/uapi/btrfs.h | 7 ++++ > mkfs/main.c | 4 +- > tune/main.c | 76 ++++++++++++++++++++++++-------------- > 5 files changed, 67 insertions(+), 30 deletions(-) > > kernel: > fs/btrfs/disk-io.c | 17 +++++++- > fs/btrfs/fs.h | 3 +- > fs/btrfs/ioctl.c | 18 ++++++++ > fs/btrfs/super.c | 8 ++-- > fs/btrfs/sysfs.c | 2 + > fs/btrfs/volumes.c | 84 ++++++++++++++++++++++++++++++++------ > fs/btrfs/volumes.h | 3 +- > include/uapi/linux/btrfs.h | 7 ++++ > 8 files changed, 122 insertions(+), 20 deletions(-) >
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
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.
On 9/6/23 00:43, David Sterba wrote: > 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. Although setting up a SAN may not be as swift as launching a guest VM using a file-based disk image, however hosts running these VM guests rely on SAN-based multipath. Yep. Later verification is fine. >>> 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. Great! Thanks for confirming. > > 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. I'm trying to set up multipath, but I haven't had any luck so far. Thanks. Anand