Remove unused check from dmu_tx_count_write()

[behlendorf]

Motivation and Context

Resolve issue #3731.

Description

Individual transactions may not be larger than DMU_MAX_ACCESS.
This is enforced by the assertions in dmu_tx_hold_write() and
dmu_tx_hold_write_by_dnode(). There's an additional check in
dmu_tx_count_write() however it has no effect and only sets a
local err variable. We could enable this check, however since
it's already enforced by ASSERTs elsewhere I opted to remove it
instead.

How Has This Been Tested?

Locally compiled.

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.

[ahrens]

If I understand correctly this resolves #3731 because the it's saying that this is dead code, not that write() actually returns EFBIG (which is not true). I'm going to change its synopsis to reflect that.

I take it that since DMU_MAX_ACCESS should be enforced by calling code, we are OK with failing the ASSERT in the case of a bug in the calling (ZPL) code. Or on production builds, with driving on and probably everything will work even with larger writes (unless the pool totally runs out of space).

[behlendorf]

That's right. My thought was that it's sufficient to rely on the calling code and existing ASSERTs to enforce this. Since it's effectively been this way for years now this wouldn't change the production build behavior at all. That said, I'm not at all against returning EFBIG here instead if that's preferred. It does seem to be what the original code intended and it would be another safety check. It would just be an unused code path for all existing callers.