On Tue, Dec 06, 2016 at 07:49:03PM -0800, Darrick J. Wong wrote: > On Tue, Dec 06, 2016 at 06:45:59AM -0800, Christoph Hellwig wrote: > > I think the problem is that the extents -> btree conversion does not > > use the per-AG reservations, but it should probably use it (even if it > > predates if of course). > > > > In the reproduce the fs still has enough blocks to allocate the > > one block for the first bmap btree leave. But all free space sits > > in AGs with a lower agno then what we used for allocating the actual > > extent, and thus xfs_alloc_vextent never manages to allocate it. > > Wellll... I cobbled together a crappy patch that flips on > XFS_AG_RESV_AGFL if xfs_bmap_extents_to_btree really can't get a block. > It seems to have survived ~175 iterations of xfs/109 so I'll try to > clean it up tomorrow. I tried it with XFS_AG_RESV_METADATA, but that didn't work. But then again I didn't add an additional reservation and I was about to head out for dinner so I didn't investigate the details. It might have been the case Ross pointed out yeserday, so I'll look into the details more today. > Not sure that helps Christoph's situation though... if you're not > running rmap or reflink then the AG reservation is always zero. For now I was just running xfs/109. The customer workload uses reflinks, but not rmap. That being said I think this issue can in theory happen without eithr one due to the way the AG loop works in xfs_alloc_vextext - while we have a reservation for the indirect block(s) there is no guarantee it is in an AG that is greater or equal to that use for the actual extent allocation. -- 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
