From: Christoph Hellwig <hch@infradead.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Matthew Wilcox <willy@infradead.org>,
djwong@kernel.org, dchinner@redhat.com, kbusch@kernel.org,
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, corbet@lwn.net,
jake@lwn.net
Subject: Re: [RFC 4/4] bdev: extend bdev inode with it's own super_block
Date: Thu, 8 Jun 2023 21:20:14 -0700 [thread overview]
Message-ID: <ZIKofhpTXREOR3ec@infradead.org> (raw)
In-Reply-To: <ZIITpjDXyupKom+N@bombadil.infradead.org>
On Thu, Jun 08, 2023 at 10:45:10AM -0700, Luis Chamberlain wrote:
> > > and then considering only two superblocks instead of having a list of
> > > all bdevs?
> >
> > Or why the heck we would even do this to start with?
>
> That's what I gathered you suggested at LSFMM on hallway talk.
No. I explained you that sharing the superblock or has absolutely no
effct on the aops after you wanted to it. I said it might be nice for
other reasons to have a sb per gendisk.
> > iomap has absolutely nothing to do with superblocks.
> >
> > Now maybe it might make sense to have a superblock per gendisk just
> > to remove all the weird special casing for the bdev inode in the
> > writeback code. But that's something entirely different than this
> > patch.
>
> The goal behind this is to allow block devices to have its bdev cache
> use iomap, right now now we show-horn in the buffer-head aops if we
> have to build buffer-heads.
>
> If this sort of approach is not desirable, let me know what alternative
> you would prefer to see, because clearly, I must not have understood
> your suggestion.
Again, every non-trivial file system right now has more than one set
of aops per superblock. I'm not sure what problem you are trying to
solve here.
next prev parent reply other threads:[~2023-06-09 4:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-08 3:24 [RFC 0/4] bdev: allow buffer-head & iomap aops to co-exist Luis Chamberlain
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 [this message]
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=ZIKofhpTXREOR3ec@infradead.org \
--to=hch@infradead.org \
--cc=corbet@lwn.net \
--cc=da.gomez@samsung.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=hare@suse.de \
--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=mcgrof@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.