block allocations for the refcount btree

[Christoph Hellwig]

On Tue, Mar 01, 2016 at 10:18:09AM -0800, Darrick J. Wong wrote:
> One side effect of the per-ag block reservation code is that it reserves all
> the blocks that the refcountbt will ever need at mount time, which includes
> decreasing the incore fdblocks counter at mount and putting it back at unmount
> time.  This /should/ eliminate the need for reserving blocks in truncate
> transactions, though clearly this isn't being done correctly.

We're still accouting these blocks in t_blk_res_used through
xfs_alloc_vextent -> xfs_alloc_ag_vextent -> xfs_trans_mod_sb.

I don't really see how the reservation code changes anything about
that accounting.  It just ensures the allocation will succeed through
xfs_ag_resv_needed in xfs_alloc_ag_vextent, and then removes the
allocated block from the reservation using xfs_ag_resv_alloc_block.

Maybe we need to find a way to not account for these blocks.

> So what I'm saying is that I think this problem was with the AGresv code not
> doing accounting correctly, and that I've fixed it in a subsequent rewrite of
> the AGresv code.  I'll post it later, after I figure out why generic/333
> regresses with the new code.

Ok, let's see if the new version helps with the above issue.

> However, there's one thing to be aware of -- if the AGresv uses up all the
> blocks that were preallocated at mount time, the allocator will grab any free
> blocks available and charge the blocks to the transaction, just like before.
> If this ever happens (in theory we reserve enough blocks so that we can have a
> refcount record for every block in the AG) then we'll still have this problem.

It seems like we should simply avoid that this case ever happens.