txg_sync should handle write errors in ZIL

[ryao]

Motivation and Context

The txg_sync thread will see certain buffers in a DR_IN_DMU_SYNC state when ZIL is writing them out. Then it waits until the state changes, but has an assertion to check that they were not DR_NOT_OVERRIDDEN. If the data write failed with an error, ZIL will put it into the DR_NOT_OVERRIDDEN state. It looks like the code will handle that state without an issue, so we can just delete the assertion.

This was done by Klara Systems and sponsored by Wasabi Technology, Inc.

Description

Delete unnecessary assertion.

How Has This Been Tested?

It has been runtime tested on ZFS by running a benchmark used by Wasabi Technology, Inc on top of a pool using a patched driver. The driver had other WIP patches on top, but this issue is believed to be present in the code without those patches.

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.

[ryao]

@behlendorf I have rebased this on master and repushed. While I did not keep a count of the precise number of test runs that included this patch, I have records for 1328 runs. While 20 of those runs had issues, none were attributable to this patch. As previously described in another pull request, the testing done on this patch was as follows:

We have a system with a 14 disk pool (typically all in a single raidz3 vdev, but also sometimes all as individual top level vdevs for testing purposes) and a script that will:

- Run a ZIL intensive workload that creates dozens of gigabytes of data
- Power-off 5 drives at the backplane while the workload is running
- After some time has elapsed and the pool has long faulted, power-on the drives
- Run zpool clear on the pool to unsuspend it.
- (As of a few weeks ago) Do a scrub.