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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
