All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Do quota groups cost noticeable performance in 3.14?
Date: Mon, 21 Apr 2014 05:44:54 +0000 (UTC)	[thread overview]
Message-ID: <pan$a2f12$b2daf6bc$70ff71c$1a6edc97@cox.net> (raw)
In-Reply-To: 20140420195901.GP7884@merlins.org

Marc MERLIN posted on Sun, 20 Apr 2014 12:59:01 -0700 as excerpted:

> I was looking at using qgroups for my backup server, which will be
> filled with millions of files in subvolumes with snapshots.
> 
> I read a warning that quota groups had performance issues, at least in
> the past.

Yes.  Additionally, there were serious bugs such that after subvolume 
deletes people would end up with negative quota usage!  Luckily I didn't 
need that for my use-case, but the recommendation for a couple kernels 
was definitely to avoid it for the time being, unless you were simply 
playing with it.  There were/are other filesystems with more mature quota 
solutions that actually work, if you're going to depend on it actually 
working.

> Is it still true?

Very good question.  Certainly both the qgroups bug reports and the 
patches have slowed down for 3.13/3.14 so it's gotta be better than it 
was, and while I don't use that feature and thus haven't been tracking it 
directly, I believe current status should be about where generic btrfs is 
at this point, that is, reasonably stable, but keep your backups tested 
and ready, just in case.

> If there is a performance issue, is it as simple as just turning off
> quota support and then things go back to normal?

IIRC yes, even back when the bugs were coming in right and left, that was 
basically the case -- WITH THE CAVEAT that back then anyway, a reboot was 
sometimes needed as the counts just weren't being updated correctly and 
people were getting some very weird results on deletion/disabling until 
reboot, sometimes.


Meanwhile, looking forward to your testing/reports/wiki-updates!  If you 
can do for qgroups what you've been doing for raid5/6 mode I'm sure a lot 
of folks (including me, I might not use it presently, but the better I 
understand it, the more effectively I can help others with questions) 
will be much edified. =:^)

-- 
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


  reply	other threads:[~2014-04-21  5:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-20 19:59 Do quota groups cost noticeable performance in 3.14? Marc MERLIN
2014-04-21  5:44 ` Duncan [this message]
2014-04-21 22:45   ` Duncan
2014-04-21 23:01     ` 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$a2f12$b2daf6bc$70ff71c$1a6edc97@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.