From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-xfs@vger.kernel.org, cem@kernel.org
Subject: Re: [PATCH 0/2] xfs: dedupe realtime rmap btree code
Date: Sun, 20 Sep 2026 20:40:03 -0700 [thread overview]
Message-ID: <20260921034003.GG2705364@frogsfrogsfrogs> (raw)
In-Reply-To: <20260918181324.2472127-1-sandeen@redhat.com>
On Fri, Sep 18, 2026 at 01:01:31PM -0500, Eric Sandeen wrote:
> xfs_rmap_btree.c and xfs_rtrmap_btree.c have a large amount of
> duplicated code, differing only in function names which add "rt"
> in the latter case. This can all be shared to reduce the cut & paste.
>
> Tested with an auto xfstests run as well as the rmap group with
> rtdev & rmap enabled.
>
> xfs_rmap_btree.c | 16 +--
> xfs_rmap_btree.h | 26 ++++++
> xfs_rtrmap_btree.c | 230 +++------------------------------------------------
> 3 files changed, 51 insertions(+), 221 deletions(-)
In general this looks good to me, though I'll add that the same sort of
code deduplication could likely be done to the refcount btree code too.
;)
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
>
> [root@fedora-rawhide xfstests-dev]# ./check -g rmap
> FSTYP -- xfs (non-debug)
> PLATFORM -- Linux/x86_64 fedora-rawhide 7.3.0-rc3+ #330 SMP
> PREEMPT_DYNAMIC Fri Sep 18 10:23:43 CDT 2026
> MKFS_OPTIONS -- -f -rrtdev=/dev/loop0 -m rmapbt=1,reflink=1 /dev/vdb2
> MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0
> -ortdev=/dev/loop0 /dev/vdb2 /mnt/scratch
>
> generic/365 2s ... 2s
> xfs/114 3s ... 2s
> xfs/233 1s ... 1s
> xfs/234 5s ... 5s
> xfs/235 1s ... 1s
> xfs/236 6s ... 6s
> xfs/271 2s ... 2s
> xfs/272 2s ... 2s
> xfs/273 4s ... 5s
> xfs/274 3s ... 3s
> xfs/275 [not run] This test requires a valid $SCRATCH_LOGDEV
> xfs/276 3s ... 3s
> xfs/277 2s ... 2s
> xfs/310 0s ... 1s
> xfs/317 [not run] XFS error injection requires
> CONFIG_XFS_DEBUG
> xfs/331 2s ... 2s
> xfs/332 1s ... 1s
> xfs/334 1s ... 1s
> xfs/335 4s ... 3s
> xfs/336 5s ... 5s
> xfs/337 5s ... 5s
> xfs/338 2s ... 2s
> xfs/339 2s ... 2s
> xfs/340 2s ... 2s
> xfs/341 1s ... 1s
> xfs/342 2s ... 2s
> xfs/343 2s ... 2s
> xfs/450 1s ... 2s
> Ran: generic/365 xfs/114 xfs/233 xfs/234 xfs/235 xfs/236 xfs/271 xfs/272
> xfs/273 xfs/274 xfs/275 xfs/276 xfs/277 xfs/310 xfs/317 xfs/331 xfs/332
> xfs/334 xfs/335 xfs/336 xfs/337 xfs/338 xfs/339 xfs/340 xfs/341 xfs/342
> xfs/343 xfs/450
> Not run: xfs/275 xfs/317
> Passed all 28 tests
>
>
>
next prev parent reply other threads:[~2026-09-21 3:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 18:01 [PATCH 0/2] xfs: dedupe realtime rmap btree code Eric Sandeen
2026-09-18 18:01 ` [PATCH 1/2] xfs: export several rmap btree key/record ops Eric Sandeen
2026-09-18 18:01 ` [PATCH 2/2] xfs: use the shared rmap btree ops for the rt rmap btree Eric Sandeen
2026-09-21 3:40 ` Darrick J. Wong [this message]
2026-09-21 8:24 ` [PATCH 0/2] xfs: dedupe realtime rmap btree code Christoph Hellwig
2026-09-21 17:56 ` Eric Sandeen
2026-09-21 18:17 ` Carlos Maiolino
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=20260921034003.GG2705364@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=cem@kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
/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.