On Mon, Sep 18, 2006 at 03:29:49PM -0400, Jonathan Edwards wrote: > > 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.
I don't understand how this changes my explanation at all. If you have multiple disks 'claiming to be the same disk', does this mean that they actually show up as the same /dev/dsk/* path depening on blind luck? If so, that's well below the level of ZFS. If they show up as different paths and/or devids, then ZFS will behave exactly as I described and you will be perfectly safe - you just won't be able to import the pool from the mirrored devices. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
