ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks

Matthew Seaman m.seaman at infracaninophile.co.uk
Sun Jan 9 10:03:25 UTC 2011

On 09/01/2011 09:01, Jean-Yves Avenard wrote:
> Hi
> On 9 January 2011 19:44, Matthew Seaman <m.seaman at infracaninophile.co.uk> wrote:
>> Not without backing up your current data, destroying the existing
>> zpool(s) and rebuilding from scratch.
>> Note: raidz2 on 4 disks doesn't really win you anything over 2 x mirror
>> pairs of disks, and the RAID10 mirror is going to be rather more performant.
> I would have thought that the probability of failure to be slightly different.
> Sure you out of 4 disks, 2 can fail in both conditions.
> *But*, in raidz2, any two of the four can fail.
> In RAID10, the two disks that failed must be in different block
> otherwise you loose it all
> As such the resilience for failure in a RAIDz2 is far greater than in
> a RAID10 system

So you sacrifice performance 100% of the time based on the very unlikely
possibility of drives 1+2 or 3+4 failing simultaneously, compared to the
similarly unlikely possibility of drives 1+3 or 1+4 or 2+3 or 2+4
failing simultaneously?[*]  That's not a trade-off worth making IMHO.
If the data is that valuable, you should be making copies of it to some
independent machine all the time and backing up at frequent intervals,
which backups you keep off-site in disaster-proof storage.



[*] All of this mathematics is pretty suspect, because if two drives
fail simultaneously in a machine, the chances are the failures are not
independent, but due to some external cause [eg. like the case fan
breaking and the box toasting itself.]  In which case, the comparative
chance of whatever it is affecting three or four drives at once renders
the whole argument pointless.

Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110109/4eb14cb3/signature.pgp

More information about the freebsd-stable mailing list