Donald Pearson posted on Sat, 25 Jul 2015 08:27:03 -0500 as excerpted: [Duncan wrote...] >>>>> 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. [Big intervening thread snip...] > 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. Thanks for the confirmation! Good to have a recent and concrete report to point to, on the subject of btrfs and quotas, now. Now I can at least say something like "we do have at least one report (4.1 timeframe) of snapshot deletion scaling or lockup issues where quotas was implicated -- after deleting qgroups and disabling quotas, the problem disappeared." -- 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
