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

Christoph Hellwig
2025-10-16T04:38:03Z

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.