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
