On Mon, Dec 05, 2016 at 10:28:02AM -0800, Darrick J. Wong wrote: > Hmm. Purely speculating here (I haven't yet been able to reproduce it) > but I wonder if we're nearly out of space, fdblocks is still large > enough that we can start delalloc reservations, but something is > stealing blocks out of the AGs such that when we go to look for one > there aren't any (or the per AG reservation denies it). > > Does it happen if rmapbt=0 ? Since xfs/109 isn't doing any CoW, it's > possible that this could be another symptom of the bug where we reserve > all the bmap+rmap blocks we need via indlen, but discard the entire > reservation in the transaction roll that happens before we start the > rmap update, which effectively means we're allocating space that we > didn't previously reserve... I'm pretty sure it's something like that, but I don't think rmap needs to be in the game - at least my customer report does not have rmap enabled. > I suppose you could constrict the reflink exception thing further by > passing bma->flags to xfs_bmap_extents_to_btree and only allowing the > ENOSPC retry if XFS_BMAPI_REMAP is set. Well, we assert on having an allocation even without that exception, so I'm not sure that would help us - it's just an oddity I noticed while looking at the code. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
