[Bug 201259] [xfstests shared/010]: maybe pagecache contents is mutated after cycle mount

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=201259

Eric Sandeen (sandeen@sandeen.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandeen@sandeen.net

--- Comment #1 from Eric Sandeen (sandeen@sandeen.net) ---
In trying to get to a more targeted reproducer, this script clearly exposes
stale data, though I'm not seeing an md5sum change across the remount.  The
operations below are a subset of an fsstress sequence that caused a failure in
shared/010 for me.

---
#!/bin/bash

DEV=/dev/pmem0p2
MNT=/mnt/scratch

umount $MNT
xfs_io -d -c "pwrite -S 0x58 0 16g" $DEV
mkfs.xfs -m reflink=1 $DEV
mount $DEV $MNT

DONOR1=$MNT/donor1
DONOR2=$MNT/donor2
TARGET=$MNT/file

rm -f $DONOR1 $DONOR2 $TARGET

xfs_io -f -c "pwrite -S 0x72 0 1772544" $DONOR1
xfs_io -f -c "pwrite -S 0x52 0 840263" $DONOR2

touch $TARGET

xfs_io -f \
        -c "falloc -k 624393 840278"    \
        -c "reflink $DONOR1 925696 212992 57344" \
        -c "pwrite -S 0x57 1662464 74240" \
        -c "fdatasync" \
        -c "reflink $DONOR2 585728 5357568 122880" \
                $TARGET

md5sum $TARGET
umount $MNT
mount $DEV $MNT
md5sum $TARGET
xfs_bmap -vvp $TARGET
hexdump -C $TARGET
---

95580da3cda8eb09c23c8deefb347d77  /mnt/scratch/file
95580da3cda8eb09c23c8deefb347d77  /mnt/scratch/file
/mnt/scratch/file:
 EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
   0: [0..415]:        hole                                   416
   1: [416..527]:      3648..3759        0 (3648..3759)       112 100000 (first
reflink)
   2: [528..1215]:     hole                                   688
   3: [1216..2863]:    192..1839         0 (192..1839)       1648 010000
(fallocated)
   4: [2864..3239]:    hole                                   376
   5: [3240..3455]:    5304..5519        0 (5304..5519)       216 000000
(pwrite)
   6: [3456..10463]:   hole                                  7008
   7: [10464..10703]:  6664..6903        0 (6664..6903)       240 100000 (2nd
reflink)


00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
(hole)
*
00034000  72 72 72 72 72 72 72 72  72 72 72 72 72 72 72 72  |rrrrrrrrrrrrrrrr|
(first reflink)
*
00042000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
(hole + fallocated)
*
00195e00  57 57 57 57 57 57 57 57  57 57 57 57 57 57 57 57  |WWWWWWWWWWWWWWWW|
(pwrite)
*
001a8000  58 58 58 58 58 58 58 58  58 58 58 58 58 58 58 58  |XXXXXXXXXXXXXXXX|
(stale 32k)
*
001b0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
(hole)
*
0051c000  52 52 52 52 52 52 52 52  52 52 52 52 52 52 52 52  |RRRRRRRRRRRRRRRR|
(2nd reflink)
*
0053a000


the "XXXXXXX" is exposed stale data (no pwrite in the script wrote 'X', that is
the disk pattern)
The pattern starts right after the end of the pwrite call of the script.  There
also seems to be a reflinked extent prior to the pwrite.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.