Add a section describing what is a dirty log, why xfs_repair won't touch such things, and what one can do to clear the condition and check the filesystem. Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> --- man/man8/xfs_repair.8 | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/man/man8/xfs_repair.8 b/man/man8/xfs_repair.8 index 1b4d9e3..e4ca88e 100644 --- a/man/man8/xfs_repair.8 +++ b/man/man8/xfs_repair.8 @@ -510,6 +510,25 @@ will return a status of 1 if filesystem corruption was detected and 0 if no filesystem corruption was detected. .B xfs_repair run without the \-n option will always return a status code of 0. +.SH DIRTY LOGS +Due to the design of the XFS log, a dirty log can only be replayed on a +machine having the same CPU architecture as the machine which was +writing to the log. +xfs_repair cannot replay a dirty log and will return a status code of 2 +when it detects a dirty log. +.PP +In this situation, the log can be replayed by mounting and immediately +unmounting the filesystem on the same class of machine that crashed. +Please make sure that the machine's hardware is reliable before +replaying to avoid compounding the problems. +.PP +If mounting fails, the log can be erased by running xfs_repair with the +-L option. +All metadata updates in progress at the time of the crash will be lost, +which may cause significant filesystem damage. +This should +.B only +be used as a last resort. .SH BUGS The filesystem to be checked and repaired must have been unmounted cleanly using normal system administration procedures -- 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
