I can confirm that getting rid of the quotas fixed the issue for me. Just disabling quotas wasn't enough, I had to enable, delete all qgroups, reboot because disable was hung on one of the filesystems, then disable quotas. Now when btrfs-cleaner runs it doesn't completely consume a core, I can see corresponding disk i/o, and the process goes away after a reasonable amount of time.
On Tue, Jul 21, 2015 at 8:29 PM, Donald Pearson <donaldwhpear...@gmail.com> wrote: > 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
