From: Eric Sandeen <sandeen@sandeen.net>
To: dann frazier <dann.frazier@canonical.com>,
linux-fsdevel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Jan Kara <jack@suse.com>
Cc: Colin King <colin.king@canonical.com>,
Ryan Harper <ryan.harper@canonical.com>
Subject: Re: ext4 fsck vs. kernel recovery policy
Date: Tue, 27 Aug 2019 16:39:55 -0500 [thread overview]
Message-ID: <e017ad27-15f5-b44c-7180-7b1545665fcd@sandeen.net> (raw)
In-Reply-To: <db1128a9-1316-e409-9dc6-9470bd2191f7@sandeen.net>
On 8/27/19 3:29 PM, Eric Sandeen wrote:
> On 8/27/19 2:10 PM, dann frazier wrote:
>> hey,
>> I'm curious if there's a policy about what types of unclean
>> shutdowns 'e2fsck -p' can recover, vs. what the kernel will
>> automatically recover on mount. We're seeing that unclean shutdowns w/
>> data=journal,journal_csum frequently result in invalid checksums that
>> causes the kernel to abort recovery, while 'e2fsck -p' resolves the
>> issue non-interactively.
>>
>> Driver for this question is that some Ubuntu installs set fstab's
>> passno=0 for the root fs - which I'm told is based on the assumption
>> that both kernel & e2fsck -p have parity when it comes to automatic
>> recovery - that's obviously does not appear to be the case - but I
>> wanted to confirm whether or not that is by design.
>>
>> -dann
>
> Ted or others more involved w/ ext4 will speak w/ authority but it's my
> understanding that log replay, whether done by userspace or by the kernel,
> should always return the filesystem to a consistent state.
I should amend: "from an otherwise normal unclean shutdown"
corruption discovered during recovery is a different matter, as adilger
pointed out.
-Eric
next prev parent reply other threads:[~2019-08-27 21:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 19:10 ext4 fsck vs. kernel recovery policy dann frazier
2019-08-27 20:27 ` Andreas Dilger
2019-08-29 22:53 ` dann frazier
2019-08-27 20:29 ` Eric Sandeen
2019-08-27 21:39 ` Eric Sandeen [this message]
2019-08-29 23:50 ` dann frazier
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=e017ad27-15f5-b44c-7180-7b1545665fcd@sandeen.net \
--to=sandeen@sandeen.net \
--cc=colin.king@canonical.com \
--cc=dann.frazier@canonical.com \
--cc=jack@suse.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ryan.harper@canonical.com \
--cc=tytso@mit.edu \
/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).