Re: block allocations for the refcount btree

[Christoph Hellwig <hch@xxxxxxxxxxxxx>]

On Wed, Feb 10, 2016 at 01:50:10AM -0800, Darrick J. Wong wrote:
> That's odd... I'd have thought that the AG reservation would always be able
> to handle a refcount btree expansion, since it calculates how many blocks
> are needed to handle the worst case of 1 record per extent.  There's also
> a bug where we undercount the number of blocks already used, so it should
> have an extra big reservation.
> 
> OTOH I've seen occasional ENOSPCs in generic/186 and generic/168 too, so I
> guess something's going wrong.  Maybe the xfs_ag_resv* tracepoints can help?

I'm not seeing an ENOSPC, I run into:

[  640.924891] XFS: Assertion failed: tp->t_blk_res_used <= tp->t_blk_res, 
file: fs/xfs/xfs_trans.c, line: 315

Which asserts that the current transaction is using up more blocks from
its reservation than it reserved.  The AG reservation seems to operate
on a different level than that.