Full replication fails "dataset is busy"

[fa2k]

I'm having trouble replicating to a local drive on TrueNAS-SCALE-22.02.0 The source is a selection of datasets from my main pool. All are encrypted and unlocked. I'm using Full Filesystem Replication. When the target pool - backup - is empty (destroyed and created), it replicates the first dataset successfully, then replicates the second dataset "home", but fails after this with an error:

Code:

cannot destroy 'backup/home/%recv': dataset is busy

Then there is a "zfs receive" process running at 100% CPU utilisation.


When I start it again to resume, it doesn't seem to make any progress.

I hope someone can see if I made a mistake in the replication task. This task did work on TrueNAS CORE, but I have migrated to SCALE.

 

[fa2k]

By the way - the sources are not encryption roots. The structure looks like this:

 

[fa2k]

It seems to be a problem with OpenZFS. Even if I use the send and recv commands on the command line, I get the same problem. The transfer hangs, and there are some messages in the kernel log. Only the "home" dataset has a problem - all the others work well.

* I was able to replicate the oldest daily snapshot with a raw replication (-w), but when I tried an incremental transfer up to the newest snapshot, it stopped, like with the TrueNAS replication task.

* I wiped out the pool and did the raw replication of an old snapshot again. I was then able to do a non-raw incremental replication on top of that. It completed successfully. But the snapshot task won't run because it's not possible to do a raw replication on top of that again - an intentional limitation in zfs.

* I deleted all the daily snapshots, made a new one, and tried the transfer - same problem.
--
I hope an update may help to fix this bug.

The temporary solution for me is to do a non-raw replication, and receive it into an encrypted root on the backup pool. The inconvenience is that I have to manange two replication tasks (backup and backup-home), and have to unlock the backup pool (which is normally offline) when doing a backup.