On Wed, Feb 13, 2013 at 11:26:40AM +0400, Dmitry Monakhov wrote: > This helps us to spot several hidden issues (number is still unknown) > so may be it is reasonable to split first patch in two parts: > 1) disable uninitialized extents merging itself. > 2) Print warning if split is required inside end_io(so only warning will > be printed, but w/o data corruption) > 3) Get rid of extent split machinery from end_io (because it is not > longer valid situation) > > (1) and (2) should be accepted ASAP and will help us to spot and fix > other hidden issues. And we fix all related issues it will be safe > to apply (3)'rd one. > I'll send patches soon. That seems like reasonable approach; I'm not sure we'll be able to get to (3) by the time the merge window opens, but getting (1) and (2) in would be great; if the warning is getting triggered a lot, we might need to only enable it under CONFIG_EXT4_DEBUG, though. If you could you base the patches off of tip of the dev branch (which I just updated), I'd really appreciate it. The last commit on the newly updated dev branch is: 7eedefe ext4: support simple conversion of extent-mapped inodes to use i_blocks In this updated dev branch, I've moved the extent status patches to the unstable portion of the tree due to the bigalloc regressions. So the plan for the merge window is that currently, the extent status patches and the uninitialized extent merging patches are currently on the unstable portion of the tree here: http://repo.or.cz/w/ext4-patch-queue.git git://repo.or.cz/ext4-patch-queue.git That way we can do intensive testing on the rest of the ext4 tree. Once the rest of the patches have been validated, I'll push the master branch on the ext4 git tree to point at the fully validated set of patches, and then we can try to push the rest of the patches that have been moved past the stable-boundary in the ext4 patch queue back onto the dev branch, and see if we can shake out the rest of the problems before the merge window opens. I will be leaving for Hawaii tomorrow, so the amount of time I will have to do a development/debugging work will be limited. On the other hand, it's easy to let regression tests run in the hotel room while I'm visiting volcano craters, so please do send me updated patches, and I'll review and test them as I have time. The joys of having the pre-merge window crunch coincide with your vacation... :-) - Ted -- 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
