From 47e48705ed893ca9f46adb02ad15e5acddbe060a Mon Sep 17 00:00:00 2001 From: Eric Sandeen 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 Reviewed-by: Darrick J. Wong Signed-off-by: Eric Sandeen --- 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"