Re: [PATCH] xfs: rewrite getbmap using the xfs_iext_* helpers

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Mon, Aug 28, 2017 at 09:35:07PM +0200, Christoph Hellwig wrote:
> On Mon, Aug 28, 2017 at 11:31:42AM -0700, Darrick J. Wong wrote:
> > Hmm... this causes at least a couple of xfstests regressions:
> 
> Oh.  Looks like I didn't do a rmap run as none of my runs showed
> a regression.
> 
> > xfs/310, because we no longer merge adjacent bmap records.  I think the
> > solution here is to change the extent count check to allow 2 extents.
> 
> Yeah.
> 
> > xfs/245 because zero-mapping forks are no longer reported as having one
> > big "hole" extent; instead zero extents are reported back.  How do we
> > want to handle this case?
> 
> Hmm.  Looks like that is the COW fork, as even the current code
> never reports a hole at then end when there are no extents at all.
> It does however when we have at least one extent:
> 
> root@brick:/home/hch/work/xfs# uname -a
> Linux brick 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux
> root@brick:/home/hch/work/xfs# truncate --size 10g foo
> root@brick:/home/hch/work/xfs# xfs_bmap foo
> foo: no extents
> root@brick:/home/hch/work/xfs# fallocate -l 10m foo
> root@brick:/home/hch/work/xfs# xfs_bmap foo
> foo:
> 	0: [0..20479]: 786860592..786881071
> 	1: [20480..20971519]: hole
> 
> in this case I suspect we should try to treat the COW fork the
> same.  But let me take a more detailed look at xfs/245 on what's
> going on there.

Aha, I see, it's only if you pass in -e to xfs_bmap then you get a hole record:

$ truncate -s 50m /storage/tmp/a
$ xfs_io -c 'bmap -elpv' /storage/tmp/a
/storage/tmp/a:
 EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET         TOTAL FLAGS
   0: [0..102399]:     hole                                 102400
$ xfs_bmap /storage/tmp/a
/storage/tmp/a: no extents
$ xfs_io -c 'bmap -lpv' /storage/tmp/a
/storage/tmp/a: no extents

(eesh.)

--D

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html