ignore return code of fstrim

[nopeslide]

devices (i.e. virtualized) may not support fstrim operations.

[behrmann]

Thanks for the contribution!

I guess this should be unproblematic.

[DaanDeMeyer]

Can we ignore a specific return code instead of ignoring all return codes? It would be even better if we could check if fstrim is supported before running fstrim but I guess detecting if it's supported might not be trivial.

[keszybz]

--quiet-unsupported instead?

[poettering]

Yes, please rework this to just use fstrim's --quiet-unsupported switch, which will just make the unsupported error go away, but all other errors will still be fatal and be logged.

[nopeslide]

@poettering Tried the flag first, but this seems to only surpress the output not the error code.

[nopeslide]

See https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/fstrim.c#n544

rc = fstrim_filesystem(&ctl, path, NULL);
if (rc == 1 && !ctl.quiet_unsupp)
	warnx(_("%s: the discard operation is not supported"), path);

return rc == 0 ? EXIT_SUCCESS : EXIT_FAILURE;

[nopeslide]

removed the non-existing co-author

[DaanDeMeyer]

Sorry for taking so long on this. Can we run the process (without the flag) and check the returncode and the output to figure out if the failure is due to fstrim being unsupported? If it's due to any other error, we can call die to make sure we don't continue if fstrim failed for another reason.

[poettering]

@karelzak shouldn't fstrim suppress not only the warning but also the unclean exit code when --quiet-unsupported it specified? i.e. isn't this something to fix in the fstrim tool?

[poettering]

Id probably merge this PR as it is though, the fstrim stuff is best-effort anyway, I doubt we need to put too much effort into working around the fact that we can't recognize the error cause properly here... I mean, even if @karelzak changes fstrim to return a clean exit code on EOPNOTSUPP, we should probably just work with released versions of fstrim too.