From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH v3 11/18] xfs_repair: seed the max lsn from log state in phase 2
Date: Fri, 2 Oct 2015 14:19:48 -0400 [thread overview]
Message-ID: <1443809995-20395-12-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1443809995-20395-1-git-send-email-bfoster@redhat.com>
At this point, the log state is always available once repair has
progressed through phase 2 and the log is only ever zeroed when
absolutely necessary. This means that in the common case, repair runs
with the log in a non-initialized state. The libxfs max metadata LSN
tracking initializes the max LSN to zero, however, which will require
updates throughout the repair process even if all metadata LSNs are
behind the current LSN.
Since all metadata LSNs that are behind the current LSN are valid, seed
the libxfs maximum seen LSN value with the log state from phase 2. This
is a minor optimization to minimize global variable updates in the
common case where all (or most) metadata LSNs are valid.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
repair/phase2.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/repair/phase2.c b/repair/phase2.c
index fe7ed2b..f9d0e22 100644
--- a/repair/phase2.c
+++ b/repair/phase2.c
@@ -126,6 +126,13 @@ zero_log(
if (error || head_blk != tail_blk)
do_error(_("failed to clear log"));
}
+
+ /*
+ * Finally, seed the max LSN from the current state of the log if this
+ * is a v5 filesystem.
+ */
+ if (xfs_sb_version_hascrc(&mp->m_sb))
+ libxfs_max_lsn = log->l_last_sync_lsn;
}
/*
--
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:20 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 ` [PATCH v3 10/18] xfs_repair: don't clear the log by default Brian Foster
2015-10-02 18:19 ` Brian Foster [this message]
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-12-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