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.bt...@jan-o-sch.net> > >> Tested-by: <dustym...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
