Ah, that's the one.
It is clearly a NetApp document but a lot of it seems to be a copy and paste of Sun ZFS technical material without much in the way of reference to its relevance on NetApp. For example, the benefits of ZVOLs are expounded without noting that they are completely redundant and a useless additional layer of complexity if you are already in an environment where you have a NetApp filer.
As a consequence, some of the claims made in it don't seem to make sense. For example :
"A mirrored configuration consumes more disk space but generally performs better with small
random reads. "
Irrespective of the whether the data is random or sequential, if you set up a mirrored zpool you will have to do additional, redundant (=pointless), reads or writes for each read or write you do to the ZFS volume. Aside from doing additional pointless accesses, the filer's own cache will get thrashed more. With two LUNs in a mirror the cache benefit would theoretically be half of what it would be without the LUNs being mirrored.
"A RAID Z2 configuration offers excellent data availability, and performs similarly to RAID Z. RAID
Z2 has significantly better mean time to data loss (MTTDL) than either RAID Z or two-way mirrors."
If you configure RAID-Zx (or any type of RAID from any vendor) on multiple NetApp LUNs that are hosted on the same aggregate (or any storage device from any vendor that already implements RAID and scrubbing, which most of them do), there is no additional data security benefit - WAFL already protects against creeping corruption - but there will be an additional performance hit due to the additional accesses. If you were crazy enough to do RAID-Z3 you would be doing three extra accesses for every block. I would imagine this would have "interesting" (in the Chinese proverb sense) effects on the filer's own internal caching algorithms. Not to mention using substantial extra storage space.
Those concerns won't apply if you are using zpools to create a mirror over multiple aggregates. But the document does not make this clear, and it should always be pointed out that you're a great deal better off using the native filer features for redundancy, mirroring, snapshots etc. (given that you've paid hefty $$$ for them) rather than adding an extra layer of complexity to sort-of do the same thing.
As for the self-healing thing .. the NetApp filer already does this, so it will catch and fix any errors (rebuilding physical disks as necessary) long before they become apparent to ZFS .. if ZFS even saw any corruption the filer would not be doing its job. The block alignment tips are worthwhile (and not an issue specific either to ZFS or to NetApp)
IMHO, this document does not look like it was supposed to have been released.
