http://bugzilla.kernel.org/show_bug.cgi?id=13232 --- Comment #8 from Jan Kara <jack@xxxxxxx> 2009-05-18 12:45:23 --- On Wed 13-05-09 12:07:24, Theodore Tso wrote: > On Wed, May 13, 2009 at 03:48:02PM +0200, Jan Kara wrote: > > OK, the deadlock has been introduced by ext3 variant of > > 261bca86ed4f7f391d1938167624e78da61dcc6b (adding Al to CC). > > What do you mean by this? > > I'm puzzled why we haven't hit this before. This looks like > long-standing issue; what unmasked it now? Unless you mount the fs with 'sync' option, hitting this is much harder (the window is quite small in nosync case). I think that is the main reason why we didn't see this earlier. > > The deadlock > > is really tough to avoid - we have to first allocate inode on disk so > > that we know the inode number. > > Well, the simple thing to do is to have a way of quickly determining > that a particular inode number is in the I_FREEING state, and simply > try to avoid using that inode number. If there are no inodes > available, it can simply close the handle (since nothing else has > changed at that point), wait for the current transaction to close, and > then try again. That should fix the problem, I think. Yes, we could work-around it like that but other filesystems might need similar things and generally it would be nicer if we could avoid using this vfs-internal information in the filesystems. Al seems to have found some other solution without changing filesystems so that would be easier for us... Honza -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
