xfs_repair: update the manual content about xfs_repair exit status

The man 8 xfs_repair said "xfs_repair run without the -n option will
always return a status code of 0". That's not correct.

xfs_repair will return 2 if it finds a fs log which needs to be
replayed or cleared, 1 if runtime error is encountered, and 0 for
all other cases.

[ sandeen: editing for clarity ]

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>

diff --git a/man/man8/xfs_repair.8 b/man/man8/xfs_repair.8
index ae3f29393aa9ccfc50ca6396631ab74227314d08..85e4dc97aece04782f73ca9a705add244aa3f2bd 100644 (file)
--- a/man/man8/xfs_repair.8
+++ b/man/man8/xfs_repair.8
@@ -507,11 +507,17 @@ This message refers to a large directory.
 If the directory were small, the message would read "junking entry ...".
 .SH EXIT STATUS
 .B xfs_repair \-n
-(no modify node)
+(no modify mode)
 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.
+run without the \-n option will always return a status code of 0 if
+it completes without problems.  If a runtime error is encountered
+during operation, it will return a status of 1.  In this case,
+.B xfs_repair
+should be restarted.  If
+.B xfs_repair is unable
+to proceed due to a dirty log, it will return a status of 2.  See below.
 .SH DIRTY LOGS
 Due to the design of the XFS log, a dirty log can only be replayed 
 by the kernel, on a machine having the same CPU architecture as the