[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101210023852.GB3059@thunk.org>
Date: Thu, 9 Dec 2010 21:38:52 -0500
From: Ted Ts'o <tytso@....edu>
To: Matt <jackdachef@...il.com>
Cc: Chris Mason <chris.mason@...cle.com>,
Andi Kleen <andi@...stfloor.org>,
Jon Nelson <jnelson@...poni.net>,
Mike Snitzer <snitzer@...hat.com>,
Milan Broz <mbroz@...hat.com>,
linux-btrfs <linux-btrfs@...r.kernel.org>,
dm-devel <dm-devel@...hat.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
htd <htd@...cy-poultry.org>, htejun <htejun@...il.com>,
linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt
barrier support is effective)
On Fri, Dec 10, 2010 at 02:53:30AM +0100, Matt wrote:
>
> Try a kernel before 5a87b7a5da250c9be6d757758425dfeaf8ed3179
>
> from the tests I've done that one showed the least or no corruption if
> you count the empty /etc/env.d/03opengl as an artefact
Yes, that's a good test. Also try commit bd2d0210cf. The patch
series that is most likely to be at fault if there is a regression in
between 5a87b7a5d and bd2d0210cf inclusive.
I did a lot of testing before submitting it, but that wa a tricky
rewrite. If you can reproduce the problem reliably, it might be good
to try commit 16828088f9 (the commit before 5a87b7a5d) and commit
bd2d0210cf. If it reliably reproduces on bd2d0210cf, but is clean on
16828088f9, then it's my ext4 block i/o submission patches, and we'll
need to either figure out what's going on or back out that set of
changes.
If that's the case, a bisect of those changes (it's only 6 commits, so
it shouldn't take long) would be most appreciated.
Regards,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists