public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: linux-btrfs@vger.kernel.org
Subject: New experimental btrfs branch ready for testing
Date: Mon, 1 Jun 2009 17:04:47 -0400	[thread overview]
Message-ID: <20090601210447.GC3890@think> (raw)

Hello everyone,

Yan Zheng has been doing some major surgery to the back references and
extent allocation code, tackling bottlenecks in the code that tracks
extents.  It scales better with many snapshots and performs better in
the common case of no snapshots at all.

THE NEW CODE IS A FORWARD ROLLING DISK FORMAT CHANGE.  This means it is
compatible with the current btrfs disk format, but once you mount a
filesystem with the new code, it WILL NO LONGER BE MOUNTABLE FROM OLD
KERNELS.  Old kernels spit out an error message when you try them on new
format filesystems.

This is a large change, and I'm hoping to have it stable in time for the
2.6.31 merge window.  I've been testing it for about a week now, and
haven't been able to cause major problems yet.  But, testing the
compatibility with old format filesystems is the hard part, and
everyone that pulls the new code should backup their data first.

I've setup git branches called newformat where you can pull the new code.

For the kernel (based on 2.6.30-rc7):

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat

For the progs:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git newformat

The main benefit of the new code is that backrefs on the extent
allocation tree use a fuzzier format.  It basically means that we search
for the key in the extent allocation tree instead of providing an exact
backref to the parent block.

This means we can predict how many blocks will be changed when changing
the extent allocation tree, and it makes enospc much less complex.  It
is also significantly faster.

For regular subvolume trees, a similar change is made as long as there
are no snapshots against a given block.  This is the common case, and it
makes COW less expensive overall.

Yan Zheng also worked out a way to free blocks during the transaction
without needing to do an explicit snapshot deletion on the old root when
the transaction was done.  This gets rid of some complex caching code,
and fixes worst-case problems where btrfs could take a very very long
time to unmount.

btrfs-vol -b is faster with the new code as well, he added caching of
high levels in the tree to speed things up.

(Many kudos to Yan Zheng for all of this work!)

-chris


             reply	other threads:[~2009-06-01 21:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-01 21:04 Chris Mason [this message]
2009-06-02 13:28 ` New experimental btrfs branch ready for testing Chris Mason
2009-06-03 17:08   ` Chris Mason
2009-06-04 19:02 ` Steven Pratt
2009-06-04 19:05   ` Chris Mason
2009-06-05 14:20   ` Chris Mason
2009-06-05 16:02     ` Steven Pratt
2009-06-05 21:27       ` Steven Pratt
2009-06-06  0:20         ` Chris Mason
2009-06-06 16:38           ` Steven Pratt
2009-06-09 15:26             ` Chris Mason
2009-06-15 15:46               ` Steven Pratt
2009-06-07 11:50 ` Roy Sigurd Karlsbakk
2009-06-07 12:13   ` Daniel Cordero
2009-06-08 12:33 ` Yan Zheng

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=20090601210447.GC3890@think \
    --to=chris.mason@oracle.com \
    --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