linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Calvin Walton <calvin.walton@kepstin.ca>
To: "Brian J. Murrell" <brian@interlinx.bc.ca>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: efficiency of btrfs cow
Date: Sun, 06 Mar 2011 11:06:22 -0500	[thread overview]
Message-ID: <1299427596.15017.8.camel@ayu> (raw)
In-Reply-To: <il0a8d$4ev$1@dough.gmane.org>

On Sun, 2011-03-06 at 10:46 -0500, Brian J. Murrell wrote:
> I have a backup volume on an ext4 filesystem that is using rsync and
> it's --link-dest option to create "hard-linked incremental" backups.  I
> am sure everyone here is familiar with the technique but in case anyone
> isn't basically it's effectively doing (each backup):

> So I replicated a few of the directories in my backup volume to a btrfs
> volume using snapshots for each backup to take advantage of CoW and with
> any luck, avoid entire file duplication where only some subset of the
> file has changed.
> 
> Overall, it seems that I saw success.  Most backups on btrfs were
> smaller than their source, and overall, for all of the backups
> replicated, the use was less.  There were some however that were
> significantly larger.  Here's the analysis:

> Taking the biggest anomaly, monthly.15, a du of just that directory on
> both the btrfs and ext4 filesystems shows results I would expect:
> 
> btrfs: 136,876,580 monthly.15
> ext4:  142,153,928 monthly.15
> 
> Yet the before and after "df" results show the btrfs usage higher than
> ext4.  Is there some "periodic" jump in "overhead" used by btrfs that
> would account for this mysterious increased usage in some of the copies?

There actually is such a periodic jump in overhead, caused by the way
which btrfs dynamically allocates space for metadata as needed by the
creation of new files, which it does whenever the free metadata space
ratio reaches a threshold (it's probably more complicated than that, but
close enough for now).

To see exactly what's going on, you should use the "btrfs filesystem df"
command to see how space is being allocated for data and metadata
separately:

ayu ~ # btrfs fi df /
Data: total=266.01GB, used=249.35GB
System, DUP: total=8.00MB, used=36.00KB
Metadata, DUP: total=3.62GB, used=1.93GB
ayu ~ # df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda4             402G  254G  145G  64% /

If you use the btrfs tool's df command to account for space in your
testing, you should get much more accurate results.

-- 
Calvin Walton <calvin.walton@kepstin.ca>


  parent reply	other threads:[~2011-03-06 16:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-06 15:46 efficiency of btrfs cow Brian J. Murrell
2011-03-06 16:02 ` Fajar A. Nugraha
2011-03-06 16:11   ` Brian J. Murrell
2011-03-06 16:17   ` Calvin Walton
2011-03-06 16:18     ` Brian J. Murrell
2011-03-06 17:22   ` Freddie Cash
2011-03-06 16:06 ` Calvin Walton [this message]
2011-03-06 16:17   ` Brian J. Murrell
2011-03-23 12:39   ` Brian J. Murrell
2011-03-23 15:53     ` Chester
2011-03-23 16:19       ` Brian J. Murrell
2011-03-23 17:36     ` Kolja Dummann

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=1299427596.15017.8.camel@ayu \
    --to=calvin.walton@kepstin.ca \
    --cc=brian@interlinx.bc.ca \
    --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).