This is obviously wrong and makes ./check -r skip over tests on ext4
with "ext4 on $DEV not configured with metadata journaling".
Signed-off-by: Ilya Dryomov <idryomov@gmail.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>
To avoid having many tests repeating the following pattern:
_load_flakey_table $FLAKEY_DROP_WRITES
_unmount_flakey
_load_flakey_table $FLAKEY_ALLOW_WRITES
_mount_flakey
add the helper function _flakey_drop_and_remount to remove
the existing duplicated code and serve as a shortcut.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
generic/085 was failing on a machine w/o devicemapper kernel
support because it requires the linear target, but didn't
explicitly test for it.
I could have cut & pasted _require_dm_linear(), but chose
to go the route of a generic helper, _require_dm_target $FOO,
because some day someone will need the zero target, the error
target, or who knows.
Add the helper, use it in test generic/085, and convert
_require_dm_flakey, _require_dm_snapshot, and
_dmerror_required with this new helper.
Reported-by: Angelo Dureghello <angelo.dureghello@nomovok.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
For busy-box systems that don't support the extended format options.
Signed-off-by: Ari Sundholm <ari@tuxera.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Many tests use dm_flakey to trigger log replay, but for filesystems that
don't support metadata journaling, this causes failures when it shouldn't.
(i.e. we can hardly test log replay if there is no log, and the subsequent
filesystem check will turn up errors).
For some tests they actually sync everything we care about, and find
inconsistencies elsewhere, but I erred on the side of simply not running
the test in most cases.
Tested-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test is motivated by an fsync issue discovered in btrfs.
The steps to trigger the issue were:
1) remove an hard link from an inode with a large number of hard links;
2) add a new hard link;
3) add another hard link with the same name as the one removed in step 1;
4) fsync the inode.
These steps made the btrfs fsync log replay fail (with the -EOVERFLOW
error), making the filesystem unmountable, requiring the use of
btrfs-zero-log (it wipes the fsync log) in order to make the filesystem
mountable again (but losing some data/metadata).
The btrfs issue was fixed by the following linux kernel patches:
Btrfs: fix fsync when extend references are added to an inode
Btrfs: fix fsync log replay for inodes with a mix of regular refs and extrefs
This issue was present in btrfs since the extrefs (extend references)
feature was added (2012).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Ilya Dryomov
Theodore Ts'o
Filipe Manana
Eric Sandeen
Ari Sundholm