All this reminds me: how much work (if any) has been done on the
"asyncronous" mirroring option? That is, for supporting mirrors with
radically different access times? (useful for supporting a mirror
across a WAN, where you have hundred(s)-millisecond latency to the other
side of the mirror)?
-Erik
Scott Lawson wrote:
Bob Friesenhahn wrote:
On Fri, 18 Sep 2009, David Magda wrote:
If you care to keep your pool up and alive as much as possible,
then mirroring across SAN devices is recommended.
One suggestion I heard was to get a LUN that's twice the size, and
set "copies=2". This way you have some redundancy for incorrect
checksums.
This only helps for block-level corruption. It does not help much at
all if a whole LUN goes away. It seems best for single disk rpools.
I second this. In my experience you are more likely to have a single
LUN go missing for some reason or another and it seems most
prudent to support any production data volume with at the very minimum
a mirror. This also give you 2 copies in a far more resilient
way generally. (and per my other post, there can be other niceties
that come with it as well when couple with SAN based LUNS.)
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us,
http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
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
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
