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 Which asserts that the current transaction is using up more blocks from its reservation than it reserved. The AG reservation seems to operate on a different level than that. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
