abd: lift ABD zero scan from zio_compress_data() to abd_cmp_zero()

[robn]

[Sponsors: Klara, Inc., Wasabi Technology, Inc.]

Motivation and Context

In #16323 I made all compression users call zio_compress_data() rather than doing their own bounce through zio_compress_table. It was (rightly) pointed out that this meant things that were not getting hole detection/flattening before now would.

For now I've reverted that change there. This PR is how I think I want to tackle that particular interface quirk though,

Description

This lifts the zero-detection code from inside zio_compress_data() into abd_cmp_zero() and abd_cmp_zero_off(), matching the interface of the other abd_cmp_* functions.

It's now the caller's responsibility do special handling for holes if that's something it wants.

All call sites have been checked and updated where necessary. The ones that haven't been touched are believed to either be impossible to have fully-zero data for input, or already did not properly handle a zero return from abd_compress_data().

How Has This Been Tested?

compression and rsend test tags pass successfully.

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.

[mcmilk]

LGTM

[amotin]

I was thinking about few places where we re-compress the data and expect achieving identical results, like L2ARC writing, encryption signature checks, etc. But I hope we should never reach any of them after the buffer is declared empty here.

Also I am not happy that comparison function requires buffer to be multiple of 8 bytes. Could we assert it while there? At some point experimenting with ZIL using odd gang ABDs to avoid memory copying I had a problem to figure out what are alignments requirements of ZIO pipeline. Assertion would make sure we'll notice immediately if anything go wrong.

[robn]

I was thinking about few places where we re-compress the data and expect achieving identical results, like L2ARC writing, encryption signature checks, etc. But I hope we should never reach any of them after the buffer is declared empty here.

I checked them all and I think we're safe. So long as it fails loudly I won't be too sad if we missed one.

Also I am not happy that comparison function requires buffer to be multiple of 8 bytes. Could we assert it while there? At some point experimenting with ZIL using odd gang ABDs to avoid memory copying I had a problem to figure out what are alignments requirements of ZIO pipeline. Assertion would make sure we'll notice immediately if anything go wrong.

Good call; added the assert. It's fairly straightforward to fix up, but I'll leave that until something needs it.