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>

diff --git a/repair/phase2.c b/repair/phase2.c
index 5964244bc98ee3c581a11c56b78cb17edc4548e3..c21778b8afb8cb98458666effd9c720253339aae 100644 (file)
--- a/repair/phase2.c
+++ b/repair/phase2.c
@@ -90,11 +90,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"