Update resume token at object receive.

[amotin]

Before this change resume token was updated only on data receive. Usually it is enough to resume replication without much overlap. But we've got a report of a curios case, where replication source was traversed with recursive grep, which through enabled atime modified every object without modifying any data. It produced several gigabytes of replication traffic without a single data write and so without a single resume point.

While the resume token was not designed to resume from an object, I've found that the send implementation always sends object before any data. So by requesting resume from offset 0 we are effectively resuming from the object, followed (or not) by the data at offset 0, just as we need it.

How Has This Been Tested?

I was able to recreate original problem, seeing no resume token updates during long stream receive without data. With the patch I see token updates, can resume replication using them and see that resumed stream starts from the expected object.

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.

[allanjude]

Reviewed-by: Allan Jude <[email protected]>

[pcd1193182]

It might be worth putting a comment in send_cb in the send code to say that we're actually relying on this behavior now; it's a somewhat natural result of the way dataset traversing works (When resuming from blkid 0 in an object, we haven't completed the whole subtree below the object, so the traverse code visits it, and we don't actually do any checks for where we're resuming from in the send code itself), but it's possible someone might want tweak that in the future, reintroducing this bug. That or we could add a zfs suite test to verify that this works, though I think it would necessarily need to be a little flaky unless we can manually make/tweak the resume token to get the effect we want.