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: abysmal rm performance?
Date: Sat, 20 Jul 2013 12:54:50 +0000 (UTC)	[thread overview]
Message-ID: <pan$ced03$25979b41$99925d6e$d5a92251@cox.net> (raw)
In-Reply-To: 20130720133726.7c2e1314@wpkg.org

Tomasz Chmielewski posted on Sat, 20 Jul 2013 13:37:26 +0800 as excerpted:

> So it looks like removing files with btrfs [as opposed to ext4] needs
> much more metadata updates?

You /really/ need to read up on the btrfs wiki.

The short answer is yes, btrfs does a LOT more metadata processing due to 
the checksumming it does by default.  (Consider that it must have all the 
metadata from a leaf available in ordered to rechecksum it when one 
file's metadata from that leaf gets deleted.)  Additionally, btrfs keeps 
two copies of metadata by default, in raid1 mode if there's multiple 
devices (btrfs raid1), DUP mode if not (other forms of raid, which would 
appear to btrfs as a single device).

Then there's the whole problem that you didn't provide nearly enough 
information about your test to tell what it was actually comparing.  What 
sort of raid1, btrfs/md/dm/hardware/what, and if btrfs raid1, was that 
for both data and metadata or just one of the two and what was the other 
one if they weren't both raid1?  And if you were testing btrfs raid1, 
what did you do with the ext4 test to try to make it comparable since 
ext4 doesn't have a native raid1 mode, or was it on a single device?

So... read up on the wiki a bit, then come back with questions you have 
that aren't answered there.  (I certainly had some I didn't see directly 
answered there when I first started with btrfs.)

https://btrfs.wiki.kernel.org/

-- 
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:[~2013-07-20 12:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-20  5:37 abysmal rm performance? Tomasz Chmielewski
2013-07-20 12:54 ` Duncan [this message]
2013-07-20 13:36   ` Clemens Eisserer
  -- strict thread matches above, loose matches on Subject: below --
2013-07-22  5:22 Tomasz Chmielewski
2013-07-22 10:39 ` Duncan

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$ced03$25979b41$99925d6e$d5a92251@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).