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@xxxxxxxxxx > > > > > > > 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. I'll add an fstest for it then, I could have easily broken this if I didn't see Christians giant note about it. Thanks, Josef
