Re: update BDI {io,ra}_pages values based on the RT device limits

[Christoph Hellwig <hch@lst.de>]

On Wed, Jun 24, 2026 at 02:26:35PM +0200, Jan Kara wrote:
> A cleaner but still relatively simple way how to fix your problem would be
> to do something similar like e.g. btrfs does. That is when you have a
> filesystem with multiple backing devices, you create a new BDI (using
> super_setup_bdi()) and set its parameters based on the combination of
> devices you have.
> 
> The only downside to this is that blk-wbt has a layering violation in it
> when it tries to guess whether there are task dirty-throttled for the
> device which stops working for when the filesystem uses this synthetic bdi.
> But I don't think that's too serious to worry about.

The big downside of that is that it breaks the userspace ABI - any
previous changes to BDI paramters, most importantly the read-ahead size,
would now only apply to the BDI for s_bdev which isn't actually used
by anything.

And yeah, the blk-wbt thing actually looks really broken and could use
fixing..

> >   1) support multiple BDIs per file system.
> > 
> > 	This would work pretty well for XFS, as data for a given file is
> > 	always entirely on one device, and the VFS writeback code is not
> > 	used for metadata.  But it probably doesn't work well for other
> > 	cases
> 
> Since looking up the bdi is abstracted through inode_to_bdi() (which
> currently goes through the superblock), this would be relatively easy to do
> but either the inode would have to store the bdi pointer or we'd have to
> have an operation to query it. Just at this point I'm not fully convinced
> the additional complexity / memory cost is worth it compared to what can be
> achieved with a synthetic bdi.

Same.

> >   2) stop propagating these values through the BDI
> > 
> > 	Have a way to query these parameters from the file system, either
> > 	through a method if we want to be fully dynamic, or through fields
> > 	instead of going through the BDI.  The downside would be that
> > 	sysfs modifications of the readahead size would not work after
> > 	the file system initially queried them.
> 
> Similarly as above. It makes sense but I'm not sure there are strong enough
> usecases to justify this.

It would at least be a lot less complete than option 1.  And get us out of
a bit more of all that bdi weirdness.