Let zfs diff be more permissive.

[rincebrain]

Motivation and Context

#6335

Description

In the current world, zfs diff will die on first encounter of certain kinds of errors that come up on ordinary, not-mangled snapshots - like EINVAL, which can apparently come from a file with multiple hardlinks having the one whose name is referenced deleted.

Since they don't appear to indicate the snapshot is mangled in any way, let's relax about ENOENT and EINVAL - still print an error to stderr, but don't immediately abort when we encounter them.

How Has This Been Tested?

Quickly ran it locally on a pair of snapshots with 1TB of diff between them -

• Vanilla zfs diff dies after 48 files on the first EINVAL
• With this PR, zfs diff spits out 9326 lines, and the last one does not appear to be it dying on another error code.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[tonynguien]

Looks good to me.

[rincebrain]

This may take a little while for me to attempt the kernel changes version for, I need to do some poking around to figure out where the relevant return codes are coming from, but that's going to require making a copy of the dataset I have that triggers these conditions to play with in a VM, and it's several TB.

[behlendorf]

Yup, I think this makes sense.

[tonynguien]

@rincebrain - I updated the description/commit message to reflect current code. Can you let me know if this is OK or provide a description that I can use? Thanks!

======== Description ========
In the current world, zfs diff will die on first encounter of certain
kinds of errors that come up on ordinary, not-mangled snapshots - like
ENOENT for non-existent object and ENOTSUP for non-ZPL object.

Since they don't appear to indicate the snapshot is mangled in any way,
let's relax about ENOENT and ENOTSUP - still print an error to stderr,
but don't immediately abort when we encounter them.

[rincebrain]

This seems inaccurate, as it's (almost entirely; there is one ENOENT change because it can turn up somewhere else now) not the behavior of ENOTSUP/ENOENT we're changing, it's everything else - what about the current commit message do you disagree with?

[tonynguien]

This seems inaccurate, as it's (almost entirely; there is one ENOENT change because it can turn up somewhere else now) not the behavior of ENOTSUP/ENOENT we're changing, it's everything else - what about the current commit message do you disagree with?

You're right, of course. I misread that.

I'll use current commit message. Thanks!