David Dyer-Bennet wrote: > My choice of mirrors rather than RAIDZ is based on > the fact that I have > only 8 hot-swap bays (I still think of this as LARGE > for a home server; > the competition, things like the Drobo, tends to have > 4 or 5), that I > don't need really large amounts of storage (after my > latest upgrade I'm > running with 1.2TB of available data space), and that > I expected to need > to expand storage over the life of the system. With > mirror vdevs, I can > expand them without compromising redundancy even > temporarily, by attaching > the new drives before I detach the old drives; I > couldn't do that with > RAIDZ. Also, the fact that disk is now so cheap > means that 100% > redundancy is affordable, I don't have to compromise > on RAIDZ.
Maybe I have been unlucky too many times doing storage admin in the 90s, but simple mirroring still scares me. Even with a hot spare (you do have one, right?) the rebuild window leaves the entire pool exposed to a single failure. One of the nice things about zfs is that allows, "to each his own." My home server's main pool is 22x 73GB disks in a Sun A5000 configured as RAIDZ3. Even without a hot spare, it takes several failures to get the pool into trouble. At the same time, there are several downsides to a wide stripe like that, including relatively poor iops and longer rebuild windows. As noted above, until bp_rewrite arrives, I cannot change the geometry of a vdev, which kind of limits the flexibility. As a side rant, I still find myself baffled that Oracle/Sun correctly touts the benefits of zfs in the enterprise, including tremendous flexibility and simplicity of filesystem provisioning and nondisruptive changes to filesystems via properties. These forums are filled with people stating that the enterprise demands simple, flexibile and nondisruptive filesystem changes, but no enterprise cares about simple, flexibile and nondisruptive pool/vdev changes, e.g. changing a vdev geometry or evacuating a vdev. I can't accept that zfs flexibility is critical and zpool flexibility is unwanted. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
