On Thu, June 3, 2010 10:50, Marty Scholes wrote: > 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.
No hot spare currently. And now running on 4-year-old disks, too. For me, mirroring is a big step UP from bare single drives. That's my "default state". Of course, I'm a big fan of multiple levels of backup. > 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. Yes, it's very flexible, and while there are no doubt useless degenerate cases here and there, lots of the cases are useful for some environment or other. That does seem like rather an extreme configuration. > 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. There are a LOT of reasons to want bp_rewrite, certainly. > 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. We could certainly use that level of pool-equivalent flexibility at work; we don't currently have it (not ZFS, not high-end enterprise storage units). -- David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
