Re: fiemap issues with XFS

[Markus Trippelsdorf]

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.
-- 
Markus