I took a look at the dumps. There are 2 problems here. First is that
zpool on zpool on the same machine is not really supported. In the
pool_create dump, you are hitting a deadlock on the
spa_namespace_lock, between the 2 threads listed below. In the
zfs_send dump, it looks like there is a deadlock on the
zfsdev_state_lock.
This is causing the system to hang, causing a timeout in the iscsi
code. This is hitting a different bug in iscsi which is causing the
panic. It looks like some thread has forgotten to release the
ic_state_mutex.
I imagine you could get iscsi out of the picture by using the LUN
directly as /dev/zvol/dsk/..., but you'd still hit the problem of pool
on pool on the same machine. I think some development work would be
required to make this use case work correctly.
--matt
As we have far too little knowledge to do that development work, I will
go for the 2 machines fallback.
Interesting indeed that no one else used that design, as it saves money.
Anyhow i want to thank you very much for clearing up that issue.
Franz
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
