xfstests 252 failure

[Eric Sandeen]

On 6/14/11 10:41 AM, Allison Henderson wrote:
> Hi all,
> 
> I just wanted to get some ideas moving on this question before too
> much time goes by. Ext4 is currently failing xfstest 252, test number
> 12. Currently test 12 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

so the file should go through these steps:
(H=hole, P=prealloc, D=data)

0k                       20k
|  H |  H |  H |  H |  H | (truncate)
|  P |  P |  P |  P |  P | (alloc_cmd)
|  P |  P |  D |  P |  P | (pwrite)
<fsync>                    (fsync)
|  P |  H |  H |  H |  P | (punch)
 
> 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. 

so it's like this?

0: [0..7]: data
1: [8..31]: hole
2: [32..39]: data

> I did some
> investigating and it looks like the fsync command causes the extents
> to be written out before the punch hole operation starts. It looks
> like 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.

Yes, it does do that IIRC.

I probably need to look closer, but any test which expects exact
layouts from a filesystem after a series of operations is probably
expecting too much...