xfs_repair compares attr names in the root namespace to
two special/reserved names, "SGI_ACL_FILE" and "SGI_ACL_DEFAULT"
and if the value in them aren't valid acls, flags this as
an inconsistency.
However, due to various bugs, xfs_repair may only compare
a smaller portion of the on-disk value; hence either
substrings or superstrings may match, and false-positive
corruption will be detected. This test checks for those
false positives; i.e. the ACL names created in this test
may cause xfs_repair to "fix" them, but it should not.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This is to detect whether filesystem supports shutdown feature or not.
And let use this into the following xfs tests.
xfs/053 (data exposure)
xfs/137 (data vs filesize)
xfs/138 (data vs filesize vs truncate)
xfs/139 (data vs filesize vs partial truncate)
xfs/140 (data vs filesize vs extending truncate)
xfs/179 (data vs filesize w/ fsync)
xfs/180 (data vs filesize w/ sync)
xfs/182 (data vs filesize w/ recovery)
xfs/200 (recovery vs ro-block device)
xfs/306 (fsstress vs recovery)
xfs/085
xfs/086
xfs/087
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
XFS buffered I/O writeback has a subtle race condition that leads to
stale data exposure if the filesystem happens to crash after delayed
allocation blocks are converted on disk and before data is written back
to said blocks.
Use file allocation commands to attempt to reproduce a related, but
slightly different variant of this problem. The associated falloc
commands can lead to partial writeback that converts an extent larger
than the range affected by falloc. If the filesystem crashes after the
extent conversion but before all other cached data is written to the
extent, stale data can be exposed.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>