When we're using dm-error to simulate failed devices, we don't really
know if the write or the fdatasync is going to receive the EIO. For
tests that make a single (failed) write attempt and never retry, it's
sufficient to check that the file md5 doesn't change after recovery.
For tests that /do/ retry the write, we should capture the entire output
and just look for the word error instead of enshrining the exact perror
message (filename/function call and everything) in the golden output.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Upstream xfs_io has been converted to always use LFS compliant
(i.e. 64 bit) pwrite() rather than pwrite64(). Similar changes have
been made for multiple syscalls that have "*64" variants. hence the
error output of all these commands has changed, such as "pwrite64:
..." to "pwrite: ....".
Make a filter to catch the *64 variants and strip it, and
convert all the golden output to use the non-*64 variant. This will
make all golden output matching work correctly regardless of what
version of xfs_io is in use.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test various scenarios (with dm-flakey) where we simulate write
failures during CoW, to see if the FS can get through it without
blowing up or corrupting data. Plumb in a FS-generic method to
sort out repairing filesystems after they get hit by IO errors.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Darrick J. Wong
Dave Chinner