On Tue, 6 Mar 2012, Allison Henderson wrote: > On 03/06/2012 11:37 AM, Allison Henderson wrote: > > On 03/06/2012 09:44 AM, Ted Ts'o wrote: > > > On Tue, Mar 06, 2012 at 08:11:37AM +0100, Lukas Czerner wrote: > > > > > > > > you're right my patches solves this problem (as I wrote in the commit > > > > description) just because we now use a different code paths, which do > > > > not have this problem. > > > > > > Ok, thanks. I'll look at them before the end of this week. > > > > > > Just to be clear, have the problematic code paths been removed in your > > > patches, or are they not just being used in the problem scenario? > > > Basically, is there any other time where we might need the additional > > > logic which Allison added? > > > > > > - Ted > > > > > > > Hi Ted, > > > > I think we will be ok with out this patch if we pick up Lukas's patches. > > Since the new implementation is seated inside ext4_ext_remove_space, > > Lukas can take advantage of the existing code there. > > > > In the current solution, we are seated inside map blocks, and then call > > ext4_ext_rm_leaf from there. The bug in the current solution was that we > > needed to free index blocks in the path to the extent we just removed, > > but ext4_ext_remove_space will do this as it walks over the tree. > > > > There are some things in the new implementation that Lukas and I are > > looking at, but once we get it straightened out, I think it will be ok > > to let this patch go. Thx! > > > > Allison Henderson > > > > forgot to reply to all. Resending to keep everyone posted :) > I second that. The previous codepaths are removed from map blocks, so this bug is not there anymore. Thanks! -Lukas -- 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
