These four tests check that mmap'd cow writes fail when the
filesystem goes down. For regular filesystems the msync reports
EIO, but if quotas are enabled on xfs the write itself terminates
xfs_io with a SIGBUS. We don't care how the write fails, so don't
let the SIGBUS report escape to the golden output.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
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>
The check script requires that it be run as root, so adding
individualized checks for this in each teat is not needed.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.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
Theodore Ts'o