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>
This makes it clear when we are using "mount ; umount" versus "mount
-o remount" for most file systems. The reason for this distinction is
(a) tests may want to test the difference between what happens on the
remount versus the munt paths, (b) with tmpfs, "mount ; umount" will
cause the contents of all of the files to disappear which makes many
tests sad, and (c) some mount options may not be changed using "mount
-o remount".
Currently _scratch_mount performs "_scratch_mount ; _scratch_umount"
so mechnically rename this function to _scratch_cycle_mount. This was
done mechnically using the script fragment:
git grep "_scratch_remount" | \
awk -F: '{print $1}' | sort -u | \
xargs sed -i 's/_scratch_remount/_scratch_cycle_mount/g'
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that after truncating a file into the middle of a hole causes the
new size of the file to be persisted after a clean unmount of the
filesystem (or after the inode is evicted). This is for the case where
all the data following the hole is not yet durably persisted, that is,
that data is only present in the page cache.
This test is motivated by an issue found in btrfs, which got fixed by
the patch titled:
"Btrfs: fix shrinking truncate when the no_holes feature is enabled"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Theodore Ts'o
Filipe Manana