From: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@gmail.com>
To: Carlos Maiolino <cem@kernel.org>
Cc: djwong@kernel.org, hch@infradead.org, linux-xfs@vger.kernel.org,
ritesh.list@gmail.com, ojaswin@linux.ibm.com
Subject: Re: [patch v4 2/2] xfs: Fix in xfs_rtalloc_query_range()
Date: Wed, 25 Feb 2026 20:16:29 +0530 [thread overview]
Message-ID: <f9ff2fbb-bcae-4a36-95c5-9d12d24d4a35@gmail.com> (raw)
In-Reply-To: <aZ7on3baf3v3qh0z@nidhogg.toxiclabs.cc>
On 2/25/26 17:49, Carlos Maiolino wrote:
> On Wed, Feb 25, 2026 at 04:58:26PM +0530, Nirjhar Roy (IBM) wrote:
>> On 2/25/26 16:10, Carlos Maiolino wrote:
>>> On Wed, Feb 04, 2026 at 08:36:27PM +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()).
>>> This causes a regression in xfstests's generic/475 running on a RT
>>> device.
>>>
>>> I'm dropping this patch until I have time to investigate what's wrong.
>>
>> I just took a quick glance at generic/475 - It does something related to
>> recovery. I am not sure how this fix is affecting this test. Maybe this fix
>> is triggering some other bug which needs to be fixed. Can you please share
>> the error logs and the local.config you used?
> I will get the info and let you know, I don't have access to my test
> system right now to get the details.
Okay sure, thank you.
>
> What config did you use? I'll give it a try later tonight and see if I
> spot any differences.
I haven't run it yet. But I usually use the following configuration
[xfs_4k]
export TEST_DEV=/dev/loop0
export TEST_DIR=/mnt1/test
export SCRATCH_DEV=/dev/loop1
export SCRATCH_MNT=/mnt1/scratch
export SCRATCH_RTDEV=/dev/loop2
export USE_EXTERNAL=yes
Most of the options are the default ones and/or used by the test script
itself.
--NR
>
>
>> --NR
>>
>>>> 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.
>>>>
>>>> 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>
>>>> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
>>>> Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
>>>> ---
>>>> 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
>>>>
>>>>
>> --
>> Nirjhar Roy
>> Linux Kernel Developer
>> IBM, Bangalore
>>
--
Nirjhar Roy
Linux Kernel Developer
IBM, Bangalore
next prev parent reply other threads:[~2026-02-25 14:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 15:06 [patch v4 0/2] Misc fixes in XFS realtime Nirjhar Roy (IBM)
2026-02-04 15:06 ` [patch v4 1/2] xfs: Replace ASSERT with XFS_IS_CORRUPT in xfs_rtcopy_summary() Nirjhar Roy (IBM)
2026-02-05 16:21 ` Darrick J. Wong
2026-02-05 18:33 ` Nirjhar Roy (IBM)
2026-02-06 12:48 ` Carlos Maiolino
2026-02-06 12:51 ` Nirjhar Roy (IBM)
2026-02-04 15:06 ` [patch v4 2/2] xfs: Fix in xfs_rtalloc_query_range() Nirjhar Roy (IBM)
2026-02-25 10:40 ` Carlos Maiolino
2026-02-25 11:28 ` Nirjhar Roy (IBM)
2026-02-25 12:19 ` Carlos Maiolino
2026-02-25 14:46 ` Nirjhar Roy (IBM) [this message]
2026-02-16 16:42 ` [patch v4 0/2] Misc fixes in XFS realtime Carlos Maiolino
2026-02-16 16:43 ` Nirjhar Roy (IBM)
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=f9ff2fbb-bcae-4a36-95c5-9d12d24d4a35@gmail.com \
--to=nirjhar.roy.lists@gmail.com \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
--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