block allocations for the refcount btree

[Dave Chinner]

On Wed, Feb 10, 2016 at 11:07:38AM -0800, Christoph Hellwig wrote:
> 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

I run into that from time to time (maybe once a month) on a vanilla
kernel.

IIRC, the problem is the delayed allocation extent split runs out of
it's reserved block count if you split it enough times. The case
I've seen is that  the indlen calculated in xfs_bmap_worst_indlen()
ends up too small for a subsequent allocation after we've called
xfs_bmap_del_extent() to delete the middle of a delalloc extent too
many times.

Brian had some patches that attempted to solve it - we may have
simply dropped the ball on this (again).

http://oss.sgi.com/archives/xfs/2014-09/msg00337.html

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com