"Drives don't usually go, they go one by one."
<br><br>Agreed. But, when you have multiple drives creating one pool, just having one drive go will give you a broken pool. <br><br>"I thought the big item for ZFS was smart redundancy run by the ZFS system that can recover with a drive failure."
<br><br>Yeah, ZFS has a cool feature of being able to report and repair inconsistencies, etc. assuming you have a RAID configuration setup. There is no magic here. Again, this is great for a server environment, but it may actually be more troublesome for end users that create storage pools of multiple disks without redundancy.<br><br>Here's a link you might want to look at. http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
<br><br>Specifically:<br>"Additional Cautions for Storage Pools<br>Review the following cautions before building your ZFS storage pool:<br>A pool created with a single slice has no redundancy and is at risk for data loss
.<br>A pool created with multiple slices but no redundancy is also at risk for data loss
. A pool created with multiple slices across disks is harder to manage than a pool created with whole disks.<br>A pool created with whole disks but no redundancy is at risk for data loss
. In addition, a pool that is not created with ZFS redundancy (RAIDZ or mirror) will only be able to report data inconsistencies. It will not be able to repair data inconsistencies
. Finally, a pool created without ZFS redundancy is harder to manage because you cannot replace or detach disks in a non-redundant ZFS configuration.<br>A pool cannot be shared across systems. ZFS is not a cluster file system."<br><br><br><br><br>