zfs diff outputs grossly incorrect results

[rincebrain]

System information

Type	Version/Name
Distribution Name	Debian
Distribution Version	9.0
Linux Kernel	4.9.0-3-amd64
Architecture	x86_64
ZFS Version	0.6.5.9
SPL Version	0.6.5.9

Describe the problem you're observing

I have a temporary directory for incoming data that has nightly snapshots.

Per zfs list -t all -r...

monolith/unsorted/incoming@periodic-20161212   488K      -   579G  -
monolith/unsorted/incoming@periodic-20161213   720K      -   407G  -

But per zfs diff...

# zfs diff monolith/unsorted/incoming@periodic-20161212 monolith/unsorted/incoming@periodic-20161213
M       /monolith/unsorted/incoming/
Unable to determine path or stats for object 23125 in monolith/unsorted/incoming@periodic-20161212: Invalid argument
(The object with inum 23125 is an 18k textfile, the COPYING from a udev-0.5.5 tree. It is not 100+ GB)

[rincebrain]

In case anyone else runs into this and finds this bug but not the others (I'm looking at you, #7678 and #4367):

AFAICT, if it coughs up EINVAL for an object id, the object was a file with multiple hardlinks, but the parent path that was listed in the object (since there's only space for one - see here for more info) was deleted, so it no longer knows its own parent. (This is not evidence of a problem, just annoying for cases like zfs diff where you try to get a path for the object from the id.)

If it coughs up EEXIST, that seems to instead imply that some metadata for the object changed, e.g. xattrs or number of hardlinks. (I've only encountered the former, so I'm just extrapolating from my recent perusal of the bugs and code.)

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[rincebrain]

Lest anyone think this is fixed, I just ran into it again on 2.0.3, in which zfs diff between two snapshots whose REFER differs by over a TB reports only changes in 30 sub-1MB files.

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.