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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
