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@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. 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@xxxxxxxxxxxxx -- 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
