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