Linux block layer
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>, Al Viro <viro@zeniv.linux.org.uk>,
	"Darrick J. Wong" <djwong@kernel.org>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 5/9] block: introduce holder ops
Date: Wed, 17 May 2023 09:57:55 +0200	[thread overview]
Message-ID: <20230517-einreden-dermatologisch-9c6a3327a689@brauner> (raw)
In-Reply-To: <20230517073031.GF27026@lst.de>

On Wed, May 17, 2023 at 09:30:31AM +0200, Christoph Hellwig wrote:
> On Tue, May 16, 2023 at 06:00:05PM +0200, Christian Brauner wrote:
> > Looking at this code reminds me that we'll need a block dev lookup
> > function that takes a diskseq argument so we can lookup a block device
> > and check it against the diskseq number we provided so we can detect
> > "media" changes (images on a loop device etc). Idea being to pass
> > diskseq numbers via fsconfig().
> 
> You can already do this by checking right after opening but before
> using it.  In theory we could pass the seq down, and handle it further
> down, but I'm not sure this really solves anything.

BTW, why is there no code to lookup a bdev by O_PATH fd? It seems weird
that a lot of ioctls pass the device path to the kernel (btrfs comes to
mind). I can see certain things that would make this potentially a bit
tricky e.g., you'd not have access to the path/name of the device if you
want to show it somewhere such as in mountinfo but nothing that makes it
impossible afaict.

> 
> The main work here really is in the mount code.

Yeah, I'll get to this soon. Josef has mentioned that he'll convert
btrfs to the new mount api this cycle and we have that recorded on
video. And I think that otherwise all block device based filesystems
might have already been converted.

  reply	other threads:[~2023-05-17  7:58 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-05 17:51 introduce bdev holder ops and a file system shutdown method Christoph Hellwig
2023-05-05 17:51 ` [PATCH 1/9] block: consolidate the shutdown logic in blk_mark_disk_dead and del_gendisk Christoph Hellwig
2023-05-07 19:08   ` Jan Kara
2023-05-09 13:35     ` Christoph Hellwig
2023-05-05 17:51 ` [PATCH 2/9] block: avoid repeated work in blk_mark_disk_dead Christoph Hellwig
2023-05-07 19:05   ` Jan Kara
2023-05-16 16:29   ` Christian Brauner
2023-05-05 17:51 ` [PATCH 3/9] block: factor out a bd_end_claim helper from blkdev_put Christoph Hellwig
2023-05-07 19:08   ` Jan Kara
2023-05-16 16:29   ` Christian Brauner
2023-05-05 17:51 ` [PATCH 4/9] block: turn bdev_lock into a mutex Christoph Hellwig
2023-05-07 19:09   ` Jan Kara
2023-05-16 16:24   ` Christian Brauner
2023-05-05 17:51 ` [PATCH 5/9] block: introduce holder ops Christoph Hellwig
2023-05-05 18:51   ` Darrick J. Wong
2023-05-09 13:35     ` Christoph Hellwig
2023-05-09 22:19       ` Dave Chinner
2023-05-10  1:38         ` Darrick J. Wong
2023-05-10 15:13         ` Christoph Hellwig
2023-05-07 19:12   ` Jan Kara
2023-05-16 11:02   ` Ming Lei
2023-05-16 14:36     ` Darrick J. Wong
2023-05-17  7:29       ` Christoph Hellwig
2023-05-16 16:00   ` Christian Brauner
2023-05-17  7:30     ` Christoph Hellwig
2023-05-17  7:57       ` Christian Brauner [this message]
2023-05-17  8:06         ` Christoph Hellwig
2023-05-17  8:42           ` Christian Brauner
2023-05-17 12:02             ` Christoph Hellwig
2023-05-17 13:14               ` Christian Brauner
2023-05-17 14:26                 ` Christoph Hellwig
2023-05-18  8:13                   ` Christian Brauner
2023-05-18 13:12                     ` Christoph Hellwig
2023-05-18 13:13                       ` Christoph Hellwig
2023-05-18 13:56                       ` Christian Brauner
2023-05-05 17:51 ` [PATCH 6/9] block: add a mark_dead holder operation Christoph Hellwig
2023-05-05 18:37   ` Darrick J. Wong
2023-05-09 13:30     ` Christoph Hellwig
2023-05-07 19:19   ` Jan Kara
2023-05-09 13:32     ` Christoph Hellwig
2023-05-16 16:17       ` Christian Brauner
2023-05-05 17:51 ` [PATCH 7/9] fs: add a method to shut down the file system Christoph Hellwig
2023-05-05 18:39   ` Darrick J. Wong
2023-05-07 19:20   ` Jan Kara
2023-05-16 16:20   ` Christian Brauner
2023-05-17  7:27     ` Christoph Hellwig
2023-05-05 17:51 ` [PATCH 8/9] xfs: wire up sops->shutdown Christoph Hellwig
2023-05-05 18:23   ` Darrick J. Wong
2023-05-09 13:28     ` Christoph Hellwig
2023-05-05 17:51 ` [PATCH 9/9] xfs: wire up the ->mark_dead holder operation for log and RT devices Christoph Hellwig
2023-05-05 18:32   ` Darrick J. Wong
2023-05-08 15:20 ` introduce bdev holder ops and a file system shutdown method Christoph Hellwig

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=20230517-einreden-dermatologisch-9c6a3327a689@brauner \
    --to=brauner@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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