[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fiemap issues with XFS
From: |
Markus Trippelsdorf |
Subject: |
Re: fiemap issues with XFS |
Date: |
Thu, 14 Apr 2011 15:48:05 +0200 |
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