Blob Blame History Raw
From 47e48705ed893ca9f46adb02ad15e5acddbe060a Mon Sep 17 00:00:00 2001
From: Eric Sandeen <sandeen@redhat.com>
Date: Mon, 10 Apr 2017 17:32:04 -0500
Subject: [PATCH] xfs_repair: warn about dirty log with -n option

When looking at xfs_repair -n output today, we have no idea if
reported errors may be due to an un-replayed dirty log.  If this
is the case, mention it in the output.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
---
 repair/phase2.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Index: xfsprogs-4.5.0/repair/phase2.c
===================================================================
--- xfsprogs-4.5.0.orig/repair/phase2.c
+++ xfsprogs-4.5.0/repair/phase2.c
@@ -89,11 +89,16 @@ zero_log(
 	_("zero_log: head block %" PRId64 " tail block %" PRId64 "\n"),
 				head_blk, tail_blk);
 		}
-		if (!no_modify && head_blk != tail_blk) {
-			if (zap_log) {
+		if (head_blk != tail_blk) {
+			if (!no_modify && zap_log) {
 				do_warn(_(
 "ALERT: The filesystem has valuable metadata changes in a log which is being\n"
 "destroyed because the -L option was used.\n"));
+			} else if (no_modify) {
+				do_warn(_(
+"ALERT: The filesystem has valuable metadata changes in a log which is being\n"
+"ignored because the -n option was used.  Expect spurious inconsistencies\n"
+"which may be resolved by first mounting the filesystem to replay the log.\n"));
 			} else {
 				do_warn(_(
 "ERROR: The filesystem has valuable metadata changes in a log which needs to\n"