On Tue, Aug 20, 2024 at 03:51:23 PM +0800, Zizhi Wo wrote: > 在 2024/8/20 13:53, Chandan Babu R 写道: >> On Mon, Aug 19, 2024 at 08:53:18 AM +0800, Zizhi Wo wrote: >>> Changes since V3[1]: >>> - For the first patch, simply place the modification logic in the >>> xfs_fsmap_owner_to_rmap() function. >>> - For the second patch, more detailed comments were added and related >>> changes were made to the initialization of the end_daddr field. >>> >>> This patch set contains two patches to repair fsmap. Although they are both >>> problems of missing query intervals, the root causes of the two are >>> inconsistent, so two patches are proposed. >>> >>> Patch 1: The fix addresses the interval omission issue caused by the >>> incorrect setting of "rm_owner" in the high_key during rmap queries. In >>> this scenario, fsmap finds the record on the rmapbt, but due to the >>> incorrect setting of the "rm_owner", the key of the record is larger than >>> the high_key, causing the query result to be incorrect. This issue is >>> resolved by fixing the "rm_owner" setup logic. >>> >>> Patch 2: The fix addresses the interval omission issue caused by bit >>> shifting during gap queries in fsmap. In this scenario, fsmap does not >>> find the record on the rmapbt, so it needs to locate it by the gap of the >>> info->next_daddr and high_key address. However, due to the shift, the two >>> are reduced to 0, so the query error is caused. The issue is resolved by >>> introducing the "end_daddr" field in the xfs_getfsmap_info structure to >>> store the high_key at the sector granularity. >>> >>> [1] https://lore.kernel.org/all/20240812011505.1414130-1-wozizhi@xxxxxxxxxx/ >>> >> The two patches in this series cause xfs_scrub to execute >> indefinitely >> immediately after xfs/556 is executed. >> The fstest configuration used is provided below, >> FSTYP=xfs >> TEST_DIR=/media/test >> SCRATCH_MNT=/media/scratch >> TEST_DEV=/dev/loop16 >> TEST_LOGDEV=/dev/loop13 >> TEST_RTDEV=/dev/loop12 >> TEST_FS_MOUNT_OPTS="-o rtdev=/dev/loop12 -o logdev=/dev/loop13" >> SCRATCH_DEV_POOL="/dev/loop5 /dev/loop6 /dev/loop7 /dev/loop8 >> /dev/loop9 /dev/loop10 /dev/loop11" >> MKFS_OPTIONS="-f -m reflink=0,rmapbt=0, -d rtinherit=1 -lsize=1g" >> SCRATCH_LOGDEV=/dev/loop15 >> SCRATCH_RTDEV=/dev/loop14 >> USE_EXTERNAL=yes >> > > Sorry, running xfs/556 with this configuration was successful in my > environment, and my mkfs.xfs version is 6.8.0: > > xfs/556 > FSTYP -- xfs (debug) > PLATFORM -- Linux/x86_64 fedora 6.11.0-rc3-00015-g1a9f212eb19f #42 > SMP PREEMPT_DYNAMIC Fri Aug 16 10:19:47 CST 2024 > VMIP -- 192.168.240.11 > MKFS_OPTIONS -- -f -f -m reflink=0,rmapbt=0 -d rtinherit=1 -l size=1g > /dev/vde > MOUNT_OPTIONS -- /dev/vde /tmp/scratch > > xfs/556 4s ... 5s > Ran: xfs/556 > Passed all 1 tests > > I am not sure if it is because of the specific user mode tools or other > environment configuration differences caused? > My Linux kernel is based on v6.11-rc4. The sources can be found at https://github.com/chandanr/linux/commits/xfs-6.11-fixesC-without-jump-label-fixes/. Please note that I have reverted commits modifying kernel/jump_label.c. This is to work around https://lore.kernel.org/linux-xfs/20240730033849.GH6352@frogsfrogsfrogs/. Also, I am running xfsprogs v6.9.0. The sources can be found at https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/log/?qt=range&q=v6.9.0 -- Chandan
