Re: [PATCH] fsck.xfs: allow forced repairs using xfs_repair

[Dave Chinner <david@fromorbit.com>]

On Thu, Mar 15, 2018 at 12:16:44PM +0100, Jan Tulak wrote:
> On Wed, Mar 14, 2018 at 4:19 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> > On 3/14/18 9:30 AM, Jan Tulak wrote:
> >> On Fri, Mar 9, 2018 at 12:28 AM, Eric Sandeen <sandeen@sandeen.net>
> >> wrote:
> >>>
> >>> If it's critical to report whether errors were fixed, it would be
> >>> trivial to add a new option to xfs_repair which causes it to test
> >>> fs_is_dirty for runs without "-n", and exit with a different
> >>> value.
> >>
> >> I have toyed with it a bit and this seems to be the best option. A
> >> flag that changes the exit code on a successful run. Is exit code 3
> >> ok? According to man page, only 1 and 2 are currently used and the
> >> "everything is ok now, but an issue was there" should not be mixed
> >> with the existing ones. I also thought about a flag that would
> >> change all exit codes to fsck ones, but that seems too complicated
> >> and completely unnecessary.
> >
> > Hm, I guess we'll have to.
> 
> We can either map xfs_repair to fsck in the fsck.xfs script, or change
> xfs_repair to use the fsck exit codes. I'm for the first variant (just
> add a one new exit code for xfs_repair and remap it for fsck codes in
> the script) rather than complicate xfs_repair with two sets of exit
> codes.

Agreed, any fsck specific exit code mapping should be in the fsck
script. Let's try to keep xfs_repair isolated from all the fsck
interface bogosities....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com