From: Zorro Lang <zlang@redhat.com>
To: linux-xfs@vger.kernel.org
Cc: xfs@oss.sgi.com, Zorro Lang <zlang@redhat.com>
Subject: [PATCH] xfs_repair: update the manual content about xfs_repair exit status
Date: Sat, 10 Sep 2016 12:47:29 +0800 [thread overview]
Message-ID: <1473482849-5706-1-git-send-email-zlang@redhat.com> (raw)
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 find valuable metadata changes in log
which needs to be replayed, 1 if it can't fix the corruption or some
other errors happened and 0 if nothing wrong or all the corruptions
were fixed.
Generally xfs_repair -L will always return 0, except it can't clear
the log.
Signed-off-by: Zorro Lang <zlang@redhat.com>
---
Hi,
I trusted the xfs_repair manpage, and thought xfs_repair will always return 0.
But recently I found it lies when I tried to review someone xfstests case.
A correct manpage will help more people to write right cases, so I try to modify
the manpage, by search all exit/do_error in xfsprogs/repair. I'm not the best
one who learn about xfs_repair, so I just hope I did the right thing:-P Please
feel free to correct me.
Thanks,
Zorro
man/man8/xfs_repair.8 | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/man/man8/xfs_repair.8 b/man/man8/xfs_repair.8
index 1b4d9e3..1f8f13b 100644
--- a/man/man8/xfs_repair.8
+++ b/man/man8/xfs_repair.8
@@ -504,12 +504,23 @@ that is known to be free. The entry is therefore invalid and is deleted.
This message refers to a large directory.
If the directory were small, the message would read "junking entry ...".
.SH EXIT STATUS
+.TP
.B xfs_repair \-n
(no modify node)
will return a status of 1 if filesystem corruption was detected and
0 if no filesystem corruption was detected.
+.TP
.B xfs_repair
-run without the \-n option will always return a status code of 0.
+run without the \-n option will return a status code of 2 if it find the
+filesystem has valuable metadata changes in log which needs to be
+replayed, 1 if there's corruption left to be fixed or can't find log head
+and tail or some other errors happened, and 0 if nothing wrong or all the
+corruptions were fixed.
+.TP
+.B xfs_repair \-L
+(Force Log Zeroing)
+will return a status code of 1 if it can't clear the log, or will always
+return 0.
.SH BUGS
The filesystem to be checked and repaired must have been
unmounted cleanly using normal system administration procedures
--
2.7.4
next reply other threads:[~2016-09-10 4:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-10 4:47 Zorro Lang [this message]
2016-09-12 16:01 ` [PATCH] xfs_repair: update the manual content about xfs_repair exit status Eric Sandeen
2016-09-13 14:44 ` Zorro Lang
2016-09-13 14:49 ` Eric Sandeen
-- strict thread matches above, loose matches on Subject: below --
2017-01-11 5:18 Zorro Lang
2017-01-11 13:47 ` Eric Sandeen
2017-01-11 17:45 ` Darrick J. Wong
2017-01-12 5:00 ` Zorro Lang
2017-01-12 4:53 ` Zorro Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1473482849-5706-1-git-send-email-zlang@redhat.com \
--to=zlang@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).