Default to zfs_dmu_offset_next_sync=1

[behlendorf]

Motivation and Context

Enable strict hole reporting by default to avoid the unclear
(but functionally correct) behavior of only reporting holes
in files which were not recently dirtied.

Description

Strict hole reporting was previously disabled by default as a
performance optimization. However, this has lead to confusion
over the expected behavior and a variety of workarounds being
adopted by consumers of ZFS. Change the default behavior to
always report holes and force the TXG sync.

How Has This Been Tested?

This behavior has also been tested in the context of issue #11900.

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.

[sempervictus]

@behlendorf - any thoughts on what the performance impact would be and under which conditions its most likely to be felt?

[behlendorf]

@sempervictus this will be felt most by any workload which writes a new file then immediately (within a few seconds) uses SEEK_HOLE/SEEK_DATA to determine where the holes/data are in that file. That first lseek() will incur the additional latency of a full pool sync but subsequent lseek() calls will not (unless that file is written to again). Files which haven't been recently modified won't see any change in behavior. This should be less of an issue for SSD/NVMe based pools with faster sync times, and more of an issues for large HDD pools with a lot of uncommitted data in the writeback cache.

[shodanshok]

@behlendorf just to be sure: is it safe to use the old default setting zfs_dmu_offset_next_sync=0 ? If I understand it correctly, the only possible drawback is to read some zeroes regions rather than skipping them via SEEK_HOLE, right?

[behlendorf]

@shodanshok yes that's right.