Re: block allocations for the refcount btree

Christoph Hellwig
2016-02-10T19:07:43Z

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.