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: Re: New experimental btrfs branch ready for testing
Date: Wed, 3 Jun 2009 13:08:36 -0400	[thread overview]
Message-ID: <20090603170836.GE13945@think> (raw)
In-Reply-To: <20090602132830.GA3914@think>

On Tue, Jun 02, 2009 at 09:28:30AM -0400, Chris Mason wrote:
> On Mon, Jun 01, 2009 at 05:04:47PM -0400, Chris Mason wrote:
> > 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.
> 
> Just a quick note that I'm having some issues with the backward
> compatibility code on 32 bit kernels.  It can still read all the old
> items but it is having problems with creating new backrefs.
> 
> 32bit is working fine on an entirely new format FS, and my 64 bit box
> can read and write the old format FS just fine.  I'm hoping to track
> this one down today, but it would be a good idea to wait if you want to
> try the new code on old filesystems on 32 bit machines.
> 
> If you do hit crashes, please don't immediately reformat your FS if you
> can avoid it.  We should be able to fix most problems people hit.

Looks like Yan Zheng tracked this down yesterday, Jens Axboe bravely
tested out 32bit old format compat again with his laptop.  At this point
I think the new format code is looking pretty stable and it is generally
ready for more testing.

I've rebased the newformat kernel tree to fold in the corruption fixes.
This way if anyone does a git bisect they won't end up on a commit that
can corrupt their FS by accident.  If you've already pulled the
newformat tree, the new commits will conflict with the old.

So, something like this will fix things if you have already pulled the
newformat branch:

git reset --hard v2.6.30-rc7
git pull git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat

If you've made your own commits or pulls other than just btrfs,
different steps will be required.

The btrfs-progs unstable tree was also rebased.

Use git reset --hard ed20f5fc905145a0673097b539442d2a59491e77 on the
progs tree if you've already pulled down the newformat branch.

Happy testing everyone

-chris


  reply	other threads:[~2009-06-03 17:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-01 21:04 New experimental btrfs branch ready for testing Chris Mason
2009-06-02 13:28 ` Chris Mason
2009-06-03 17:08   ` Chris Mason [this message]
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=20090603170836.GE13945@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