On Wed, Aug 19, 2009 at 05:34:08PM +0800, Yan, Zheng wrote: > 2009/8/19 Nick Piggin <npiggin@xxxxxxx>: > > On Wed, Aug 19, 2009 at 04:56:12PM +0800, Yan, Zheng wrote: > > Firstly, the insert/delete code is wrong for duplicates and it will crash in > > the absense of any search activity. Agree? > > Secondly, OK now if we did allow duplicates in the tree as-per my last > > patch to Jens, then look what happens with igrab: it will correctly > > prevent us from getting a freeing inode, but then it will set the next > > inode to search at ino+1 -- ie. it will not correctly traverse duplicates > > without modifications. Agree? > > So with that in mind -- the fact that you don't want to see freeing > > inodes in your search code, then there is no point to handle duplicates > > at all; simply remove freeing inodes from the tree. > > > > I agree all of this. Thing confuses me is you saw crashes in > inode_tree_del. It's unlikely you were playing btrfsctl -b when you > encountered the problem. So no search code got involved, only > inode_tree_add/del modified the tree. I don't think the crash was > caused by duplicates in the tree. Oh, it is because inodes get reclaimed then presumably the inode number gets reused while an inode of the same number is being freed. I'm not exactly sure how the inode and inode number lifetimes work in btrfs... Duplicate inodes are definitely being added because I put a message in there and it is being triggered. What happens is that the duplicate insertion code is wrong, and it kicks the old inode out of the tree with the inode still marked as being in the tree. So when you try to delete that inode, it crashes. I'm not quite sure how to explain it any better. It is pretty easy to reproduce (it is the same workload as I describe in fsx-linux failures mail) if you would like to verify what is happening. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
