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>
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