On 1/12/17 1:34 PM, Darrick J. Wong wrote: > 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> Thanks, this seems fine. <resists urge to nitpick> ;) <reserves right to last-minute commit mods> :) Reviewed-by: Eric Sandeen <sandeen@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
