From: Chris Mason <chris.mason@oracle.com>
To: "Yan, Zheng" <yanzheng@21cn.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
Tsutomu Itoh <t-itoh@jp.fujitsu.com>,
liubo <liubo2009@cn.fujitsu.com>,
Linux Btrfs <linux-btrfs@vger.kernel.org>,
Josef Bacik <josef@redhat.com>
Subject: Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
Date: Mon, 13 Jun 2011 11:09:48 -0400 [thread overview]
Message-ID: <1307977739-sup-6108@shiny> (raw)
In-Reply-To: <BANLkTi=m2CkcSQNPNja=A7eG62vLstM1sw@mail.gmail.com>
Excerpts from Yan, Zheng's message of 2011-06-13 10:58:35 -0400:
> The usage of trans_mutex in relocation code is subtle. It controls
> interaction of relocation
> with transaction start, transaction commit and snapshot creation.
> Simple replacing
> trans_mutex with trans_lock is wrong.
What requirements of the relocation stuff are we currently missing? I'=
d
rather add extra waiting for relocation than go back to the mutex.
-chris
>=20
> On Mon, Jun 13, 2011 at 3:13 PM, Li Zefan <lizf@cn.fujitsu.com> wrote=
:
> > Cc: Josef
> >
> >>>>>>>>> I encountered following panic using 'btrfs-unstable + for-l=
inus'
> >>>>>>>>> kernel.
> >>>>>>>>>
> >>>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /t=
est5
> >>>>>>>>> is as follows:
> >>>>>>>>>
> >>>>>>>>> =C2=A0/dev/sdc3 on /test5 type btrfs (rw,space_cache,compre=
ss=3Dlzo,inode_cache)
> >>>>>>>>>
> >>>>>>>> So, just a "btrfs fi bal" would lead to the bug?
> >>>>>>> I think so.
> >>>
> >>> It should be specific to the inode caching code. =C2=A0The balanc=
ing code is
> >>> finding the inode map cache extents, but it doesn't know how to r=
elocate
> >>> them.
> >>
> >> However, the panic has occurred even if inode_cahce is turned off.
> >> Is this another problem?
> >>
> >
> > I don't think free inode cache isthe cause of the bug here (even if=
inode_cache
> > is turned on).
> >
> > What I have found out is:
> >
> > 1. git checkout a4abeea41adfa3c143c289045f4625dfaeba2212
> >
> > So the top commit is the removal of trans_mutex and no delayed_inod=
e patch
> > or free inode cache patchset in the tree, and bug can be triggered.
> >
> > 2. git checkout 2a1eb4614d984d5cd4c928784e9afcf5c07f93be
> >
> > So the top commit is the one before trans_mutex removal, and no bug=
triggered.
> >
> > 3. test linus' tree
> >
> > bug triggered.
> >
> > 4. revert that suspicoius commit manually from linus' tree
> >
> > no bug.
> >
> > so either that commit is buggy or it reveals some bugs covered by t=
he trans_mutex.
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btr=
fs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.=
html
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-06-13 15:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 8:33 kernel BUG at fs/btrfs/extent-tree.c:6164! Tsutomu Itoh
2011-06-07 5:31 ` liubo
2011-06-07 5:59 ` Tsutomu Itoh
2011-06-07 6:17 ` Tsutomu Itoh
2011-06-07 8:24 ` Tsutomu Itoh
2011-06-07 8:36 ` liubo
2011-06-07 15:46 ` Chris Mason
2011-06-08 5:12 ` Tsutomu Itoh
2011-06-13 7:13 ` bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!) Li Zefan
2011-06-13 7:49 ` Yan, Zheng
2011-06-13 8:26 ` Li Zefan
2011-06-13 13:12 ` Chris Mason
2011-06-13 15:18 ` Chris Mason
2011-06-13 14:58 ` Yan, Zheng
2011-06-13 15:09 ` Chris Mason [this message]
2011-06-13 19:55 ` Chris Mason
2011-06-14 3:24 ` Yan, Zheng
2011-06-14 5:44 ` Li Zefan
2011-06-14 6:53 ` 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=1307977739-sup-6108@shiny \
--to=chris.mason@oracle.com \
--cc=josef@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=liubo2009@cn.fujitsu.com \
--cc=lizf@cn.fujitsu.com \
--cc=t-itoh@jp.fujitsu.com \
--cc=yanzheng@21cn.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.