linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: hch@infradead.org, djwong@kernel.org, dchinner@redhat.com,
	kbusch@kernel.org, willy@infradead.org
Cc: hare@suse.de, ritesh.list@gmail.com, rgoldwyn@suse.com,
	jack@suse.cz, patches@lists.linux.dev, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
	p.raghav@samsung.com, da.gomez@samsung.com,
	rohan.puri@samsung.com, rpuri.linux@gmail.com, mcgrof@kernel.org,
	corbet@lwn.net, jake@lwn.net
Subject: [RFC 0/4] bdev: allow buffer-head & iomap aops to co-exist
Date: Wed,  7 Jun 2023 20:24:00 -0700	[thread overview]
Message-ID: <20230608032404.1887046-1-mcgrof@kernel.org> (raw)

At LSFMM it was clear that for some in order to support large order folios
we want to use iomap. So the filesystems staying and requiring buffer-heads
cannot make use of high order folios. This simplifies support and reduces
the scope for what we need to do in order to support high order folios for
buffered-io.

As Christoph's patches show though, we can only end up without buffer-heads
if you build and boot a system without any support for any filesystem that
requires buffer-heads. That's a tall order today.

We however want to be able to support block devices which may want to
completely opt-in to to only use iomap and iomap based filesystems. We
cannot do that today. To help with this we must extend the block device
cache so to enable each block device to get its own super block, and so
to later enable us to pick and choose the aops we use for the block
device.

The first patch seems already applicable upstream. The second is just
makes future changes easier to read. The third patch probably just needs
to be squashed into Christoph's work.

The last patch is the meat of this.

It goes boot tested, and applies on top of Christoph's patches which
enable you to build a sytem without buffer-heads. For convenience I've
stashed what this looks like on my large-block-20230607-dev-cache
branch [0].

The hot swapping of the aops is what would be next, and when we do that.
One option is to pursue things as-is now and then only flip if we need
high order folios. I'm sure Christoph will have better ideas how to do
that cleanly. But this is is what I have so far.

Lemme know how crappy this looks or pitfalls I'm sure I missed.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=large-block-20230607-dev-cache

Luis Chamberlain (4):
  bdev: replace export of blockdev_superblock with BDEVFS_MAGIC
  bdev: abstract inode lookup on blkdev_get_no_open()
  bdev: rename iomap aops
  bdev: extend bdev inode with it's own super_block

 block/bdev.c       | 106 +++++++++++++++++++++++++++++++++++++--------
 block/blk.h        |   1 +
 block/fops.c       |  14 +++---
 include/linux/fs.h |   4 +-
 4 files changed, 98 insertions(+), 27 deletions(-)

-- 
2.39.2


             reply	other threads:[~2023-06-08  3:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-08  3:24 Luis Chamberlain [this message]
2023-06-08  3:24 ` [RFC 1/4] bdev: replace export of blockdev_superblock with BDEVFS_MAGIC Luis Chamberlain
2023-06-08 10:22   ` Jan Kara
2023-06-08 13:53   ` Christoph Hellwig
2023-06-08  3:24 ` [RFC 2/4] bdev: abstract inode lookup on blkdev_get_no_open() Luis Chamberlain
2023-06-08  3:24 ` [RFC 3/4] bdev: rename iomap aops Luis Chamberlain
2023-06-08  3:24 ` [RFC 4/4] bdev: extend bdev inode with it's own super_block Luis Chamberlain
2023-06-08 13:37   ` Matthew Wilcox
2023-06-08 13:50     ` Christoph Hellwig
2023-06-08 17:45       ` Luis Chamberlain
2023-06-09  4:20         ` Christoph Hellwig
2023-06-09  9:17           ` Luis Chamberlain
2023-06-08 13:50   ` 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=20230608032404.1887046-1-mcgrof@kernel.org \
    --to=mcgrof@kernel.org \
    --cc=corbet@lwn.net \
    --cc=da.gomez@samsung.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=jake@lwn.net \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=p.raghav@samsung.com \
    --cc=patches@lists.linux.dev \
    --cc=rgoldwyn@suse.com \
    --cc=ritesh.list@gmail.com \
    --cc=rohan.puri@samsung.com \
    --cc=rpuri.linux@gmail.com \
    --cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).