On Sat, Jan 23, 2010 at 12:30:01PM -0800, Simon Breden wrote: > And regarding mirror vdevs etc, I can see the usefulness of being > able to build a mirror vdev of multiple drives for cases where you > have really critical data -- e.g. a single 4-drive mirror vdev. I > suppose regular backups can help with critical data too.
Multi-way mirrors have lots of uses: - seek independence, for heavily read-biased loads (writes tend to kill this quickly by forcing all drives to seek together). - faster resilver times with less impact to production load (resilver reads are a particular case of the above) - capacity upgrades without losing redundancy in the process (note this is inherently n+1, proof by induction for arbitrary mirrors) - lots of variations of the "attach another mirror, sync and detach" workflow that "zpool clone" was created to support, whether for backup or reporting or remote replication or test systems or .. - "burning in" or qualifying new drives, to work out early failures before putting them in service (easy way to amplify a test workload by say 10x). Watch for slow units, as well as bad data/scrub fails. Just as good for amplifying test workload for controllers and other components. and.. um.. - testing dedup (make a n-way mirror out of n zvols on the same dedup'ed pool; comstar optional :) More seriously, though, it's for some of these scenarios that the zfs limitation of not being able to layer pool types (easily) is most irritating (raidz of mirrors, mirror of raidz). Again, that's in part because of practices developed previously; zfs may eventually offer even better solutions, but not yet. -- Dan.
pgpUCCDnHnJbO.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
