From: "Theodore Ts'o" <tytso@mit.edu>
To: Peter Geis <pgwipeout@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Ext4 corruption on linux-next since 5.2 merge window
Date: Fri, 24 May 2019 00:37:45 -0400 [thread overview]
Message-ID: <20190524043745.GG2532@mit.edu> (raw)
In-Reply-To: <f79a1b38-898d-8bfa-37d6-a74ee97411e5@gmail.com>
On Wed, May 22, 2019 at 07:40:26PM -0400, Peter Geis wrote:
> Good Evening,
>
> Since the 5.2 merge window, I've been encountering EXT4 corruption
> periodically.
Yeah, sorry. The fix is in the ext4.git tree, on the dev branch.
I'll be pushing it to Linus shortly.
It's actually not an actual file system corruption, but rather a false
positive, when there is sufficient memory pressure to push the extent
status tree entries for the journal out of the cache.
The fix is:
commit 0a944e8a6c66ca04c7afbaa17e22bf208a8b37f0
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed May 22 10:27:01 2019 -0400
ext4: don't perform block validity checks on the journal inode
Since the journal inode is already checked when we added it to the
block validity's system zone, if we check it again, we'll just trigger
a failure.
This was causing failures like this:
[ 53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode
#8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries
8, max 340(340), depth 0(0)
[ 53.931430] jbd2_journal_bmap: journal block not found at offset 49 on sda-8
[ 53.938480] Aborting journal on device sda-8.
... but only if the system was under enough memory pressure that
logical->physical mapping for the journal inode gets pushed out of the
extent cache. (This is why it wasn't noticed earlier.)
Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity")
Reported-by: Dan Rue <dan.rue@linaro.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
- Ted
prev parent reply other threads:[~2019-05-24 4:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-22 23:40 Ext4 corruption on linux-next since 5.2 merge window Peter Geis
2019-05-24 4:37 ` Theodore Ts'o [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=20190524043745.GG2532@mit.edu \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=pgwipeout@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).