Re: [PATCH 0/3] fanotify support for btrfs sub-volumes

Christian Brauner
2023-11-03T06:56:49Z

On Thu, Nov 02, 2023 at 06:07:45PM +0100, David Sterba wrote:
> On Thu, Nov 02, 2023 at 08:34:46AM -0400, Josef Bacik wrote:
> > On Thu, Nov 02, 2023 at 10:48:35AM +0100, Christian Brauner wrote:
> > > > We'll be converted to the new mount API tho, so I suppose that's something.
> > > > Thanks,
> > >
> > > Just in case you forgot about it. I did send a patch to convert btrfs to
> > > the new mount api in June:
> > >
> > > https://lore.kernel.org/all/20230626-fs-btrfs-mount-api-v1-0-045e9735a00b@kernel.org
> > >
> >
> > Yeah Daan told me about this after I had done the bulk of the work. I
> > shamelessly stole the dup idea, I had been doing something uglier.
> >
> > > Can I ask you to please please copy just two things from that series:
> > >
> > > (1) Please get rid of the second filesystems type.
> > > (2) Please fix the silent remount behavior when mounting a subvolume.
> > >
> >
> > Yeah I've gotten rid of the second file system type, the remount thing is odd,
> > I'm going to see if I can get away with not bringing that over. I *think* it's
> > because the standard distro way of doing things is to do
> >
> > mount -o ro,subvol=/my/root/vol /
> > mount -o rw,subvol=/my/home/vol /home
> > <boot some more>
> > mount -o remount,rw /
> >
> > but I haven't messed with it yet to see if it breaks. That's on the list to
> > investigate today. Thanks,
>
> It's a use case for distros, 0723a0473fb4 ("btrfs: allow mounting btrfs
> subvolumes with different ro/rw options"), the functionality should
> be preserved else it's a regression.

My series explicitly made sure that it _isn't_ broken. Which is pretty
obvious from the description I put in there where that example is
explained at length.

It just handles it _cleanly_ through the new mount api while retaining
the behavior through the old mount api. The details - as Josef noted -
I've explained extensively.