Re: fiemap issues with XFS

[Markus Trippelsdorf]

On 2011.04.14 at 14:53 +0100, Pádraig Brady wrote:
> 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.

You're right `filefrag -vs` fixes the issue on both xfs and ext4.

-- 
Markus