From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com, "Darrick J. Wong" <darrick.wong@oracle.com>
Subject: Re: block allocations for the refcount btree
Date: Thu, 11 Feb 2016 08:40:58 +1100 [thread overview]
Message-ID: <20160210214058.GN14668@dastard> (raw)
In-Reply-To: <20160210190738.GA13051@infradead.org>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-02-10 21:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-10 9:30 block allocations for the refcount btree Christoph Hellwig
2016-02-10 9:50 ` Darrick J. Wong
2016-02-10 19:07 ` Christoph Hellwig
2016-02-10 21:40 ` Dave Chinner [this message]
2016-02-11 14:09 ` Brian Foster
2016-02-11 20:21 ` Dave Chinner
2016-02-12 19:10 ` Christoph Hellwig
2016-02-13 2:33 ` Dave Chinner
2016-02-13 4:44 ` Darrick J. Wong
2016-02-13 8:02 ` Christoph Hellwig
2016-02-13 7:48 ` Christoph Hellwig
2016-02-14 0:21 ` Dave Chinner
2016-03-01 18:18 ` Darrick J. Wong
2016-03-01 20:40 ` Christoph Hellwig
2016-03-02 5:24 ` Darrick J. Wong
2016-03-02 9:59 ` Christoph Hellwig
2016-03-02 16:41 ` Darrick J. Wong
2016-03-02 16:57 ` Christoph Hellwig
2016-03-02 21:21 ` Darrick J. Wong
2016-03-03 14:05 ` Christoph Hellwig
2016-03-04 1:36 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160210214058.GN14668@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox