I've been thinking about this some more, and if you don't have a lot of time, perhaps the most important test to do is this. Does the chance of your seeing corrupted files in v3.6.3 go down if you run 3.6.3 with commit 14b4ed22a6 reverted? Keep your current configuration, using nobarrier, et. al, constant. If reverting the commit makes things better, then that's what would be most useful to know as soon as possible, since the correct short-term solution is to revert that commit for 3.7-rcX, as well as the 3.6 and 3.5 stable kernels. We can investigate later whether nobarrier, journal_async_commit seem to make the problem worse, and whether the less common corruption case that you were seeing with 3.6.1 was actually a change which was introduced between 3.3 and 3.4. But most importantly, even if the bug doesn't show up with the default mount options at all (which explains why Eric and I weren't able to reproduce it), there are probably other users using nobarrier, so if the frequency with which you were seeing corruptions went up significantly between 3.6.1 and 3.6.3, and reverting 14b4ed22a6 brings the frequency back down to what you were seeing with 3.6.1, we should do that ASAP. Regards, - 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
