I found another bug. There are codes (btrfs_save_ino_cache) that modify fs trees after create_pending_snapshots is called. This can corrupt your fs.
On Mon, Jun 13, 2011 at 3:13 PM, Li Zefan <l...@cn.fujitsu.com> wrote: > 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. > > -- > 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 > -- 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
