Excerpts from Chris Mason's message of 2011-06-13 09:12:06 -0400:
> Excerpts from Li Zefan's message of 2011-06-13 03:13:13 -0400:
> > Cc: Josef
> > 
> > >>>>>>>> I encountered following panic using 'btrfs-unstable + for-linus'
> > >>>>>>>> kernel.
> > >>>>>>>>
> > >>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
> > >>>>>>>> is as follows:
> > >>>>>>>>
> > >>>>>>>>  /dev/sdc3 on /test5 type btrfs 
> > >>>>>>>> (rw,space_cache,compress=lzo,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.  The balancing code is
> > >> finding the inode map cache extents, but it doesn't know how to relocate
> > >> 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_inode 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 the 
> > trans_mutex.
> 
> Ok, what dataset are you balancing?
> 
> What are you doing concurrently with the balance?
> 
> I haven't been able to trigger this here.

There we go.  It took about two hours but I hit this with the balancing
exerciser that was posted.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to