Sorry, I can't not respond... Edward Ned Harvey wrote: > whatever you do, *don't* configure one huge raidz3.
Peter, whatever you do, *don't* make a decision based on blanket generalizations. > If you can afford mirrors, your risk is much lower. > Because although it's > hysically possible for 2 disks to fail simultaneously > and ruin the pool, > the probability of that happening is smaller than the > probability of 3 > simultaneous disk failures on the raidz3. Edward, I normally agree with most of what you have to say, but this has gone off the deep end. I can think of counter-use-cases far faster than I can type. > Due to > smaller resilver window. Coupled with a smaller MTTDL, smaller cabinet space yield, smaller $/GB ratio, etc. > I highly endorse mirrors for nearly all purposes. Clearly. Peter, go straight to the source. http://blogs.sun.com/roch/entry/when_to_and_not_to In short: 1. vdev_count = spindle_count / (stripe_width + parity_count) 2. IO/s is proprotional to vdev_count 3. Usable capacity is proportional to stripe_width * vdev_count 4. A mirror can be approximated by a stripe of width one 5. Mean time to data loss increases exponentially with parity_count 6. Resilver time increases (super)linearly with stripe width Balance capacity available, storage needed, performance needed and your own level of paranoia regarding data loss. My home server's main storage is a 22 (19 + 3) disk RAIDZ3 pool backed up hourly to a 14 (11+3) RAIDZ3 backup pool. Clearly this is not a production Oracle server. Equally clear is that my paranoia index is rather high. ZFS will let you choose the combination of stripe width and parity count which works for you. There is no "one size fits all." -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
