Sorry, I popped up to Hokkdaido for a holiday. I want to thank you all for the replies.
I mentioned AVS as I thought it to do be the only product close to enabling us to do a (makeshift) fail-over setup. We have 5-6 ZFS filesystem, and 5-6 zvol with UFS (for quotas). To do "zfs send" snapshots every minute might perhaps be possible (just not very attractive), but if the script dies at any time, you need to resend the full volumes, this currently takes 5 days. (Even using "nc"). Since we are forced by vendor to run Sol10, it sounds like AVS is not an option for us. If we were interested in finding a method to replicate data to a 2nd x4500, what other options are there for us? We do not need instant updates, just someplace to fail-over to when the x4500 panics, or a HDD dies. (Which equals panic) It currently takes 2 hours to fsck the UFS volumes after a panic (and yes, they are logging; it is actually just the one UFS volume that always needs fsck). Vendor has mentioned "VeritasVolumReplicator" but I was under the impression that Veritas is a whole different set to zfs/zpool. Lund Jim Dunham wrote: > On Sep 11, 2008, at 5:16 PM, A Darren Dunham wrote: >> On Thu, Sep 11, 2008 at 04:28:03PM -0400, Jim Dunham wrote: >>> On Sep 11, 2008, at 11:19 AM, A Darren Dunham wrote: >>> >>>> On Thu, Sep 11, 2008 at 10:33:00AM -0400, Jim Dunham wrote: >>>>> The issue with any form of RAID >1, is that the instant a disk >>>>> fails >>>>> out of the RAID set, with the next write I/O to the remaining >>>>> members >>>>> of the RAID set, the failed disk (and its replica) are instantly >>>>> out >>>>> of sync. >>>> Does raidz fall into that category? >>> Yes. The key reason is that as soon as ZFS (or other mirroring >>> software) >>> detects a disk failure in a RAID >1 set, it will stop writing to the >>> failed disk, which also means it will also stop writing to the >>> replica of >>> the failed disk. From the point of view of the remote node, the >>> replica >>> of the failed disk is no longer being updated. >>> >>> Now if replication was stopped, or the primary node powered off or >>> panicked, during the import of the ZFS storage pool on the secondary >>> node, the replica of the failed disk must not be part of the ZFS >>> storage >>> pool as its data is stale. This happens automatically, since the ZFS >>> metadata on the remaining disks have already given up on this >>> member of >>> the RAID set. >> Then I misunderstood what you were talking about. Why the restriction >> on RAID >1 for your statement? > > No restriction. I meant to say, RAID 1 or greater. > >> Even for a mirror, the data is stale and >> it's removed from the active set. I thought you were talking about >> block parity run across columns... >> >> -- >> Darren >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > Jim Dunham > Engineering Manager > Storage Platform Software Group > Sun Microsystems, Inc. > work: 781-442-4042 > cell: 603.724.2972 > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > -- Jorgen Lundman | <[EMAIL PROTECTED]> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
