All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: hch@lst.de, cem@kernel.org, stable@vger.kernel.org,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/6] xfs: fix xfs_rtrmapbt_mem_cursor for non-rmap filesystems
Date: Wed, 19 Aug 2026 16:30:25 -0700	[thread overview]
Message-ID: <20260819233025.GF6072@frogsfrogsfrogs> (raw)
In-Reply-To: <20260819231943.GD6072@frogsfrogsfrogs>

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 <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?

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

  reply	other threads:[~2026-08-19 23:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13  5:24 [PATCHSET 2/2] xfs: LLM-inspired bug fixes, part 6 Darrick J. Wong
2026-08-13  5:25 ` [PATCH 1/6] xfs: fix xfs_rtrmapbt_mem_cursor for non-rmap filesystems Darrick J. Wong
2026-08-19  6:16   ` Christoph Hellwig
2026-08-19 23:19     ` Darrick J. Wong
2026-08-19 23:30       ` Darrick J. Wong [this message]
2026-08-13  5:25 ` [PATCH 2/6] xfs: preserve owner on in-memory btree creation Darrick J. Wong
2026-08-19  6:17   ` Christoph Hellwig
2026-08-13  5:26 ` [PATCH 3/6] xfs: don't leak new_bp if xfs_btree_bload_drop_buf fails Darrick J. Wong
2026-08-19  6:20   ` Christoph Hellwig
2026-08-13  5:26 ` [PATCH 4/6] xfs: actually recover intended file sizes in xfs_xmi_item_recover_intent Darrick J. Wong
2026-08-19  6:21   ` Christoph Hellwig
2026-08-13  5:26 ` [PATCH 5/6] xfs: don't modify file attributes or poke fsnotify for dry runs Darrick J. Wong
2026-08-19  6:24   ` Christoph Hellwig
2026-08-19 23:24     ` Darrick J. Wong
2026-08-13  5:26 ` [PATCH 6/6] xfs: fix bnobt repair space reservation disposal failure Darrick J. Wong
2026-08-19  6:24   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260819233025.GF6072@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.