Re: [PATCH v2] xfs: Make fiemap works with sparse file.

[Dave Chinner]

On Sat, Jun 12, 2010 at 10:08:15AM +0800, Tao Ma wrote:
> In xfs_vn_fiemap, we set bvm_count to fi_extent_max + 1 and want
> to return fi_extent_max extents, but actually it won't work for
> a sparse file.

Define "won't work". i.e. what's the test case?  I just created a
sparse file and checked it, and it reported all the extents in it:

# xfs_bmap -vp testfile 
testfile:
 EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
   0: [0..7]:          hole                                     8
   1: [8..15]:         96..103           0 (96..103)            8 00000
   2: [16..23]:        hole                                     8
   3: [24..31]:        112..119          0 (112..119)           8 00000
   4: [32..39]:        hole                                     8
   5: [40..47]:        128..135          0 (128..135)           8 00000
   6: [48..55]:        hole                                     8
   7: [56..63]:        144..151          0 (144..151)           8 00000
   8: [64..71]:        hole                                     8
   9: [72..79]:        160..167          0 (160..167)           8 00000
  10: [80..87]:        hole                                     8
  11: [88..95]:        176..183          0 (176..183)           8 00000
  12: [96..103]:       hole                                     8
  13: [104..111]:      192..199          0 (192..199)           8 00000
  14: [112..119]:      hole                                     8
  15: [120..127]:      208..215          0 (208..215)           8 00000
# filefrag -v testfile 
Filesystem type is: 58465342
File size of testfile is 65536 (16 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       1       12               1 
   1       3       14       12      1 
   2       5       16       14      1 
   3       7       18       16      1 
   4       9       20       18      1 
   5      11       22       20      1 
   6      13       24       22      1 
   7      15       26       24      1 eof
testfile: 9 extents found
#

FWIW, filefrag seems busted - the file has 8 extents, not 9.

For a more fragmented sparse file (25,000 extents):

# for i in `seq 1 2 50000`; do dd if=/dev/zero of=testfile bs=4k count=1 seek=$i; done
....
# xfs_bmap -vp testfile | grep -v hole | wc -l
25002
# filefrag -v testfile |tail -1
testfile: 25001 extents found

So taking away the 2 header lines from xfs_bmap output we have 25000
extents, and filefrag has over-counted by one again. However, we are
we are definitely finding all the extents through fiemap...

> The reason is that in xfs_getbmap we will
> calculate holes and set it in 'out', while out is malloced by
> bmv_count(fi_extent_max+1) which didn't consider holes. So in the
> worst case, if 'out' vector looks like
> [hole, extent, hole, extent, hole, ... hole, extent, hole],
> we will only return half of fi_extent_max extents.

Right, it's not broken, we simply return less than fi_extent_mex
extents when there are holes. I don't see that as a problem as
applications have to handle that case anyway, and....

> So in xfs_vn_fiemap, we should consider this worst case. If the
> user wants fi_extent_max extents, we need a 'out' with size of
> 2 *fi_extent_max + 2(one more the header).

That's rather dangerous, I think. It relies on other code to catch
the buffer overrun that this sets up for fragmented, non-sparse
files. Personally I'd much prefer to return fewer extents for sparse
files than to add a landmine like this into the kernel code....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/