在 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? Thanks, Zizhi Wo
