Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Jan Kara <jack@suse.cz>
Cc: David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Christian Brauner <brauner@kernel.org>,
	Josef Bacik <josef@toxicpanda.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH RESEND] btrfs: use the super_block as holder when mounting file systems
Date: Mon, 25 Sep 2023 17:54:09 +0200	[thread overview]
Message-ID: <20230925155409.GO13697@twin.jikos.cz> (raw)
In-Reply-To: <20230921121945.4701-1-jack@suse.cz>

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.

I'll add the patch to the rest of the series, thanks. I don't have a
timeframe when this will be moved to the main patch queue, until then
it'll be in linux-next. The series has been sitting in the review
backlog for a few weeks but no takers. I try to have a look from time
to time but the kind of changes done there are not trivial so I'm still
not confident enough to put to the main patch queue.

  parent reply	other threads:[~2023-09-25 16:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-21 12:19 [PATCH RESEND] btrfs: use the super_block as holder when mounting file systems Jan Kara
2023-09-21 12:50 ` Christian Brauner
2023-09-21 13:07   ` Jan Kara
2023-09-21 13:33     ` Christian Brauner
2023-09-25 16:13   ` David Sterba
2023-09-26  9:59     ` Christian Brauner
2023-09-25 15:54 ` David Sterba [this message]
2023-09-26  9:45   ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230925155409.GO13697@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=brauner@kernel.org \
    --cc=dsterba@suse.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox