On Wed, 23 Jul 2008, Miles Nordin wrote: > the problem is that it's common for a very large drive to have > unreadable sectors. This can happen because the drive is so big that > its bit-error-rate matters. But usually it happens because the drive > is starting to go bad but you don't realize this because you haven't > been scrubbing it weekly. Then, when some other drive actually does > fail hard, you notice and replace the hard-failed drive, and you're > forced to do an implicit scrub, and THEN you discover the second > failed drive. too late for mirrors or raidz to help.
The computed MTTDL is better for raidz2 than for two-way mirrors but the chance of loss is already small enough that humans are unlikely to notice. Consider that during resilvering the mirror case only has to read data from one disk whereas with raidz2 it seems that the number of disks which need to be read are the number of total disks minus two. This means that resilvering the mirror will be much faster and since it takes less time and fewer components are involved in the recovery, there is less opportunity for a second failure. The concern over scrub is not usually an issue since a simple cron job can take care of it. Richard's MTTDL writeup at http://blogs.sun.com/relling/entry/raid_recommendations_space_vs_mttdl is pretty interesting. However, Richard's writeup is also `flawed' since it only considers the disks involved and ignores the rest of the system. This is admitted early on in the statement that "MTTDL calculation is ONE attribute" of all the good things we are hoping for. Raw disk space is cheap. Mirrors are fast and simple and you can plan your hardware so that the data path to the disk is independent of the other disk. When in doubt add a third mirror. If you start out with just a little bit of data which grows over time, you can use three way mirroring and transition the extra mirror disks to become regular data disks later on. Bob ====================================== Bob Friesenhahn [EMAIL PROTECTED], 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
