From: "Darrick J. Wong" <djwong@kernel.org>
To: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@gmail.com>
Cc: linux-xfs@vger.kernel.org, ritesh.list@gmail.com,
ojaswin@linux.ibm.com, hch@infradead.org
Subject: Re: [PATCH v1 2/2] xfs: Fix in xfs_rtalloc_query_range()
Date: Wed, 28 Jan 2026 09:14:43 -0800 [thread overview]
Message-ID: <20260128171443.GL5966@frogsfrogsfrogs> (raw)
In-Reply-To: <43e717d7864a2662c067d8013e462209c7b2952a.1769613182.git.nirjhar.roy.lists@gmail.com>
On Wed, Jan 28, 2026 at 08:44:35PM +0530, Nirjhar Roy (IBM) wrote:
> xfs_rtalloc_query_range() should not return 0 by doing a NOP when
> start == end i.e, when the rtgroup size is 1. This causes incorrect
> calculation of free rtextents i.e, the count is reduced by 1 since
> the last rtgroup's rtextent count is not taken and hence xfs_scrub
> throws false summary counter report (from xchk_fscounters()).
>
> A simple way to reproduce the above bug:
>
> $ mkfs.xfs -f -m metadir=1 \
> -r rtdev=/dev/loop2,extsize=4096,rgcount=4,size=1G \
> -d size=1G /dev/loop1
> meta-data=/dev/loop1 isize=512 agcount=4, agsize=65536 blks
> = sectsz=512 attr=2, projid32bit=1
> = crc=1 finobt=1, sparse=1, rmapbt=1
> = reflink=0 bigtime=1 inobtcount=1 nrext64=1
> = exchange=1 metadir=1
> data = bsize=4096 blocks=262144, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=0
> log =internal log bsize=4096 blocks=16384, version=2
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =/dev/loop2 extsz=4096 blocks=262144, rtextents=262144
> = rgcount=4 rgsize=65536 extents
> = zoned=0 start=0 reserved=0
> Discarding blocks...Done.
> Discarding blocks...Done.
> $ mount -o rtdev=/dev/loop2 /dev/loop1 /mnt1/scratch
> $ xfs_growfs -R $(( 65536 * 4 + 1 )) /mnt1/scratch
> meta-data=/dev/loop1 isize=512 agcount=4, agsize=65536 blks
> = sectsz=512 attr=2, projid32bit=1
> = crc=1 finobt=1, sparse=1, rmapbt=1
> = reflink=0 bigtime=1 inobtcount=1 nrext64=1
> = exchange=1 metadir=1
> data = bsize=4096 blocks=262144, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=0
> log =internal log bsize=4096 blocks=16384, version=2
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =/dev/loop2 extsz=4096 blocks=262144, rtextents=262144
> = rgcount=4 rgsize=65536 extents
> = zoned=0 start=0 reserved=0
> calling xfsctl with in.newblocks = 262145
> realtime blocks changed from 262144 to 262145
> $ xfs_scrub -n -v /mnt1/scratch
> Phase 1: Find filesystem geometry.
> /mnt1/scratch: using 2 threads to scrub.
> Phase 2: Check internal metadata.
> Corruption: rtgroup 4 realtime summary: Repairs are required.
> Phase 3: Scan all inodes.
> Phase 5: Check directory tree.
> Info: /mnt1/scratch: Filesystem has errors, skipping connectivity checks.
> Phase 7: Check summary counters.
> Corruption: filesystem summary counters: Repairs are required.
> 125.0MiB data used; 8.0KiB realtime data used; 15 inodes used.
> 64.3MiB data found; 4.0KiB realtime data found; 18 inodes found.
> 18 inodes counted; 18 inodes checked.
> Phase 8: Trim filesystem storage.
> /mnt1/scratch: corruptions found: 2
> /mnt1/scratch: Re-run xfs_scrub without -n.
>
> Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
Yeah, that looks right. I can also reproduce it with:
# mkfs.xfs -m metadir=1 -r rtdev=/dev/sdb /dev/sda -r rgsize=65536b,size=131073b -f
# mount /dev/sda /mnt -o rtdev=/dev/sdb
# xfs_scrub -dTvn /mnt
Cc: <stable@vger.kernel.org> # v6.13
Fixes: e3088ae2dcae3c ("xfs: move RT bitmap and summary information to the rtgroup")
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> ---
> fs/xfs/libxfs/xfs_rtbitmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/xfs/libxfs/xfs_rtbitmap.c b/fs/xfs/libxfs/xfs_rtbitmap.c
> index 618061d898d4..8f552129ffcc 100644
> --- a/fs/xfs/libxfs/xfs_rtbitmap.c
> +++ b/fs/xfs/libxfs/xfs_rtbitmap.c
> @@ -1170,7 +1170,7 @@ xfs_rtalloc_query_range(
>
> if (start > end)
> return -EINVAL;
> - if (start == end || start >= rtg->rtg_extents)
> + if (start >= rtg->rtg_extents)
> return 0;
>
> end = min(end, rtg->rtg_extents - 1);
> --
> 2.43.5
>
next prev parent reply other threads:[~2026-01-28 17:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 15:14 [PATCH v1 0/2] Misc fixes in XFS realtime Nirjhar Roy (IBM)
2026-01-28 15:14 ` [PATCH v1 1/2] xfs: Move ASSERTion location in xfs_rtcopy_summary() Nirjhar Roy (IBM)
2026-01-28 15:25 ` Alan Huang
2026-01-28 16:14 ` Darrick J. Wong
2026-01-28 16:13 ` Darrick J. Wong
2026-01-28 17:00 ` Nirjhar Roy (IBM)
2026-01-28 15:14 ` [PATCH v1 2/2] xfs: Fix in xfs_rtalloc_query_range() Nirjhar Roy (IBM)
2026-01-28 17:14 ` Darrick J. Wong [this message]
2026-01-28 18:00 ` Nirjhar Roy (IBM)
2026-01-28 18:29 ` Darrick J. Wong
2026-01-28 18:30 ` Nirjhar Roy (IBM)
2026-02-02 6:25 ` 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=20260128171443.GL5966@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
--cc=nirjhar.roy.lists@gmail.com \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox