Re: Anyone tried out btrbk yet?

[Duncan <1i5t5.duncan@cox.net>]

Donald Pearson posted on Mon, 20 Jul 2015 08:33:47 -0500 as excerpted:

>> Also, FWIW, the btrfs quota subsystem increases snapshot management
>> complexity dramatically, so if you're using that, aim for the low ends
>> of the above recommendation if at all possible, and/or consider either
>> turning off the quota stuff or using a filesystem other than btrfs, as
>> in addition to the scaling issues, the quota management code has been a
>> source of repeated bugs and isn't a feature I'd recommend relying on
>> until it has at least several kernel cycles worth of trouble-free
>> history behind it.
> 
> Thanks for the insight.  I just took a look at dmesg and found this.
> Is this coincidental or is this maybe the reason things appear to be
> stuck?  I'm not sure how to read this.
> 
> [195400.023165] ------------[ cut here ]------------
> [195400.023199] WARNING: CPU: 2 PID: 16987 at fs/btrfs/qgroup.c:1028
> __qgroup_excl_accounting+0x1dc/0x270 [btrfs]()

I don't know.  I'm not a btrfs quota feature user.

What I do know is that there has been... again... more quota code patches 
recently, fixing what sound like serious problems.

You already have my recommendation above; unless you are actively testing 
the btrfs quota code, if you don't need it, don't use it; if you do need 
it, use something where it's actually working well enough to /rely/ on.

But in fairness that's potentially a negatively biased view, since as I'm 
on the list but not actually using that feature I'm seeing the bug 
reports without much in the way of knowing how common they actually are.  
If it's a big deal to turn quotas off, I'd say wait and see if the dev 
actually working on it cares to comment with his opinion of quota feature 
stability in general, and perhaps of that specific trace, before deciding 
for sure.

But if you have the inclination and don't really need quotas, and 
assuming disabling them isn't /too/ big a hassle, it might be worthwhile 
disabling the feature and seeing how things go.  I can't see how not 
having to deal with quotas could /hurt/ scaling, and with luck, it'll 
improve things noticeably.

FWIW, the developer post where the effect of quotas on scaling was 
explained was actually in the context of snapshot-aware-defrag, which has 
been disabled for awhile now, /because/ of the scaling issues (it was so 
bad the defrag would basically hang, taking hours to defrag a single 
moderately sized file as it tracked it thru the various snapshots, so 
processing time for a full filesystem could easily be weeks and could in 
some cases be months, obviously well outside any practically workable 
range!), and while quota processing was explained to be horrible in that 
context at that time (I read it as at least doubling the necessary work), 
there has been at least one quota-code rewrite since then, as well as 
additional work, and it may actually not be nearly as bad any more, 
barring a direct bug, of course.  But I don't know as I've not seen any 
direct statements or numbers either way, only the bug reports and patches 
going by.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman