Re: [PATCH] Btrfs: fix negative qgroup tracking from owner accounting (bug #61951)

[Josef Bacik <jbacik@fusionio.com>]

On Wed, Nov 06, 2013 at 06:20:47PM +0100, Jan Schmidt wrote:
>  
> On Mon, November 04, 2013 at 18:42 (+0100), Josef Bacik wrote:
> > On Thu, Oct 24, 2013 at 03:22:06PM +0200, Jan Schmidt wrote:
> >> btrfs_dec_ref() queued a delayed ref for owner of a tree block. The qgroup
> >> tracking is based on delayed refs. The owner of a tree block is set when a
> >> tree block is allocated, it is never updated.
> >>
> >> When you allocate a tree block and then remove the subvolume that did the
> >> allocation, the qgroup accounting for that removal is correct. However, the
> >> removal was accounted again for each subvolume deletion that also referenced
> >> the tree block, because accounting was erroneously based on the owner.
> >>
> >> Instead of queueing delayed refs for the non-existent owner, we now
> >> queue delayed refs for the root being removed. This fixes the qgroup
> >> accounting.
> >>
> >> Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
> >> Tested-by: <dustymabe@gmail.com>
> > 
> > This breaks btrfs/003, I'm kicking it out.
> 
> Can you be a bit more specific? Works fine here.
> 

It's blowing up on the balance, so maybe make a bigger fs and balance that so
you can see it?  It's exploding in __btrfs_free_extent because we can't find the
ref we're trying to drop, so I assume you've broken the dropping of the reloc
root part where it depends on you giving it btrfs_header_owner() instead of
root->root_key.objectid as when we cow blocks that belong to the reloc root we
leave the owner set to whoever owned the block originally and not the reloc
root.  Thanks,

Josef