]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs_repair: don't clear the log by default
authorBrian Foster <bfoster@redhat.com>
Tue, 13 Oct 2015 23:58:24 +0000 (10:58 +1100)
committerDave Chinner <david@fromorbit.com>
Tue, 13 Oct 2015 23:58:24 +0000 (10:58 +1100)
commitf2053bc8dde13064d35ba1f8501b879bbc53fe2e
tree106e99ad10563b183c79c4fa50a05e965d165aa7
parent1926558d49b01953ba8fd5499b2251a31f5d0454
xfs_repair: don't clear the log by default

xfs_repair currently clears the log regardless of whether it is
corrupted, clean or contains data. This is traditionally harmless but
now causes log recovery problems on v5 filesystems. v5 filesystems
expect a clean log to always have an LSN out ahead of the maximum last
modification LSN stamped on any bit of metadata throughout the fs. If
this is not the case, repair must reformat the log with a larger cycle
number after fs processing is complete.

Given that unconditional log clearing actually introduces a filesystem
inconsistency on v5 superblocks (that repair must subsequently recover
from) and provides no tangible benefit for v4 filesystems that otherwise
have a clean and covered log, it is more appropriate behavior to not
clear the log by default.

Update xfs_repair to always and only clear the log when the -L parameter
is specified. Retain the existing logic to require -L or otherwise exit
if the log appears to contain data. Adopt similar behavior if the log
appears to be corrupted.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
repair/phase2.c