https://bugzilla.kernel.org/show_bug.cgi?id=201259 --- Comment #3 from Eric Sandeen (sandeen@xxxxxxxxxxx) --- Here's a slightly simpler test on smaller, block boundaries: xfs_io -f -c "pwrite -S 0x72 0 4096" $DONOR1 xfs_io -f -c "pwrite -S 0x52 0 4096" $DONOR2 xfs_io -f \ -c "falloc -k 8192 4096" \ -c "reflink $DONOR1 0 4096 4096" \ -c "pwrite -S 0x57 65536 8192" \ -c "fdatasync" \ -c "reflink $DONOR2 0 131072 4096" \ $TARGET By block, it does these operations, all within 32 blocks: 11111111112222222222333 012345678901234567890123456789012 P R WW R P = preallocate R = reflink W = write What we should get out is: HRPHHHHHHHHHHHHHWWHHHHHHHHHHHHHHR H = Hole What we do get out is: HRPHHHHHHHHHHHHHWWSSSSSSSSSSSSSSR S = Stale The extents: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..7]: hole 8 1: [8..15]: 112..119 0 (112..119) 8 100000 2: [16..23]: 104..111 0 (104..111) 8 010000 3: [24..127]: hole 104 4: [128..255]: 216..343 0 (216..343) 128 000000 5: [256..263]: 120..127 0 (120..127) 8 100000 are lined up as (chars represent hole/reflink/prealloc/written/stale) H R P HHHHHHHHHHHHH WWSSSSSSSSSSSSSS R [E][E][E][ E ][ E ][E] So the 5th extent is what has exposed the stale data, with written data only in the first 2 blocks and another 14 blocks exposed up to the next reflinked block. -- You are receiving this mail because: You are watching the assignee of the bug.
