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.
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...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|