From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Anyone tried out btrbk yet?
Date: Sun, 26 Jul 2015 05:39:33 +0000 (UTC) [thread overview]
Message-ID: <pan$c3d84$44e79b82$a4995e51$e6fa6d40@cox.net> (raw)
In-Reply-To: CAC=t97Dp2DU0_4bC-ZQmUa9_J96yi6VLfEZ27Wu3LufOfcLwEg@mail.gmail.com
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
next prev parent reply other threads:[~2015-07-26 5:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-09 12:26 Anyone tried out btrbk yet? Martin Steigerwald
2015-07-09 17:12 ` Henri Valta
2015-07-09 17:17 ` Marc MERLIN
2015-07-10 1:35 ` Donald Pearson
2015-07-10 1:38 ` Donald Pearson
2015-07-10 4:02 ` Paul Harvey
2015-07-10 10:46 ` Axel Burri
2015-07-12 3:55 ` Marc MERLIN
2015-07-13 0:42 ` Marc MERLIN
2015-07-15 0:03 ` Paul Harvey
2015-07-15 3:14 ` Marc MERLIN
2015-07-15 8:00 ` Sander
2015-07-15 14:42 ` Donald Pearson
2015-07-15 18:02 ` Donald Pearson
2015-07-15 21:49 ` Marc MERLIN
2015-07-20 5:15 ` Donald Pearson
2015-07-20 8:28 ` Duncan
2015-07-20 13:33 ` Donald Pearson
2015-07-21 9:29 ` Duncan
2015-07-22 1:29 ` Donald Pearson
2015-07-25 13:27 ` Donald Pearson
2015-07-26 5:39 ` Duncan [this message]
2015-07-15 21:48 ` Marc MERLIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$c3d84$44e79b82$a4995e51$e6fa6d40@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.