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.dun...@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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
