From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:54113 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751353AbbGZFjq (ORCPT ); Sun, 26 Jul 2015 01:39:46 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZJEew-0001G6-ML for linux-btrfs@vger.kernel.org; Sun, 26 Jul 2015 07:39:38 +0200 Received: from ip98-167-165-199.ph.ph.cox.net ([98.167.165.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Jul 2015 07:39:38 +0200 Received: from 1i5t5.duncan by ip98-167-165-199.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Jul 2015 07:39:38 +0200 To: linux-btrfs@vger.kernel.org From: Duncan <1i5t5.duncan@cox.net> Subject: Re: Anyone tried out btrbk yet? Date: Sun, 26 Jul 2015 05:39:33 +0000 (UTC) Message-ID: References: <11148188.L9vtSMaNHV@merkaba> <559FA280.8090309@tty0.ch> <20150712035523.GI5274@merlins.org> <20150713004249.GP5274@merlins.org> <20150715031412.GZ5274@merlins.org> <20150715080057.GA15200@panda> <20150715214913.GG5274@merlins.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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