Re: [PATCH v2] xfs_repair: update the manual content about xfs_repair exit status

[Eric Sandeen <sandeen@sandeen.net>]

On 9/13/16 4:48 PM, Dave Chinner wrote:
> On Tue, Sep 13, 2016 at 11:57:59AM -0500, Eric Sandeen wrote:
>> On 9/13/16 11:32 AM, Darrick J. Wong wrote:

...

>>> So... I'd rather the documentation about the return code reflect the
>>> status of the filesystem -- 2 means "unclean log, replay it or zap it",
>>> 1 means "errors encountered, fs may not be correct", and 0 /should/ mean
>>> "fs is correct".
>>>
>>> OTOH I don't know for sure that xfs_repair always cleans up the fs on
>>> the first try.
>>
>> That's certainly the intent; I can't imagine a manpage documenting
>> return codes qualified with "... unless bugs happen." :)
> 
> Right - if we hit bugs, all bets are off. But otherwise, the fs
> should be repaired and clean after a single pass.
> 
>>>  ISTR
>>> asking Dave about this, and I think he said that the FS should be clean
>>> if repair returns 0.  But I'll let him reiterate that if it's true;
>>> don't trust my crummy memory, that's why I have filesystems. ;)
>>
>> Did you have an alternate wording in mind?
> 
> Yup, 0 = " fs is clean", 1 = "fs is still b0rken",
> 2 = "couldn't run for whatever reason given"

Technically, 1 = "may or may not be broken" - we really don't know.
We could get an exit of 1 for a consistent filesystem, for example
if some allocation failed... all we know is something bonked out in
the middle.

Maybe "1 == xfs_repair did not run to completion?"

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs