From: Chris Mason <chris.mason@fusionio.com>
To: Josef Bacik <jbacik@fusionio.com>
Cc: Miao Xie <miaox@cn.fujitsu.com>,
Linux Btrfs <linux-btrfs@vger.kernel.org>,
David Sterba <dave@jikos.cz>
Subject: Re: [RFC PATCH] Btrfs: fix full backref problem when inserting shared block reference
Date: Thu, 9 Aug 2012 09:11:09 -0400 [thread overview]
Message-ID: <20120809131109.GE4185@shiny> (raw)
In-Reply-To: <20120809122319.GG2141@localhost.localdomain>
On Thu, Aug 09, 2012 at 06:23:19AM -0600, Josef Bacik wrote:
> On Wed, Aug 08, 2012 at 09:10:17PM -0600, Miao Xie wrote:
> > If we create several snapshots at the same time, the following BUG_ON() will be
> > triggered.
> >
> > kernel BUG at fs/btrfs/extent-tree.c:6047!
> >
> > Steps to reproduce:
> > # mkfs.btrfs <partition>
> > # mount <partition> <mnt>
> > # cd <mnt>
> > # for ((i=0;i<2400;i++)); do touch long_name_to_make_tree_more_deep$i; done
> > # for ((i=0; i<4; i++))
> > > do
> > > mkdir $i
> > > for ((j=0; j<200; j++))
> > > do
> > > btrfs sub snap . $i/$j
> > > done &
> > > done
> >
> > The reason is:
> > Before transaction commit, some operations changed the fs tree and new tree
> > blocks were allocated because of COW. We used the implicit non-shared back
> > reference for those newly allocated tree blocks because they were not shared by
> > two or more trees.
> >
> > And then we created the first snapshot for the fs tree, according to the back
> > reference rules, we also used implicit back refs for the child tree blocks of
> > the root node of the fs tree, now those child nodes/leaves were shared by two
> > trees.
> >
> > Then We didn't deal with the delayed references, and continued to change the fs
> > tree(created the second snapshot and inserted the dir item of the new snapshot
> > into the fs tree). According to the rules of the back reference, we added full
> > back refs for those tree blocks whose parents have be shared by two trees.
> > Now some newly allocated tree blocks had two types of the references.
> >
> > As we know, the delayed reference system handles these delayed references from
> > back to front, and the full delayed reference is inserted after the implicit
> > ones. So when we dealt with the back references of those newly allocated tree
> > blocks, the full references was dealt with at first. And if the first reference
> > is a shared back reference and the tree block that the reference points to is
> > newly allocated, It would be considered as a tree block which is shared by two
> > or more trees when it is allocated and should be a full back reference not a
> > implicit one, the flag of its reference also should be set to FULL_BACKREF.
> > But in fact, it was a non-shared tree block with a implicit reference at
> > beginning, so it was not compulsory to set the flags to FULL_BACKREF. So BUG_ON
> > was triggered.
> >
> > We have several methods to fix this bug:
> > 1. deal with delayed references after the snapshot is created and before we
> > change the source tree of the snapshot. This is the easiest and safest way.
> > 2. modify the sort method of the delayed reference tree, make the full delayed
> > references be inserted before the implicit ones. It is also very easy, but
> > I don't know if it will introduce some problems or not.
>
> Thanks for tracking this down, FWIW I like option 2 the most, it would be
> intereseting to see if it does actually introduce new issues. Thanks,
For this release, I like the current patch ;) Great job tracking it
down Miao.
-chris
next prev parent reply other threads:[~2012-08-09 13:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-09 3:10 [RFC PATCH] Btrfs: fix full backref problem when inserting shared block reference Miao Xie
2012-08-09 6:48 ` David Sterba
2012-08-09 7:21 ` David Sterba
2012-08-09 7:50 ` Miao Xie
2012-08-10 10:38 ` Miao Xie
2012-08-21 6:24 ` Miao Xie
2012-08-09 12:23 ` Josef Bacik
2012-08-09 13:11 ` Chris Mason [this message]
2012-08-09 13:12 ` Josef Bacik
2012-08-09 13:16 ` Chris Mason
2012-08-09 18:04 ` Chris Mason
2012-08-10 10:38 ` Miao Xie
2012-08-10 11:56 ` Chris Mason
2013-01-30 18:23 ` Alex Lyakas
2013-01-31 2:42 ` Miao Xie
2013-01-31 13:06 ` Alex Lyakas
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=20120809131109.GE4185@shiny \
--to=chris.mason@fusionio.com \
--cc=dave@jikos.cz \
--cc=jbacik@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=miaox@cn.fujitsu.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.