block allocations for the refcount btree

[Darrick J. Wong]

On Sat, Feb 13, 2016 at 01:33:10PM +1100, Dave Chinner wrote:
> On Fri, Feb 12, 2016 at 11:10:46AM -0800, Christoph Hellwig wrote:
> > 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.  

Hmm.  The per-AG reservation clients also had some problems counting the number
of tree blocks in use as part of setting up the reservation; that might have
had something to do with it.  Dunno, I'll go look at that part of the code
again when I finish interval query support for rmap.

> Ok, so we may have two different issues with a similar failure
> symptom. As it is, I don't think this is a show stopper - we're
> expecting to find these sorts of issues as we go along (hence the
> experimental tag on the feature) and I think, at this point, getting
> review and an initial merge done is more important...

I've noticed that I can trigger that assert (the log reservation one) fairly
regularly when running xfs/140 on a 800MB disk.

Brain dead, going to bed.  Next on my list is to rebase the more stable
parts of the patchset against Dave's for-4.6 branch and do another mass
mailing.

--D

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david at fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs