Solved zfs send/recv: cannot unmount, device busy?

[`Orum]

I have two systems with identical hardware, and I'm trying to clone the zroot storage pool (which currently exists on both machines, and is what each booted from) from one system to the other. I've already done a recursive snapshot of the zroot pool, naming it the "now" snapshot. The command I'm using to try and send/recv is:
zfs send -R zroot@now | ssh foo zfs recv -vFd zroot
However, when I run this, I strangely get:

cannot unmount '/var/log': Device busy

I'm not sure which machine that error is coming from, or why it's even trying to unmount anything. Poring over the man page hasn't revealed anything obvious, either. Any ideas?

Edit: It appears it's trying to unmount on the recv side, as redirecting the send output to /dev/null doesn't cause an error. It's still not clear why it's trying to unmount though...

Edit2: I'm beginning to think that, unfortunately, it's not possible to recv to any mounted zfs file system. And, since that entire pool needs to be transferred, and that's also the system pool, there's no easy way to accomplish this without installing world in a md device or just booting from the memstick and transferring to the root pool while it's offline using the "live-cd" mode. Can anyone confirm?

 

[`Orum]

Anyway, I gave up trying to transfer to a mounted root pool. It did work when I booted to another environment and transferred it over, so I'm assuming for whatever reason it's not possible to recv to a mounted pool.

 

[ShelLuser]

The problem is that the behavior heavily depends on what data you're sending, see also zfs(8):

         If an incremental stream is received, then the destination file
         system must already exist, and its most recent snapshot must match
         the incremental stream's source. For zvols, the destination device
         link is destroyed and recreated, which means the zvol cannot be
         accessed during the receive operation.

Obviously you can't "just" destroy your root filesystem because that's what your whole OS relies on. So I think that's probably the reason for your problems.

 

[`Orum]

The problem is that the behavior heavily depends on what data you're sending, see also zfs(8):

Ah, the way that is written is confusing, as I thought that the zvols were only destroyed and recreated if it was an incremental stream (there is no paragraph break between those sentences).

Obviously you can't "just" destroy your root filesystem because that's what your whole OS relies on. So I think that's probably the reason for your problems.

Yeah, it's kind of a shame that there's no way to create a snapshot via zfs recv to a live fs. I'm considering HAST instead, but that looks to have tons of issues when you run ZFS on top of it.