I realize that the problem with the secondary node can be the "R" state on
"dsstat". One half of the mirror was in replicating state already... so, that
could be the cause of the solaris zfs panic.
But i think this is a "bad" behaviour because such situation should be
avoided. If i'm right, the state changes must be "all-or-nothing", because the
source of the synchronization (in this case the secondary node), can not become
inconsistent. Or "all" the pool is resync and "all" the pool change to
"replicating", or the pool on the source remains intact. IF i'm correct, i
think this is a bug.
Leal.
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
