block allocations for the refcount btree

[Darrick J. Wong]

On Thu, Mar 03, 2016 at 06:05:56AM -0800, Christoph Hellwig wrote:
> On Wed, Mar 02, 2016 at 01:21:01PM -0800, Darrick J. Wong wrote:
> > Ok.  I think the problem is that making changes to the refcount btree eats
> > up our entire reservation in certain cases.  Can you try the following bandaid?
> > This should give us enough room to handle splitting the btree at both ends
> > of a range that we're refcount-changing.
> 
> This seems to work in general.  I ran into one log related hang when
> running -g auto on nfs, but it's not been reproducible so far.

It still breaks on 1k block filesystems, which confirms my suspicions that
we really need to have enough space in the reservation to handle the worst
case that every block in a n-block truncation has a separate refcountbt
record. :( :(

(Or break up our truncation activities, I suppose...)

--D