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.
[...] always return a status code
of 0 if it completes without problems. If a runtime error is encoun-
tered during operation, it will return a status of 1. In this case,
xfs_repair should be restarted. If xfs_repair is unable to proceed due
to a dirty log, it will return a status of 2.
As for the flag, how about -e? It is not used yet and it makes some
sense as "e-exit code."
>
> The approach above looks ok in general. The main motivation for this
> is to be able to use some config management tool to push out a config
> to a whole fleet of machines in a lab, and have them check/fix the
> root fs without interaction. If a filesystem is failing to mount due
> to a dirty log, it's likely that the admin is in a more hands-on mode
> by then anyway.
>
> A dirty log could also be "operational error" if we decree that forcefsck
> and friends should only be used on a clean reboot - but I'm less certain
> about that.
I thought about it, but "errors left uncorrected" makes more sense here to me.
>
> Perhaps a guiding principal should be that we have no easy way to repair
> the root fs today in /any/ situation, so any correct/safe improvement
> to that situation is an improvement, even if not all cases are handled
> at this point.
>
Agreed.
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
