I noticed a WARN_ON going off when adding csums because we were going over
the amount of csum bytes that should have been allowed for an ordered
extent. This is a leftover from when we used to hold the csums privately
for direct io, but now we use the normal ordered sum stuff so we need to
make su
On Tue, Jan 22, 2013 at 03:45:35PM -0500, Josef Bacik wrote:
> I noticed a WARN_ON going off when adding csums because we were going over
> the amount of csum bytes that should have been allowed for an ordered
> extent. This is a leftover from when we used to hold the csums privately
> for direct
On Wed, Jan 23, 2013 at 12:01:08PM +0100, David Sterba wrote:
> Survived a few hours of Chris' test and I'm running the full xfstests
> again now.
After 4.5 hours of the same testsuite as before, this popped up in
syslog:
[53489.99] btrfs csum failed ino 63793 off 106496 csum 2411266714 priva
On Wed, Jan 23, 2013 at 08:21:07AM -0700, David Sterba wrote:
> On Wed, Jan 23, 2013 at 12:01:08PM +0100, David Sterba wrote:
> > Survived a few hours of Chris' test and I'm running the full xfstests
> > again now.
>
> After 4.5 hours of the same testsuite as before, this popped up in
> syslog:
>
On Wed, Jan 23, 2013 at 06:57:09PM -0500, Chris Mason wrote:
> Looks like Josef saw the same, so we have two different bugs (missing
> crcs vs incorrect crcs). Josef mentioned a much faster test for the
> incorrect crcs...Josef what was that test?
Yeah, 2 bugs, this patch fixed the incorrect csum
