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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
