On Wed, Mar 14, 2018 at 8:03 AM, Edmund Nadolski <enadolski@xxxxxxxx> wrote: > This patch addresses an issue that causes fiemap to falsely > report a shared extent. The test case is as follows: > > # cat do_xfs_io > xfs_io -f -d -c "pwrite -b 16k 0 64k" -c "fiemap -v" /media/scratch/file5 > sync > xfs_io -c "fiemap -v" /media/scratch/file5 > > which gives the resulting output: > > # . do_xfs_io > wrote 65536/65536 bytes at offset 0 > 64 KiB, 4 ops; 0.0000 sec (121.359 MiB/sec and 7766.9903 ops/sec) > /media/scratch/file5: > EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS > 0: [0..127]: 24576..24703 128 0x2001 > /media/scratch/file5: > EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS > 0: [0..127]: 24576..24703 128 0x1 > > This is because btrfs_check_shared calls find_parent_nodes > repeatedly in a loop, passing a share_check struct to report > the count of shared extent. But btrfs_check_shared does not > re-initialize the count value to zero for subsequent calls > from the loop, resulting in a false share count value. This > is a regressive behavior from 4.13. > > With proper re-initialization the test result is as follows: > > # . do_xfs_io > wrote 65536/65536 bytes at offset 0 > 64 KiB, 4 ops; 0.0000 sec (110.035 MiB/sec and 7042.2535 ops/sec) > /media/scratch/file5: > EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS > 0: [0..127]: 24576..24703 128 0x1 > /media/scratch/file5: > EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS > 0: [0..127]: 24576..24703 128 0x1 > > which corrects the regression. > A fstest case for this would be appreciated. thanks, liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
