Re: block allocations for the refcount btree

Christoph Hellwig
2016-02-12T19:10:49Z

On Thu, Feb 11, 2016 at 08:40:58AM +1100, Dave Chinner wrote:
> 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

I'm pretty sure that is a separate issue. With the refcount btree we may
allocate an extent (or rather just a single block) in xfs_alloc_ag_vextent
as called from xfs_refcountbt_alloc_block. The reservation helps us to
ensure this block is always available, but we still need to account for
that in xfs_trans_reserve(), which we currently don't do for itruncate
transactions.