From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH v3 10/18] xfs_repair: don't clear the log by default
Date: Fri, 2 Oct 2015 14:19:47 -0400 [thread overview]
Message-ID: <1443809995-20395-11-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1443809995-20395-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-10-02 18:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 18:19 [PATCH v3 00/18] xfsprogs: format the log correctly on v5 supers Brian Foster
2015-10-02 18:19 ` [PATCH v3 01/18] libxfs: validate metadata LSNs against log on v5 superblocks Brian Foster
2015-10-02 18:19 ` [PATCH v3 02/18] libxfs: track largest metadata LSN in use via verifiers Brian Foster
2015-10-02 18:19 ` [PATCH v3 03/18] libxfs: don't hardcode cycle 1 into unmount op header Brian Foster
2015-10-02 18:19 ` [PATCH v3 04/18] libxfs: pass lsn param to log clear and record header logging helpers Brian Foster
2015-10-02 18:19 ` [PATCH v3 05/18] libxfs: add ability to clear log to arbitrary log cycle Brian Foster
2015-10-02 18:19 ` [PATCH v3 06/18] libxlog: pull struct xlog out of xlog_is_dirty() Brian Foster
2015-10-02 18:19 ` [PATCH v3 07/18] xfs_repair: track log state throughout all recovery phases Brian Foster
2015-10-02 18:19 ` [PATCH v3 08/18] xfs_repair: process the log in no_modify mode Brian Foster
2015-10-02 18:19 ` [PATCH v3 09/18] xfs_repair: format the log with forward cycle number on v5 supers Brian Foster
2015-10-02 18:19 ` Brian Foster [this message]
2015-10-02 18:19 ` [PATCH v3 11/18] xfs_repair: seed the max lsn from log state in phase 2 Brian Foster
2015-10-02 18:19 ` [PATCH v3 12/18] xfs_db: do not reset current lsn from uuid command on v5 supers Brian Foster
2015-10-02 18:19 ` [PATCH v3 13/18] db/metadump: bump lsn when log is cleared " Brian Foster
2015-10-02 18:19 ` [PATCH v3 14/18] xfs_copy: check for dirty log on non-duplicate copies Brian Foster
2015-10-02 18:19 ` [PATCH v3 15/18] xfs_copy: genericize write helper to facilitate separate log buf Brian Foster
2015-10-02 18:19 ` [PATCH v3 16/18] xfs_copy: store data buf alignment in buf data structure Brian Foster
2015-10-02 18:19 ` [PATCH v3 17/18] xfs_copy: refactor log format code into new helper Brian Foster
2015-10-02 18:19 ` [PATCH v3 18/18] xfs_copy: format v5 sb logs correctly 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=1443809995-20395-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