On Fri, Mar 23, 2018 at 2:57 AM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > On 3/15/18 1:23 PM, Jan Tulak wrote: >> xfs_repair ends with a return code 0 if it finished ok, no matter if >> there were some errors in the fs, or not. The new flag -e means that we >> can avoid screenscraping and parsing text output to detect if an error >> was found (and corrected). >> >> If something could not be corrected or in any other case than the "found >> something but fixed it all," the behaviour with this flag is unchanged. >> >> Signed-off-by: Jan Tulak <jtulak@xxxxxxxxxx> > > A couple more minor things, sorry for chiming in late. > > Can we make the changelog summary a little more specific, i.e. > > "xfs_repair: add flag -e to modify exit code for corrected errors" > > I had a late-breaking thought ;) that maybe we should skip up to exit > code 4, so that if for some reason in the future we need to, we can > OR together exit codes ala e2fsck to convey more information. > I don't know what other exit codes we might need, but this might > future-proof it a little. > > (Actually, I can see an use today: 1 | 4 = 5 could mean > "we found and fixed some errors and then encountered an operational > problem and exited." - but that can come later, not here. Skipping > to 4 would keep this option open.) > That makes sense. I will update it accordingly. And thanks for the rest of the things, fixing that too. -- 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
