Robert,
Hello Ben,
Monday, February 5, 2007, 9:17:01 AM, you wrote:
BR> I've been playing with replication of a ZFS Zpool using the
BR> recently released AVS. I'm pleased with things, but just
BR> replicating the data is only part of the problem. The big
BR> question is: can I have a zpool open in 2 places?
BR> What I really want is a Zpool on node1 open and writable
BR> (production storage) and a replicated to node2 where its open for
BR> read-only access (standby storage).
BR> This is an old problem. I'm not sure its remotely possible. Its
BR> bad enough with UFS, but ZFS maintains a hell of a lot more
BR> meta-data. How is node2 supposed to know that a snapshot has been
BR> created for instance. With UFS you can at least get by some of
BR> these problems using directio, but thats not an option with a zpool.
BR> I know this is a fairly remedial issue to bring up... but if I
BR> think about what I want Thumper-to-Thumper replication to look
BR> like, I want 2 usable storage systems. As I see it now the
BR> secondary storage (node2) is useless untill you break replication
BR> and import the pool, do your thing, and then re-sync storage to re-enable
replication.
BR> Am I missing something? I'm hoping there is an option I'm not aware of.
You can't mount rw on one node and ro on another (not to mention that
zfs doesn't offer you to import RO pools right now). You can mount the
same file system like UFS in RO on both nodes but not ZFS (no ro import).
One can not just mount a filesystem in RO mode if SNDR or any other
host-based or controller-based replication is underneath. For all
filesystems that I know of, expect of course shared-reader QFS, this
will fail given time.
Even if one has the means to mount a filesystem with DIRECTIO
(no-caching), READ-ONLY (no-writes), it does not prevent a filesystem
from looking at the contents of block "A" and then acting on block "B".
The reason being is that during replication at time T1 both blocks "A" &
"B" could be written and be consistent with each other. Next the file
system reads block "A". Now replication at time T2 updates blocks "A" &
"B", also consistent with each other. Next the file system reads block
"B" and panics due to an inconsistency only it sees between old "A" and
new "B". I know this for a fact, since a forced "zpool import -f
<name>", is a common instance of this exact failure, due most likely
checksum failures between metadata blocks "A" & "B".
Of course using an instantly accessible II snapshot of an SNDR secondary
volume would work just fine, since the data being read is now
point-in-time consistent, and static.
- Jim
I belive what you really need is 'zfs send continuos' feature.
We are developing something like this right now.
I expect we can give more details really soon now.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
