xfs
[Top] [All Lists]

[PATCH 0/3 v5] XFS TESTS: Add Fallocate Punch Hole Tests

To: linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>, Ext4 Developers List <linux-ext4@xxxxxxxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Subject: [PATCH 0/3 v5] XFS TESTS: Add Fallocate Punch Hole Tests
From: Allison Henderson <achender@xxxxxxxxxxxx>
Date: Mon, 06 Jun 2011 16:32:27 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
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

<Prev in Thread] Current Thread [Next in Thread>
  • [PATCH 0/3 v5] XFS TESTS: Add Fallocate Punch Hole Tests, Allison Henderson <=