Theodore Tso wrote:
On Thu, Oct 29, 2009 at 04:38:57PM -0500, Eric Sandeen wrote:
I've been running my testcase, and I just hit the usual corruption with
this patch in place after 8 iterations, I'm afraid.
Eric, since you have a relatively controllable reproduction case, have
you tried reproducing Alexey's bisection results? Specifically he
seemed to find that commit fe188c0e shows no problem, and commit
91ac6f43 is the first commit with problems?
I can try it but I have very little faith in that result to be honest.
Having to do multiple iterations will make doing a bisection a major
pain, but maybe we'll get something out of that.
Well I've been doing bisects but I'm getting skeptical of the results;
either my testcase isn't reliable enough or all the merges are confusing
git-bisect (?) Anyway it keeps ending up on nonsensical commits.
Other things that might be worth doing given that you have a test case
would be to try reverting commit 91ac6f43, and see if that helps, and
to try this patch: http://bugzilla.kernel.org/attachment.cgi?id=23468
Or have you tried some of these experiments already?
Regards,
- Ted
After talking to Aneesh last night, I think other good spot-checks will
be to revert 487caeef9fc08c0565e082c40a8aaf58dad92bbb, and to test Jan's
sync patches.
-Eric
--
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
