> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Jim Klimov > > 1) How does raidzN protect agaist bit-rot without known full > death of a component disk, if it at all does? > Or does it only help against "loud corruption" where the > disk reports a sector-access error or dies completely?
Whenever raidzN encounters a cksum error, it will read the redundant copies until it finds one that passes the cksum. The only ways you get unrecoverable cksum error are (a) more than N disks are failing, or (b) the storage subsystem - i.e. HBA, bus, memory, cpu, etc - are failing. Let's suppose one disk in a raidz (1) returns corrupt data silently. Recall that there is enough parity redundancy to recover from *any* complete disk failure. That means zfs can read disks 1,2,3,4... Then read disks 1,2,3,5... Then read disks 1,2,4,5... ZFS can figure out which disk returned the faulty data, UNLESS the disk actually returns correct data upon subsequent retries. > How *do* some things get fixed then - can only dittoed data > or metadata be salvaged from second good copies on raidZ? dittoed data is a layer of redundancy over and above your sysadmin chosen level of redundancy / raidz/mirror level. > One frequently announced weakness in ZFS is the relatively small > pool of engineering talent knowledgeable enough to hack ZFS and > develop new features (i.e. the ex-Sunnites and very few determined > other individuals): "We might do this, but we have few resources > and already have other more pressing priorities". While that may be true, compare it to everything else. I prefer ZFS over OnTap any day of the week. And although btrfs will be good someday, it's just barely suitable now for *any* production purposes. I don't see the competition developing faster than ZFS. > Likewise with opensource: yes, the code is there. A developer > might read into it and possibly comprehend some in a year or so. > Or he could spend a few days midway (when he knows enough to > pose hard questions not googlable in some FAQ yet) in yes-no > question sessions with the more knowledgeable people, and become > ready to work in just a few weeks from start. Wouldn't that be > wonderful for ZFS in general? :) You know the open-source question in regards to ZFS is pretty much concluded, right? What oracle called zpool version 28 was the last open source version, currently in use on nexenta, freebsd, and some others. The illumos project has continued development, minimally. If you think the development effort is resource limited in oracle working on zfs, just try the open source illumos community... Since close-sourcing a little over a year ago, oracle has continued developing and releasing new features... They're now at ... what, zpool version 37 or something? Illumos has continued developing too... Much less. Yes, it would be nice to see more open source development, but I think the main obstacle is the COW patent issue. Oracle is now immune from Netapp lawsuit over it, but if you want somebody ... for example perhaps Apple ... to contribute development resource to the open source branch, they'll have to duke it out with Netapp using their own legal resources. So far, the obstacle is just large enough that we don't see any other organizations contributing significantly. Linux is going with btrfs. MS has their own thing. Oracle continues with ZFS closed source. Apple needs a filesystem that doesn't suck, but they're not showing inclinations toward ZFS or anything else that I know of. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
