Re: [PATCH] Prevent extent btree block allocation failures

[Lachlan McIlroy <lachlan@sgi.com>]

Christoph Hellwig wrote:
> On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote:
>> This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(),
>> xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs
>> for the space needed.  Since we have reserved the space these allocations
>> are now guaranteed to succeed.
> 
> This looks good and makes lot of sense to me.  Please also add a comment
> to enum xfs_alloctype in xfs_alloc.h about the danger of the allocation
> types that never go out of the AG when used inside transactions.

The flags already have comments?  Are you referring specifically to the
fact we have reserved space somewhere in the filesystem but expect to find
it in a single AG?

> 
>> In order to search all AGs I had to revert
>> a change made to xfs_alloc_vextent() that prevented a search from looking
>> at AGs lower than the starting AG.  This original change was made to prevent
>> out of order AG locking when allocating multiple extents on data writeout
>> but since we only allocate one extent at a time now this particular problem
>> can't happen.
> 
> This one also makes sense, but I have a very bad gut feeling about it.
> There's nothing preventing the same deadlock scenario from coming back
> when people modify the highlevel data allocator again.  We really need
> some sort of assert to trigger early in that case to not got a nasty
> hard to trigger deadlock.

Yes I agree.  I was thinking about making the allocation of a second data
extent in the same transaction a conditional try operation to avoid the
deadlock.  If a caller to the allocator provides room to return more than
one extent then I don't think we have to return more than one - multiple
extents in one transaction is just an optimisation.

> 
>> +			if (++(args->agno) == mp->m_sb.sb_agcount)
> 
> and while we're at it this should be
> 
> 			if (++args->agno == mp->m_sb.sb_agcount)

Done, thanks.