From: Eric Whitney <enwlinux@gmail.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Eric Whitney <enwlinux@gmail.com>, linux-ext4@vger.kernel.org
Subject: Re: xfstests failures w/ metadata_csum
Date: Mon, 1 Dec 2014 17:05:34 -0500 [thread overview]
Message-ID: <20141201220534.GA4619@wallace> (raw)
In-Reply-To: <20141201202045.GR10043@birch.djwong.org>
* Darrick J. Wong <darrick.wong@oracle.com>:
> Hi Eric,
>
> Could you remind me which xfstests are failing in 3.18-rc3+ with metadata_csum
> enabled? I think you said generic/034, generic/321, and generic/322, but were
> there more?
Hi Darrick:
The other failing test is generic/325 - you've got the others right. Note that
I may be an xfstests version ahead of xfstests-bld, so depending on what you're
running, you may not see all of those. (Gonna stick closer to xfstests-bld
from now on.) The failures are the same in the inline data test scenario.
Thanks for looking at this!
Eric
>
> AFAICT the ext4 mount fails because it can't load the journal, and the journal
> can't replay because jbd2_descr_block_csum_verify() fails; the 034 test appears
> to drop all the writes related to the umount. recovery.c doesn't say anything
> when the journal descriptor block fails csum verification, though it should.
> Not sure why we end up with corrupt-looking descriptor blocks.
>
> The reason why this appears in -rc3 is because that's when we added the patch
> that forces journal_checksum on whenever metadata_csum is on, and I guess
> few people were testing journal_checksum with xfstests before that.
>
> --D
prev parent reply other threads:[~2014-12-01 22:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-01 20:20 xfstests failures w/ metadata_csum Darrick J. Wong
2014-12-01 22:02 ` Darrick J. Wong
2014-12-01 22:05 ` Eric Whitney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141201220534.GA4619@wallace \
--to=enwlinux@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.