From: Stan Hoeppner <stan@hardwarefreak.com>
To: Subranshu Patel <spatel.ml@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: Xfs_repair and journalling
Date: Sat, 16 Mar 2013 21:22:35 -0500 [thread overview]
Message-ID: <514528EB.9010905@hardwarefreak.com> (raw)
In-Reply-To: <CAEUQceh-Xcabr0KErxF6EAdafDDP1PY_AeHwgYB82QeUdyGp-g@mail.gmail.com>
On 3/16/2013 10:56 AM, Subranshu Patel wrote:
> This question is related to xfs_repair (recovery) and journalling.
>
> I powered off (improper shut down) the system when the IO was
> undergoing on mounted XFS filesystem.
>
> Then I tried to recover the inconsistent filesystem using xfs_repair,
> after powering on the same machine.
The whole point of a journaling filesystem is to recover automatically
after an unclean shutdown and put the filesystem in a consistent state.
> The XFS filesystem didn’t get recovered which was not expected.
This is because you short circuited the automatic recovery process. The
journal is replayed and the filesystem made consistent at the next mount
after unclean shutdown. You prevented this next mount.
> The output displayed by xfs_repair is as follows:
>
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
> - zero log...
> ERROR: The filesystem has valuable metadata changes in a log which needs to
> be replayed. Mount the filesystem to replay the log, and unmount it before
> re-running xfs_repair. If you are unable to mount the filesystem, then use
> the -L option to destroy the log and attempt a repair.
> Note that destroying the log may cause corruption -- please attempt a mount
> of the filesystem before doing this.
XFS is telling you to do what you should have done in the first place:
mount the filesystem so it can perform log recovery and make the XFS
consistent once again.
> The question that arises here is that why xfs_repair should be re-run
> after mounting and unmounting the XFS filesystem. According to my
> understanding, when we perform mount operation, recovery is
> automatically done if the filesystem is in inconsistent state. Then
> what is the need of re-running xfs_repair after mount is being
> performed? Does xfs_repair recovers something indifferent from the one
> recovered on mount? What exactly happens when we mount and unmount XFS
> filesystem?
No, the question that arises here is why you are intentionally short
circuiting the recovery process and immediately trying to run
xfs_repair. When a system is configured properly, write barriers or
BBWC are working properly, etc, one should never need to run xfs_repair
after an unclean shutdown, as recovery is automatic.
In fact, in general use, one should rarely, if ever, need to run
xfs_repair. I've been using XFS on production servers for a little over
3 years and I've never needed to run xfs_repair, and yes, I've had at
least two unclean shutdowns in that time.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-03-17 2:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-16 15:56 Xfs_repair and journalling Subranshu Patel
2013-03-17 2:22 ` Stan Hoeppner [this message]
2013-03-17 3:01 ` Michael L. Semon
2013-03-17 5:26 ` Stan Hoeppner
2013-03-17 11:42 ` Subranshu Patel
2013-03-17 14:50 ` Stan Hoeppner
2013-03-17 15:18 ` Matthias Schniedermeyer
2013-03-17 23:20 ` Dave Chinner
2013-03-18 18:22 ` Ben Myers
2013-03-18 20:58 ` Martin Steigerwald
2013-03-18 20:50 ` Martin Steigerwald
2013-03-19 4:02 ` Eric Sandeen
2013-03-19 6:19 ` Stan Hoeppner
2013-03-19 8:24 ` Martin Steigerwald
2013-03-19 10:14 ` Stan Hoeppner
2013-03-30 12:49 ` Xfs_repair and journalling -- EXT4 journal replay discussion Stan Hoeppner
2013-03-30 17:40 ` Eric Sandeen
2013-03-30 18:52 ` Stan Hoeppner
2013-03-30 20:21 ` Eric Sandeen
2013-03-31 11:24 ` Stan Hoeppner
2013-03-31 2:03 ` Dave Chinner
2013-03-31 1:35 ` Dave Chinner
2013-03-18 20:37 ` Xfs_repair and journalling Martin Steigerwald
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=514528EB.9010905@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=spatel.ml@gmail.com \
--cc=xfs@oss.sgi.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