summaryrefslogtreecommitdiff
path: root/tests/btrfs/143.out
AgeCommit message (Collapse)Author
2019-12-30btrfs/14[23]: Use proper help to get both devid and physical offset for ↵Qu Wenruo
corruption. [BUG] When using btrfs-progs v5.4, btrfs/142 and btrfs/143 will fail: btrfs/142 1s ... - output mismatch (see xfstests/results//btrfs/142.out.bad) --- tests/btrfs/142.out 2018-09-16 21:30:48.505104287 +0100 +++ xfstests/results//btrfs/142.out.bad 2019-12-10 15:35:40.280392626 +0000 @@ -3,37 +3,37 @@ XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) wrote 65536/65536 bytes XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ -XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ ... (Run 'diff -u xfstests/tests/btrfs/142.out xfstests/results//btrfs/142.out.bad' to see the entire diff) [CAUSE] Btrfs/14[23] test whether a read on corrupted stripe will re-silver itself. Such test by its nature will need to modify on-disk data, thus need to get the btrfs logical -> physical mapping, which is done by near hard-coded lookup function, which rely on certain stripe:devid sequence. Recent btrfs-progs commit c501c9e3b816 ("btrfs-progs: mkfs: match devid order to the stripe index") changes how we use devices in mkfs.btrfs, this caused a change in chunk layout, and break the hard-coded stripe:devid sequence. [FIX] This patch will do full devid and physical offset lookup, instead of old physical offset only lookup. The only assumption made is, mkfs.btrfs assigns devid sequentially for its devices. Which means, for "mkfs.btrfs $dev1 $dev2 $dev3", we get devid 1 for $dev1, devid 2 for $dev2, and so on. This change will allow btrfs/14[23] to handle even future chunk layout change. (Although I hope this will never happen again). This also addes extra debug output (although less than 10 lines) into $seqres.full, just in case when layout changes and current lookup can't handle it, developer can still pindown the problem easily. Reported-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Tested-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2018-01-12filter: Introduce filter to filter out offset for xfs_ioQu Wenruo
Some test cases (AFAIK, btrfs RAID recovery test cases) read out certain location to verify its data. Such read is mostly OK, but the golden output contains the on-disk offset, which can differ due to underlying chunk change. (This time is mkfs chunk layout change for btrfs) So introduce macro _filter_xfs_io_offset to filter out the offset part wrote 65536/65536 bytes at offset 136708096 ^^^^^^^^^^^^^^^^^^^^ And offset from "pread -v" 08260000: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................ ^^^^^^^^^ Only btrfs/14[0-3] are affected. Reported-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Eryu Guan <eguan@redhat.com> Signed-off-by: Eryu Guan <eguan@redhat.com>
2017-05-19btrfs: regression test for nocsum buffered read's repairLiu Bo
This is to test whether buffered read retry-repair code is able to work in raid1 case as expected. Please note that without checksum, btrfs doesn't know if the data used to repair is correct, so repair is more of resync which makes sure that both of the copy has the same content. Commit 20a7db8ab3f2 ("btrfs: add dummy callback for readpage_io_failed and drop checks") introduced the regression. The upstream fix is commit 9d0d1c8b1c9d ("Btrfs: bring back repair during read") Signed-off-by: Liu Bo <bo.li.liu@oracle.com> Reviewed-by: Eryu Guan <eguan@redhat.com> Reviewed-by: Filipe Manana <fdmanana@gmail.com> Signed-off-by: Eryu Guan <eguan@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-01 03:22:27 +0000