This test really wants to test partial file-system block I/Os. Thus, if
the device has a 4K sector size, and the file system has a 4K block
size, there's really no point in running the test. In the attached
patch, I check that the fs block size is larger than the device's
logical block size, which should cover a 4k device block size with a 16k
fs block size.
I verified that the patched test does not run on my 4k sector device
with a 4k file system. I also verified that it continues to run on a
512 byte logical sector device with a 4k file system block size.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Add a helper to check if the filesystem supports sparse files. This is
used to guard tests that exercise sparse file functionality and would
take forever on filesystems that have to zero all blocks on extending
truncates.
Unfortunately there's no good way to autodetect this functionality, so
just implement it as a blacklist for now.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
ext4 was corrupting inode table bitmaps due to a mishmash of
atomic & nonatomic bitops. This got broken twice and fixed
twice; let's add a test.
On a 4-way box this reliably ends up with a corrupted filesystem
if we get it wrong (upstream as of 2.6.35 at least is fine again)
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Dave Chinner <david@fromorbit.com>
This replicates file corruption we've seen with qemu-kvm when
we use if=virtio,cache=none,aio=native for IO to a sparse
ext4- or xfs-hosted file, and the partitions/filesystems
within that file image are not block-aligned. (think sector
63 here...) This results in AIO IOs not aligned to the
filesystem blocks.
This test modifies aiodio_sparse2.c to add an option to start
the file IO at an offset.
When we do 4k writes to a 16k file in 2 threads, starting
at offset 512, we get 0s interspersed in the file where they
should not be:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 |................|
*
00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001200 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 |................|
....
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Dave Chinner <dchinner@redhat.com>