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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 08, 2023 at 06:50:15AM -0700, Christoph Hellwig wrote:
> 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?

That's what I gathered you suggested at LSFMM on hallway talk.

> 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.

  Luis



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux