Fix raw receive with different indirect block size.

[amotin]

Unlike regular receive, raw receive require destination to have the same block structure as the source. In case of dnode reclaim this triggers two special cases, requiring special handling:

• If dn_nlevels == 1, we can change the ibs, but dnode_set_blksz() should not dirty the data buffer if block size does not change, or durign receive dbuf_dirty_lightweight() will trigger assertion.
• If dn_nlevels > 1, we just can't change the ibs, dnode_set_blksz() would fail and receive_object() would trigger assertion, so we should destroy and recreate the dnode from scratch.

How Has This Been Tested?

Without the patch raw receive triggers one or another assertion depending on file size if default_ibs is different between source and destination. Neither happens with the patch applied.

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.

[amotin]

I expect this to fix at least some cases of #13445.

[allanjude]

We have seen a few support cases related to this:

panic: VERIFY3(0 == dmu_object_set_blocksize(rwa->os, drro->drr_object,
drro->drr_blksz, drro->drr_indblkshift, tx)) failed (0 == 45)

cpuid = 1
time = 1654759253
KDB: stack backtrace:
#0 0xffffffff80c69465 at kdb_backtrace+0x65
#1 0xffffffff80c1bb1f at vpanic+0x17f
#2 0xffffffff82427f4a at spl_panic+0x3a
#3 0xffffffff82499cd0 at receive_object+0x6d0
#4 0xffffffff82497d49 at receive_writer_thread+0x199
#5 0xffffffff80bd8a5e at fork_exit+0x7e
#6 0xffffffff8108859e at fork_trampoline+0xe
Uptime: 13m37s

Where a raw recv would panic (FreeBSD 13.1) because the destination had a different blocksize.

The sender was TrueNAS-SCALE-22.02.1

[amotin]

because the destination had a different blocksize.

This patch supposed to fix only cases of different indirect block sizes, that is what I specifically tried to reproduce. Different block sizes should already be handled, but if that is what you see, it may be another problem.