Test that if we do a buffered write to a file, fsync it, clone a
range from another file into our file that overlaps the previously
written range, fsync the file again and then power fail, after we
mount again the filesystem, no file data was lost or corrupted.
This test is motivated by a bug found in btrfs, which is fixed by a
patch for the linux kernel titled:
"Btrfs: fix file data corruption after cloning a range and fsync"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Tests were merged with high seq numbers to avoid conflicts with
other tests. Now renumber them to contiguous numbers, as all other
tests have been merged correctly. This is easier to do than
assigning the final seq numbers at commit time.
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test is motivated by this inconsistency found in ext4 during random
crash consistency tests:
*** fsck.ext4 output ***
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Inode 12, end of extent exceeds allowed value
(logical block 33, physical block 33817, len 7)
Clear? no
Inode 12, i_blocks is 240, should be 184. Fix? no
This test uses device mapper flakey target to demonstrate the bug
found using device mapper log-writes target.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Filipe Manana
Eryu Guan
Amir Goldstein