Re: [PATCH RESEND] btrfs: use the super_block as holder when mounting file systems

[Christian Brauner <brauner@kernel.org>]

On Thu, Sep 21, 2023 at 03:07:29PM +0200, Jan Kara wrote:
> On Thu 21-09-23 14:50:07, Christian Brauner wrote:
> > On Thu, Sep 21, 2023 at 02:19:45PM +0200, Jan Kara wrote:
> > > From: Christoph Hellwig <hch@lst.de>
> > > 
> > > The file system type is not a very useful holder as it doesn't allow us
> > > to go back to the actual file system instance.  Pass the super_block
> > > instead which is useful when passed back to the file system driver.
> > > 
> > > This matches what is done for all other block device based file systems and it
> > > also fixes an issue that block device freezing (as used e.g. by LVM when
> > > performing device snapshots) starts working for btrfs.
> > > 
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > Acked-by: Christian Brauner <brauner@kernel.org>
> > > Reviewed-by: Josef Bacik <josef@toxicpanda.com>
> > > Message-Id: <20230811100828.1897174-7-hch@lst.de>
> > > Signed-off-by: Jan Kara <jack@suse.cz>
> > > ---
> > >  fs/btrfs/super.c | 7 ++-----
> > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > > 
> > > Hello,
> > > 
> > > I'm resending this btrfs fix. Can you please merge it David? It's the only bit
> > > remaining from the original Christoph's block device opening patches and is
> > > blocking me in pushing out the opening of block devices using bdev_handle.
> > > Thanks!
> > 
> > Thanks for resending.
> > 
> > Next time we will ensure that a vfs triggered conversion must go through
> > a vfs tree as this half converted state with forgotten patches is not
> > something that we should repeat.
> 
> Yeah, I agree it would be good to find a smoother way to handle such
> merges. I understand David's desire to give changes proper testing which
> generally doesn't happen in linux-next but on maintainer's own branches and
> infrastructure but perhaps some stable branch in VFS tree that filesystem
> maintainers could pull when putting together the branch they push out to
> the testing infrastructure would work?

Yes, I'm very happy to provide this. Also worth nothing that everything
that goes through vfs.git sees xfstests for all affected filesystems.

Ideally we'll automate this directly on that repo at some point for all
official branches.

Right now I personally have:

https://github.com/brauner/mkosi-kernel

which uses mkosi to build a GPT image fully unprivileged with an:

ESP partition
root partition (of chosen format)
2-4 testing partitions

for any distro I need with any kernel config I want:

mkosi -d debian -t disk -f

During boot it generates a bunch of unprivileged users via
systemd-userdb drop-ins placed in /etc/userdb/ during build:
https://github.com/brauner/mkosi-kernel/tree/main/mkosi.extra/etc/userdb
creating testing users (user1, fsgqa, fgqa2, 123456-fsgqa) for xfstests.

Then I just fire the relevant tests using incus (formerly LXD). All
branches get the same treatment usually for ext4, xfs, btrfs via
-g quick (btrfs gets multiple devices - that's why there's 4 partitions).