Those 2 tests fail on btrfs on a ppc64 system with 64k pages. This is
caused by the improved minimum device size calculation in upstream
btrfs-progs (commit: 31d228a2eb98 ("btrfs-progs: mkfs: Enhance minimal
device size calculation to fix mkfs failure on small file")).i
Xfstests implicitly uses '--mixed' options for filesystems smaller than
256mb thus the minimum filesystem size require is derived from the
following equation: 2 * (4mb + nodesize << 10). On a 64k page system
this evaluates to 2 * (4m + 64m) = 136m. This resuts in failures such:
mkfs.btrfs -b $((100 * 1048576)) btrfs-test.img
ERROR: size 104857600 is too small to make a usable filesystem
ERROR: minimum size for btrfs filesystem is 114294784
when running _scratch_mkfs_sized $((100 * 1048576)).
Fix this by increasing the minimum filesystem size to 196 megabytes
which makes mkfs.btrfs happy again and allows the test to proceed.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On reflink+rmapbt XFs filesystems there isn't enough free space to
run this test on the 64MB filesystem image created. It notruns with
a curious error message - needs at least 0GB free:
generic/250 [10:01:57] [10:01:58] [not run]
generic/250 -- This test requires at least 0GB free on /mnt/scratch to run
Fix this by increasing the size of the base filesystem image.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
To better exercise the data path code of realtime subvolumes, we
will set rtinherit=1 during mkfs calls. For tests which this is not
desired we introduce a _require_no_rtinherit function to opt out of
this behavior.
Signed-off-by: Richard Wareing <rwareing@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
When testing with data=journal ext4, direct write to dmerror device
doesn't return EIO, because ext4 turns direct write to buffered
write in data=journal mode and all data is written to journal
buffer. The write only fails later when commiting journal and error
messages can be seen in dmesg.
As the test is checking on the md5 checksum of the test file, it's
ok to ignore the IO error returned by xfs_io, as long as the
checksums match the golden image.
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
There were a number of tests that use Direct I/O that weren't testing
to make sure O_DIRECT is actually supported. This will be important
for avoiding false positives when testing ext4 encryption (which does
not support DIO for obvious reasons).
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check that we don't expose old disk contents when a directio write to
an unwritten extent fails due to IO errors. This primarily affects
XFS and ext4.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Nikolay Borisov
Dave Chinner
Richard Wareing
Eryu Guan
Theodore Ts'o
Darrick J. Wong