Re: [RFC 4/4] bdev: extend bdev inode with it's own super_block

From: Christoph Hellwig <hch@infradead.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	hch@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 06:50:15 -0700	[thread overview]
Message-ID: <ZIHcl8epO0h3z1TO@infradead.org> (raw)
In-Reply-To: <ZIHZngefNAtYtg7L@casper.infradead.org>

On Thu, Jun 08, 2023 at 02:37:34PM +0100, Matthew Wilcox wrote:
> On Wed, Jun 07, 2023 at 08:24:04PM -0700, Luis Chamberlain wrote:
> > We currently share a single super_block for the block device cache,
> > each block device corresponds to one inode on that super_block. This
> > implicates sharing one aops operation though, and in the near future
> > we want to be able to instead support using iomap on the super_block
> > for different block devices.
> 
> > -struct super_block *blockdev_superblock __read_mostly;
> 
> Did we consider adding
> 
> +struct super_block *blockdev_sb_iomap __read_mostly;
> 
> 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?  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.