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

[David Sterba <dsterba@suse.cz>]

On Thu, Sep 21, 2023 at 02:50:07PM +0200, 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.

Taking this as an example, I really don't want to let such patches go
through VFS git. I understand there are API-level cleanups done in
VFS that require reorganizing code in the filesystems but IMO the
conversions must be done in the filesystems first and the VFS cleanups
as a followup.

We have conflicting goals, you want better API and filesystems stand in
the way so you/somebody fix it in a seemingly correct way and you want
to merge it because it's ok for you. I view it as change from the
outside potentially introducing bugs that we'll have to deal and unless
we have somebody who's familiar with the changes to recognize the
problems and fix bugs eventually it's risky.

What I can do right now is that I'll keep the patches in linux-next,
with the additional fix so the series is complete. I'll let you know if
there's a change regarding the reviews or merge.