Hi all,
While I'm developing a new btrfs inband dedup mechanism, I found btrfsck
and kernel doing strange behavior for clone.
[Reproducer]
# mount /dev/sdc -t btrfs /mnt/test
# dd if=/dev/zero of=/mnt/test/file1 bs=4K count=4
# sync
# ~/xfstests/src/cloner -s 4096 -l 4096 /mnt/test/file1 /mnt/test/file2
# sync
Then btrfs-debug-tree gives quite strange result on the data backref:
------
<EXTENT TREE>
item 4 key (12845056 EXTENT_ITEM 16384) itemoff 16047 itemsize 111
extent refs 3 gen 6 flags DATA
extent data backref root 5 objectid 257 offset 0 count 1
extent data backref root 5 objectid 258 offset
18446744073709547520 count 1
<FS TREE>
item 8 key (257 EXTENT_DATA 0) itemoff 15743 itemsize 53
extent data disk byte 12845056 nr 16384
extent data offset 0 nr 16384 ram 16384
extent compression 0
item 9 key (257 EXTENT_DATA 16384) itemoff 15690 itemsize 53
extent data disk byte 12845056 nr 16384
extent data offset 4096 nr 4096 ram 16384
extent compression 0
------
The offset is file extent's key.offset - file exntent's offset,
Which is 0 - 4096, causing the overflow result.
Kernel and fsck all uses that behavior, so fsck can pass the strange thing.
But shouldn't the offset in data backref matches with the key.offset of
the file extent?
And I'm quite sure the change of behavior can hugely break the fsck and
kernel, but I'm wondering is this a known BUG or feature, and will it be
handled?
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
