Map ECKSUM and EFRAGS from ZFS onto real errnos

[freqlabs]

Summary

Make it less confusing when, for example, stat sets errno to 122 because a checksum failed in ZFS:

Before: getfacl: /foo/bar: stat() failed: Unknown error: 122
After: getfacl: /foo/bar: stat() failed: Integrity check failed

Sponsored by: iXsystems, Inc.

[mckusick]

Adding a new error number requires changes to a lot more files than just lib/libc/gen/errlst.c. See for example -r343111 when I added EINTEGRITY which touched 16 different files in the system. And that is just to add the base error. It then has to be added to every system call manual page for which it can be returned.

The easier way to fix this problem is to map ZFS specific errors to existing errors in FreeBSD. In this case, I would map ECKSUM to EINTEGRITY and assuming that EFRAGS is returned when a write fails due to lack of ability to store it, I would map it to ENOSPC.

[freqlabs]

Incorporate feedback. Map the constants to existing errnos instead of adding messages for old numbers.

[mav]

EFRAGS seems not to be really used on FreeBSD. It is mentioned once in code, but it seems to be dead from the day one -- used on Illumos to support dumping to ZVOL. I am not sure why ZoL haven't dropped it yet.
About ECKSUM->EINTEGRITY I have no objections, other then Linux maps it into some nonsense, so some applications may get surprised if notice the difference. But that may be unavoidable.

[mckusick]

I agree with mac@ that it looks like EFRAGS is only in an unused code path. But it does not hurt to map it to a FreeBSD error in the event that the code path gets brought back to life.

I suggest that you add a comment above the new defines that explain that they map ZFS errors to their closest equivalent FreeBSD errors.

[freqlabs]

Add a comment explaining the motivation for the mapping.

[mckusick]

Looks good to go.

[freqlabs]

@mckusick I would like to MFC your EINTEGRITY change to stable/12 along with this change. Does this seem reasonable? At a glance the only merge conflict is that stable/12 doesn't have contrib/libc++, so that part of the patch would be dropped. Anything else to look out for?
Thanks in advance!

[mckusick]

After consulting with kib@ I have concluded that it is acceptable to MFC -r343111 to stable/12. You should MFC your change separately (i.e., in a second checkin).