From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Very slow balance / btrfs-transaction
Date: Sat, 4 Feb 2017 08:22:17 +0000 (UTC) [thread overview]
Message-ID: <pan$dd6b9$f272402c$c0b70b44$e64ed91e@cox.net> (raw)
In-Reply-To: CAKuJGC-3pmzOWmaUZx-xav9W1zp+m=1PLhunKDm2Cw80c+6-Fg@mail.gmail.com
Lakshmipathi.G posted on Sat, 04 Feb 2017 08:25:04 +0530 as excerpted:
>>Should quota support generally be disabled during balances?
>
> If this true and quota impacts balance throughput, at-least there should
> an alert message like "Running Balance with quota will affect
> performance" or similar before starting.
The problem isn't that, exactly, tho that's part of it. The problem with
quotas is that the feature itself isn't yet mature. At least until very
recently, and possibly still, quotas couldn't be depended upon to work
correctly (various not entirely uncommon corner-cases would trigger
negative numbers, etc), and even when they do work correctly, they simply
don't scale well in combination with balance, check, etc -- that 10X
difference isn't uncommon.
So my recommendation for quotas has been and remains, unless you're
actively working with the devs on improving them, it's probably better to
keep them disabled. Either you actually need quota functionality or you
don't. If you do, it's better to use a mature filesystem where quotas
are a mature feature that works dependably. If you don't, just leave the
feature off, as it continues to simply not be worth the troubles and
scaling issues it triggers.
IOW, btrfs quotas might work and scale well some day, but that day isn't
today, and it's not going to be tomorrow or next kernel cycle, either.
It's going to take awhile, and you'll be much happier with btrfs in the
mean time if you don't have them enabled.
--
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:[~2017-02-04 8:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-03 22:13 Very slow balance / btrfs-transaction jb
2017-02-03 23:25 ` Goldwyn Rodrigues
2017-02-04 0:30 ` Jorg Bornschein
2017-02-04 1:07 ` Goldwyn Rodrigues
2017-02-04 1:47 ` Jorg Bornschein
2017-02-04 2:55 ` Lakshmipathi.G
2017-02-04 8:22 ` Duncan [this message]
2017-02-06 1:45 ` Qu Wenruo
2017-02-06 16:09 ` Goldwyn Rodrigues
2017-02-07 0:22 ` Qu Wenruo
2017-02-07 15:55 ` Filipe Manana
2017-02-08 0:39 ` Qu Wenruo
2017-02-08 13:56 ` Filipe Manana
2017-02-09 1:13 ` Qu Wenruo
2017-02-06 9:14 ` Jorg Bornschein
2017-02-06 9:29 ` Qu Wenruo
2017-02-04 20:50 ` Jorg Bornschein
2017-02-04 21:10 ` Kai Krakow
2017-02-06 13:19 ` Austin S. Hemmelgarn
2017-02-07 19:47 ` Kai Krakow
2017-02-07 19:58 ` Austin S. Hemmelgarn
-- strict thread matches above, loose matches on Subject: below --
2017-07-01 14:24 Sidney San Martín
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$dd6b9$f272402c$c0b70b44$e64ed91e@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).