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

On Wed, Aug 19, 2026 at 04:19:43PM -0700, Darrick J. Wong wrote:
> 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 <[email protected]>
> > > 
> > > 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?

On second thought ... the slab cache that we use to create rtrmapbt
cursors always makes them big enough for xfs_rtrmap_maxlevels_ondisk()
levels, so we always consume that much memory no matter what we set
bc_nlevels to in xfs_rtrmapbt_mem_cursor().

--D