On Sep 18, 2006, at 14:41, Eric Schrock wrote:
2 - If you import LUNs with the same label or ID as a currently
mounted
pool then ZFS will .... no one seems to know. For example: I have
a pool
on two LUNS X and Y called mypool. I take a snapshot of LUN X & Y,
ignoring issue #1 above for now, to LUN X' and LUN Y' and wait a few
days. I then present LUNs X' and Y' to the host. What happens?
Make it
even more complex and present all the LUNs to the host after a
reboot.
Do you get different parts of the pool from different LUNs? Does ZFS
say, "What the hell?!??!"
ZFS will not allow you to import the second pool (I believe it won't
even present the pool as a valid option to import). Each pool is
identified by a unique GUID. You cannot have two pools active on the
system with the same GUID. If this is really a valid use case, we
could
invent a way to assign a new GUID on import.
err .. i believe the point is that you will have multiple disks
claiming to be the same disk which can wreak havoc on a system (eg:
I've got a 4 disk pool with a unique GUID and 8 disks claiming to be
part of that same pool) - it's the same problem on VxVM with storing
the identifier in the private region on the disks - when you do bit
level replication it's always blind to the upper-level, host-based,
logical volume groupings .. if this is the case - you're probably
best using the latest leadville patch (119130 or 119131) and
maintaining blacklists for what should be seen by the system. You
can also zone the BCVs or SI copies on the controller port to prevent
name collisions, but if you can't modify the portlist (eg: EMC bin
file changes) then the host based blacklist is going to be the way to
go.
Jonathan
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
