I'm really not an expert on ZFS, but at least from my point to
handle such cases ZFS has to handle at least the following points
- GUID a new/different GUID has to be assigned
- LUNs ZFS has to be aware that device trees are different, if
these are part of some kind of metadata stored on the pools/fs
- FS Have to be mounted somewhere else
It looks as this has not been implemented yet nor even tested.
For Desaster Recovery this looks as a usefull way if it would work ;-)
Isn't it ?
Regards
Joerg
Jonathan Edwards wrote:
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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
