linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Rebalance makes BTRFS 10x slower
Date: Sun, 13 Apr 2014 20:46:32 +0000 (UTC)	[thread overview]
Message-ID: <pan$78e51$a2348240$c61eed49$b68b7430@cox.net> (raw)
In-Reply-To: CAFvQSYT=1z4iENu8xLnBLvVTqUzYfZazY1acnFvUEz_FO-Gf4w@mail.gmail.com

Clemens Eisserer posted on Sun, 13 Apr 2014 10:16:22 -0400 as excerpted:

>> I also found this to be the case as I rebalanced the root filesystem of
>> my Debian installation on this ThinkPad T520 on an Intel SSD 320.
> 
> Same here, I ran balance on kernel-3.12 some time ago and after
> balancing performance dropped noticeable and stayed there.
> When booting natively I can see the HDD activity led lid for 10+ seconds
> (Samsung 830 SSD), working with the same system in virtualbox using
> direct device access is a real pain.
> 
> Non of the measures I took (re-balance, fstrim, defraging all files on
> the volume, ...) had mentionable impact.

This one is a real mystery to me, and only recently came up on my radar 
as an issue people are seeing.  It'd be interesting to get to the bottom 
of it as it's possible it has other bug and correctness implications as 
well.

I've seen nothing like it here, but then my btrfs are all relatively 
small (under 50 gig each), and I don't tend to do much snapshotting or 
subvolumes, which might make a difference.  Additionally, I don't have a 
lot of large "internal write" files such as databases and the like (not 
even the systemd journal file issue that some have reported, as while I 
recently switched to systemd, I deliberately chose to configure it to do 
tmpfs logs only to avoid that problem entirely, with all longer term 
logging going thru syslog-ng, which has more conventional append-only log 
files).

But as I said, I'd sure like to get to the bottom of this one, since I do 
believe it has other potential implications in terms of bugs, etc.  In 
theory, a balance should either not affect performance or should improve 
it, so getting to the bottom of why it's having such a bad performance 
impact for many really is something that needs to be done.


-- 
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-13 20:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-23 14:51 Rebalance makes BTRFS 10x slower Swâmi Petaramesh
2014-03-23 15:12 ` Martin Steigerwald
2014-04-13 14:16   ` Clemens Eisserer
2014-04-13 20:46     ` Duncan [this message]
2014-04-16 15:00       ` Clemens Eisserer

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$78e51$a2348240$c61eed49$b68b7430@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).