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
--
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
