From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH v2 10/12] xfs_repair: don't clear the log by default
Date: Fri, 11 Sep 2015 14:55:40 -0400 [thread overview]
Message-ID: <1441997742-37160-11-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com>
xfs_repair currently clears the log regardless of whether it is
corrupted, clean or contains data. This is traditionally harmless but
now causes log recovery problems on v5 filesystems. v5 filesystems
expect a clean log to always have an LSN out ahead of the maximum last
modification LSN stamped on any bit of metadata throughout the fs. If
this is not the case, repair must reformat the log with a larger cycle
number after fs processing is complete.
Given that unconditional log clearing actually introduces a filesystem
inconsistency on v5 superblocks (that repair must subsequently recover
from) and provides no tangible benefit for v4 filesystems that otherwise
have a clean and covered log, it is more appropriate behavior to not
clear the log by default.
Update xfs_repair to always and only clear the log when the -L parameter
is specified. Retain the existing logic to require -L or otherwise exit
if the log appears to contain data. Adopt similar behavior if the log
appears to be corrupted.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
repair/phase2.c | 60 ++++++++++++++++++++++++++++++++++++++-------------------
1 file changed, 40 insertions(+), 20 deletions(-)
diff --git a/repair/phase2.c b/repair/phase2.c
index 72132ce..fe7ed2b 100644
--- a/repair/phase2.c
+++ b/repair/phase2.c
@@ -36,11 +36,13 @@ int xlog_recover_do_trans(struct xlog *log, xlog_recover_t *t, int p)
}
static void
-zero_log(xfs_mount_t *mp)
+zero_log(
+ struct xfs_mount *mp)
{
- int error;
- xfs_daddr_t head_blk, tail_blk;
- struct xlog *log = mp->m_log;
+ int error;
+ xfs_daddr_t head_blk;
+ xfs_daddr_t tail_blk;
+ struct xlog *log = mp->m_log;
memset(log, 0, sizeof(struct xlog));
x.logBBsize = XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks);
@@ -65,10 +67,22 @@ zero_log(xfs_mount_t *mp)
}
log->l_sectbb_mask = (1 << log->l_sectbb_log) - 1;
- if ((error = xlog_find_tail(log, &head_blk, &tail_blk))) {
- do_warn(_("zero_log: cannot find log head/tail "
- "(xlog_find_tail=%d), zeroing it anyway\n"),
+ /*
+ * Find the log head and tail and alert the user to the situation if the
+ * log appears corrupted or contains data. In either case, we do not
+ * proceed past this point unless the user explicitly requests to zap
+ * the log.
+ */
+ error = xlog_find_tail(log, &head_blk, &tail_blk);
+ if (error) {
+ do_warn(
+ _("zero_log: cannot find log head/tail (xlog_find_tail=%d)\n"),
error);
+ if (!no_modify && !zap_log)
+ do_error(_(
+"ERROR: The log head and/or tail cannot be discovered. Attempt to mount the\n"
+"filesystem to replay the log or use the -L option to destroy the log and\n"
+"attempt a repair.\n"));
} else {
if (verbose) {
do_warn(
@@ -93,19 +107,25 @@ zero_log(xfs_mount_t *mp)
}
}
- if (no_modify)
- return;
-
- libxfs_log_clear(log->l_dev, XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart),
- (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks),
- &mp->m_sb.sb_uuid,
- xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1,
- mp->m_sb.sb_logsunit, XLOG_FMT, XLOG_INIT_CYCLE);
-
- /* update the log data structure with new state */
- error = xlog_find_tail(log, &head_blk, &tail_blk);
- if (error || head_blk != tail_blk)
- do_error(_("failed to clear log"));
+ /*
+ * Only clear the log when explicitly requested. Doing so is unnecessary
+ * unless something is wrong. Further, this resets the current LSN of
+ * the filesystem and creates more work for repair of v5 superblock
+ * filesystems.
+ */
+ if (!no_modify && zap_log) {
+ libxfs_log_clear(log->l_dev,
+ XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart),
+ (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks),
+ &mp->m_sb.sb_uuid,
+ xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1,
+ mp->m_sb.sb_logsunit, XLOG_FMT, XLOG_INIT_CYCLE);
+
+ /* update the log data structure with new state */
+ error = xlog_find_tail(log, &head_blk, &tail_blk);
+ if (error || head_blk != tail_blk)
+ do_error(_("failed to clear log"));
+ }
}
/*
--
2.1.0
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-09-11 18:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 18:55 [PATCH v2 00/12] xfsprogs: format the log correctly on v5 supers Brian Foster
2015-09-11 18:55 ` [PATCH v2 01/12] libxfs: validate metadata LSNs against log on v5 superblocks Brian Foster
2015-09-11 18:55 ` [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers Brian Foster
2015-09-23 3:44 ` Dave Chinner
2015-09-23 13:18 ` Brian Foster
2015-09-23 22:36 ` Dave Chinner
2015-10-01 20:38 ` Brian Foster
2015-10-02 2:16 ` Dave Chinner
2015-10-02 11:33 ` Brian Foster
2015-09-11 18:55 ` [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header Brian Foster
2015-09-23 3:48 ` Dave Chinner
2015-09-23 13:22 ` Brian Foster
2015-09-24 0:37 ` Dave Chinner
2015-09-24 13:00 ` Brian Foster
2015-09-11 18:55 ` [PATCH v2 04/12] libxfs: pass lsn param to log clear and record header logging helpers Brian Foster
2015-09-11 18:55 ` [PATCH v2 05/12] libxfs: add ability to clear log to arbitrary log cycle Brian Foster
2015-09-11 18:55 ` [PATCH v2 06/12] libxlog: pull struct xlog out of xlog_is_dirty() Brian Foster
2015-09-11 18:55 ` [PATCH v2 07/12] xfs_repair: track log state throughout all recovery phases Brian Foster
2015-09-11 18:55 ` [PATCH v2 08/12] xfs_repair: process the log in no_modify mode Brian Foster
2015-09-11 18:55 ` [PATCH v2 09/12] xfs_repair: format the log with forward cycle number on v5 supers Brian Foster
2015-09-11 18:55 ` Brian Foster [this message]
2015-09-11 18:55 ` [PATCH v2 11/12] xfs_db: do not reset current lsn from uuid command " Brian Foster
2015-09-11 18:55 ` [PATCH v2 12/12] db/metadump: bump lsn when log is cleared " Brian Foster
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=1441997742-37160-11-git-send-email-bfoster@redhat.com \
--to=bfoster@redhat.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