Hi All,
Here is v5 of the punch hole tests that I have been working with Dave on. In v4 I merged in the non over-lapping tests from v3 into 252, and I separated the code paths for punch hole and fallocate in the fsx patch. In v5, patch 1 was re based to the latest xfstests code due to activity that had caused the patch to not apply. I've also included the ENOSPC test that we used in the ext4 punch hole tests. Some things I need some feedback on:
Ext4 is currently having a hard time passing xfstest 252, test number 12. The test is:
$XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \
-c "$alloc_cmd 0 20k" \
-c "pwrite 8k 4k" -c "fsync" \
-c "$zero_cmd 4k 12k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ]&& die_now
and the output is:
12. unwritten -> data -> unwritten
0: [0..7]: unwritten
1: [8..31]: hole
2: [32..39]: unwritten
Ext4 gets data extents here instead of unwritten extents. I did some investigating and it looks like the fsync command causes the extents to be written out before the punch hole operation even starts. I believe what happens is that when an unwritten extent gets written to, it doesnt always split the extent. If the extent is small enough, then it just zeros out the portions that are not written to, and the whole extent becomes a written extent. Im not sure if that is incorrect or if we need to change the test to not compare the extent types.
Also, we had a test for ext4 punch hole that tests to see if a hole can still be punched when the disk is full. The test has been modified to use the xfsprogs facilities to fit the xfstests framework, but has become very slow. I found that if I replace the line:
$XFS_IO_PROG -F -f -c "pwrite 0 $file_size" $dir/$file_count.bin&> /dev/null
with the original code:
dd if=/dev/zero of=$dir/$file_count.bin bs=$file_size count=1 &> /dev/null
it becomes a lot faster (takes off almost 15 minutes). Is there anything we can do to improve the xfsprogs command? Thx!
Allison Henderson
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
