Re: [PATCH 2/3] writeback: allow the file system to override MIN_WRITEBACK_PAGES

[Christoph Hellwig <hch@lst.de>]

On Wed, Oct 15, 2025 at 08:57:35AM -0700, Darrick J. Wong wrote:
> Should this be some sort of BDI field?  Maybe there are other workloads
> that create a lot of dirty pages and the sysadmin would like to be able
> to tell the fs to schedule larger chunks of writeback before switching
> to another inode?

The BDI is not owned by the file system, but rather the gendisk, so we
can't just override it in the file systems.  I still hope that eventually
changes, in which case we could revisit it.  Having a tunable sounds neat,
but I'd rather get the fix out first and then design something like that.

> 
> XFS can have two volumes, should we be using the rtdev's bdi for
> realtime files and the data dev's bdi for non-rt files?  That looks like
> a mess to sort out though, since there's a fair number of places where
> we just dereference super_block::s_bdi.

Each file system only uses a single BDI, which in case of XFS is the
one of the gendisk that the main device sits on.  Only the bdevfs uses
multiple BDIs (one per file{) and that required hard coded hacks in the
writeback code.  I don't think there is any benefit in having multiple
BIDs for real file system, the parallelization work that just got reposted
works inside a BDI.

> Also I have no idea what we'd do for filesystem raid -- synthesize a bdi
> for that?  And then how would you advertise that such-and-such fd maps
> to a particular bdi?

btrfs allocates it's own BDI.  And I hope that we eventually move to a
model where the file system always own the BDI as that would simplify
object lifetimes an relationships and locking a lot.