> 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

Reply via email to