On Wed, Mar 14, 2018 at 4:19 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > On 3/14/18 9:30 AM, Jan Tulak wrote: >> On Fri, Mar 9, 2018 at 12:28 AM, Eric Sandeen <sandeen@xxxxxxxxxxx> >> 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. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
