restore_object uses at least two transactions to restore an object
- one transaction is used for dmu_object_claim
- another transaction is used to set compression, checksum and most importantly bonus data
- furthermore dmu_object_reclaim internally uses multiple transactions
- dmu_free_long_range frees chunks in separate transactions
- dnode_reallocate is executed in a distinct transaction
The fact the dnode_allocate/ dnode_reallocate are executed in one transaction and bonus (re-)population is executed in a different transaction may lead to violation of ZFS consistency assertions if the transactions are assigned to different transaction groups.
Also, if the first transaction group is successfully written to a permanent storage, but the second transaction is lost, then an invalid dnode may be created on the stable storage.