Re: fiemap issues with XFS

[Pádraig Brady]

On 14/04/11 14:48, Markus Trippelsdorf wrote:
> On 2011.04.14 at 14:34 +0100, Pádraig Brady wrote:
>> Hi Markus,
>>
>> I noticed your fiemap issues here:
>> http://oss.sgi.com/pipermail/xfs/2011-April/050102.html
>>
>> FAIL: cp/fiemap-empty (exit: 1)
>> ===============================
>> ...
>> + fallocate -l 10MiB -n unwritten.withdata
>> + dd count=10 if=/dev/urandom conv=notrunc iflag=fullblock
>> of=unwritten.withdata
>> 10+0 records in
>> 10+0 records out
>> 5120 bytes (5.1 kB) copied, 0.00219578 s, 2.3 MB/s
>> + cp unwritten.withdata cp.test
>> ++ stat -c %s unwritten.withdata
>> ++ stat -c %s cp.test
>> + test 5120 = 5120
>> + cmp unwritten.withdata cp.test
>> unwritten.withdata cp.test differ: char 1, line 1
>> + fail=1
>>
>> cp was changed in 8.11 to not bother reading
>> an extent if it is marked as UNWRITTEN.
>> The comment in fiemap.h says that this means that the
>> space is allocated, but zero.
>>
>> We tested on XFS, on F15 x86_64, which is earlier
>> than your 2.6.39-rc3 and didn't notice this issue.
>>
>> I'm guessing so that XFS is reporting the extent
>> as UNWRITTEN, even though there is data in it now,
>> and that it might sort itself out after a while,
>> or after a sync I suppose (note we also stopped
>> using sync before fiemap for 2.6.39).
>>
>> It would help a lot if you could insert this command
>> into the test above (just before the failing cp)
>> and show the test output again:
>>
>>   filefrag -v unwritten.withdata
> 
> Hi Pádraig,
> 
> here you go:
> + filefrag -v unwritten.withdata                                              
>                                                                        
> Filesystem type is: ef53                                                      
>                                                                        
> File size of unwritten.withdata is 5120 (2 blocks, blocksize 4096)            
>                                                                        
>  ext logical physical expected length flags                                   
>                                                                        
>    0       0   274432            2560 unwritten,eof                           
>                                                                        
> unwritten.withdata: 1 extent found
> 
> Please notice that this also happens with ext4 on the same kernel. 
> Btrfs is fine.

That looks like a bug in XFS :(
I presume if you change `filefrag -v` to `filefrag -vs` that
the output will change, and the test will pass.
I'm a bit surprised that ext4 shows the same thing
as there was supposedly a patch for this issue already
applied for 2.6.39.

It would be great if we got these fixed up before
2.6.29 was released, so that the checks in coreutils 8.11
were valid.

cheers,
Pádraig.