Re: [PATCH] Btrfs: fix loading of orphan roots leading to BUG_ON

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Duncan wrote on 2016/03/03 04:31 +0000:
> fdmanana posted on Wed, 02 Mar 2016 15:49:38 +0000 as excerpted:
>
>> When looking for orphan roots during mount we can end up hitting a
>> BUG_ON() (at root-item.c:btrfs_find_orphan_roots()) if a log tree is
>> replayed and qgroups are enabled.
>
> This should hit 4.6, right?  Will it hit 4.5 before release?
>
> Because I wasn't sure of current quota functionality status, but this bug
> obviously resets the counter on my ongoing "two kernel cycles with no
> known quota bugs before you try to use quotas" recommendation.

IMHO, btrfs quota is *functionally* stable.
Which means, its main function, quota accounting is stable, under almost 
all operation.

There will be some hidden corner like this one, which is not easy to 
spot during rework.
(Although it seems the regression is not caused by qgroup rework though)

>
> Meanwhile, what /is/ current quota feature status?  Other than this bug,
> is it now considered known bug free, or is more quota reworking and/or
> bug fixing known to be needed for 4.6 and beyond?

AFAIK, no planed rework for qgroup, and the most recent large qgroup 
modification is by Mark Fasheh, allowing btrfs subvolume remove to 
update qgroup accouting correctly, at Nov 2015.

>
> IOW, given that two release cycles no known bugs counter, are we
> realistically looking at that being 4.8, or are we now looking at 4.9 or
> beyond for reasonable quota stability?
>
Never heard the 2 release cycles principle, but seems to be not flex enough.
 From this point of view, every time Filipe(just an example, as he finds 
the most of bugs and corner case), some part or even the whole btrfs is 
not stable for 4 months.

Thanks,
Qu