mbox series

[V3,0/2] Supporting same fsid mounting through the single-dev compat_ro feature

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

Message

Guilherme G. Piccoli Aug. 31, 2023, 12:12 a.m. UTC
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/

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(-)

Comments

Anand Jain Sept. 4, 2023, 6:36 a.m. UTC | #1
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(-)
>
Guilherme G. Piccoli Sept. 5, 2023, 1:29 a.m. UTC | #2
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
David Sterba Sept. 5, 2023, 4:43 p.m. UTC | #3
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.
Anand Jain Sept. 6, 2023, 2:19 p.m. UTC | #4
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