Re: [PATCH 1/6] xfs: fix xfs_rtrmapbt_mem_cursor for non-rmap filesystems

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Aug 18, 2026 at 11:16:39PM -0700, Christoph Hellwig wrote:
> On Wed, Aug 12, 2026 at 10:25:40PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > It's possible to construct an in-memory rtrmap btree for filesystems
> > that don't have the rmap feature enabled.  The kernel doesn't do this,
> > but xfs_repair will, if asked to reindex a filesystem that has rtreflink
> > enabled but not rtrmap.  Therefore, we must create the cursor with
> > enough levels to handle a maximally sized btree possible.
> 
> Should repair initialize m_rtrmap_maxlevels instead of overallocating
> in the kernel?

I'd prefer not to because (a) m_rtrmap_maxlevels is used in various
places (like computing transaction reservations) outside of creating
in-memory btrees and that would be weird on a non-rmap filesystem; (b)
the regular rmap code in xfs_repair already allocates biggish cursors
for in-memory btrees this way; and (c) I don't think it matters much
even in the kernel because if we're that low on memory then we're not
going to be able to create a replacement rmap record set in memory to
stage the rmapbt regeneration anyway.

That said, a more targetted way would be to add a maxlevels parameter to
xfs_{rt,}rmapbt_mem_cursor() and let the caller figure out the optimal
setting for their context -- online repair can use
mp->m_{rt,}rmap_maxlevels because it only creates in-memory rmap btrees
when rmap is enabled; and xfs_repair can use
xfs_{rt,}rmap_maxlevels_ondisk() for the weird (reflink && !rmap) case.

How does that sound?

--D