Replicating certain files reliably crashes TrueNAS

This is the first time I've heard of a "spill block". Thank you for explaining this further, .

For the meantime, I cannot send/recv my encrypted dataset, lest I crash my entire system again. (TrueNAS 12.0-U1)

Symlink value is stored not as data, but as special kind of system attribute.  Depending on size, system attributes can be stored in the dnode itself, or leak to separately addressed "spill block".  Recordsize is not used there.

"(I realize these questions are veering away from the purpose of this ticket, so I'll try to keep from going down a rabbit hole.)"

In my opinion, these questions are important. Native ZFS encryption is still in its infancy compared to other long-established alternatives. Who would have guessed that the path length woud cause kernel panics when sending raw encrypted streams?

"The longer path results in a different type of block being used."

To understand this correctly, you mean there is a special type of block used when a path exceeds X many characters?
https://jira.ixsystems.com/secure/AddComment!default.jspa?id=43557

Ah, I see, thanks.  Is the size of the block defined by the ZFS recordsize?  IOW, if I'd had a 1MiB recordsize on that dataset, would I not have triggered the bug because the path would have fit in a single block?

Is the "separate objects" you mention the "ZFS Structure" that is not encrypted per Tom Caputi's explanation of ZFS encryption?

(I realize these questions are veering away from the purpose of this ticket, so I'll try to keep from going down a rabbit hole.)

Encryption hides the data itself, but the data size still affects how it is processed.  The replication is still aware of separate objects within dataset, even though having no idea what they are and what's inside.