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@xxxxxxxxxx>
---
pls check double-check my logic for the 3 cases :)
diff --git a/repair/phase2.c b/repair/phase2.c
index 5964244..c21778b 100644
--- 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"
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
