Re: Anyone tried out btrbk yet?

[Donald Pearson <donaldwhpearson@gmail.com>]

Thanks for the feedback Duncan.

It doesn't appear to be a big deal to disable quotas so that's what
I'll do for now.

On Tue, Jul 21, 2015 at 4:29 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html