From: Eric Sandeen <sandeen@redhat.com>
To: Subranshu Patel <spatel.ml@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Recovery and Journalling
Date: Mon, 18 Mar 2013 11:00:22 -0500 [thread overview]
Message-ID: <51473A16.6080405@redhat.com> (raw)
In-Reply-To: <CAEUQcehjR7cgmYdTZ5_Yv8VuVAdPsL8i1ido9agmu5CzfknJNg@mail.gmail.com>
On 3/17/13 7:07 AM, Subranshu Patel wrote:
> This question is related to recovery (fsck and xfs_repair) and journalling.
>
> I powered off (improper shut down) the system when the IO was
> undergoing on mounted EXT4 filesystem.
>
> After that I powered on my machine and then used fsck on the unmounted
> filesystem. fsck recovered it.
>
> There are 2 things which I want to confirm:
> 1. Firstly fsck replays the journal for any unfinished inconsistent writes.
e2fsck replays the journal to produce a consistent set of metadata on the fs
> 2. Secondly it checks/repairs the other filesystem corruption.
Not by default
> Correct my understanding if wrong.
>
> Consider the above scenario for XFS as well. In XFS, i need to mount
> the filesystem, and this automatically replays the journal. After this
> I again unmount the filesystem and run xfs_repair.
There should be no need to run xfs_repair.
> But in EXT4, i have to run fsck mandatorily before mounting my
> filesystem.
It's not required.
> Please confirm my understanding.
Basic things first:
In general, journaling is metadata only (leaving aside for now ext3/4's "data=journal" option).
Metadata journaling ensures that if your system crashes or loses power, the contents of the filesystem + the contents of the log can be reassembled to produce a consistent set of metadata for the filesystem. Note that this does NOT imply no data loss; it only guarantees consistency.
After an unclean shutdown (crash or power loss), the journal is replayed in some manner, to regain consistency.
In ext3 & ext4, boot-time fsck can replay the journal in userspace, and performs no other consistency checks if the filesystem wasn't marked as having encountered a runtime error. When the filesystem mounts, it finds that the journal is clean (thanks to the prior e2fsck). If e2fsck is *not* run before mount, then the journal is replayed in the kernel at mount time.
XFS has no userspace journal replay. It happens only in the kernel at mount time.
There should be no need for an actual fsck (e2fsck/xfs_repair) run on a journaling filesystem after a crash; the whole point of the journal (and associated runtime overhead) is to guarantee consistency post-crash.
The only fundamental administrative difference here is that ext3/4 can have journals replayed either by e2fsck or by the kernel during mount; xfs's journal is only replayed by the kernel at mount time.
-Eric
prev parent reply other threads:[~2013-03-18 16:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-17 12:07 Recovery and Journalling Subranshu Patel
2013-03-18 16:00 ` Eric Sandeen [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=51473A16.6080405@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=spatel.ml@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).