Commit Graph

3 Commits

Author SHA1 Message Date
Qu Wenruo 996e263244 btrfs/14[01]: Use proper helper to get both devid and physical for corruption
[BUG]
With btrfs-progs v5.4, btrfs/140 and btrfs/141 will fail.

[CAUSE]
Both tests are testing re-silvering of RAID1, thus they need to corrupt
on-disk data.

This requires to do manual logical -> physical bytes mapping in the test
case.
However the test case itself uses too many hard coded helper to grab
physical offset, which will change with mkfs.btrfs.

[FIX]
Use more flex helper, to get both devid and physical for such
corruption.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2020-01-06 16:12:39 +08:00
Qu Wenruo 3651c38e0b filter: Introduce filter to filter out offset for xfs_io
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>
2018-01-12 11:40:39 +08:00
Liu Bo 4f2ea4abc1 btrfs: regression test for btrfs dio read repair
This case tests whether dio read can repair the bad copy if we have
a good copy.

Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized
blocks") introduced the regression.

The upstream fix is commit 2e949b0a5592 ("Btrfs: fix invalid
dereference in btrfs_retry_endio")

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>
2017-05-19 15:06:30 +08:00