Checksumming filesystems

Question

Are BTRFS, ZFS, or ZFS Fuse ready for production use?
I care a whole lot about the integrity of my data.  I've had problems with XFS and EXT4 over the md device driver that turned out to be a bug in the Silicon Image 3132 chipset.  It quietly corrupts data.
These checksumming filesystems sound like the answer but are they ready?
BTRFS is pretty new but might have the most mature code of the three on the linux platform.
The paint is still wet on native Linux ZFS but I have to assume the original source code was rock solid before they ported it so it shouldn't take long to stabilize.
ZFS Fuse is said to be slow but I don't care much about speed.  Can I trust my data to it?
My main storage is on two very large RAID 5 arrays.  Currently, one is on EXT4 and the other is on XFS.  They are rsync'd regularly to for redundancy.  Is it reasonable to convert the primary array to ZFS?

Answer 1

I see nobody is interested in commenting.  These discussions frequently seem to turn into jihads based on platform politics so maybe this is why there are a small number of huge threads with vitriol and uninformed commentary.  I'm going to try to boil it down to some pretty lame basics that should be obvious, but aren't entirely.
This is based on weeks of reading, a few facts, lots of assumptions, and some experience.  I invite comments or criticism.
Preface: This research started when I realized my 14TB disk array was quietly corrupting my files.  ...  almost all of my files.  It was shocking that neither RAID nor filesystem were able to effect any positive influence on the integrity of my data.
Here's a CERN paper on Data Integrity.  It seems to be a key paper that has people buzzing, either in disbelief, or panic.  Consider me in the later reactive category.  lol!
http://indico.cern.ch/getFile.py/access … nfId=13797
The options:
md_mod/XFS -> Fast.  Venerable.  This setup is popular and will protect data against some types of drive failure but leaves data subject to bit rot and various forms of quiet corruption.  Your files can easily become corrupt with no warning or errors of any kind.
hardware RAID/XFS -> Fast (typically a touch slower than md_mod but far less taxing on the CPU than md_mod).  This setup will protect data against some types of drive failure but leaves data subject to bit rot and various forms of quiet corruption.  Your files can easily become corrupt with no warning or errors of any kind.
BTRFS - New.  Interesting.  Fast for a checksumming filesystem.  Still in the birthing process, it should be sufficiently stable for critical application use in 4~5 years.
Native ZFS - Very new.  Fast for a checksumming filesystem.  Highly venerable pedigree.  Too new to fully trust but with it's impeccable heritage and relatively small amount of linux glue code versus actual filesystem code, it should be well stable in 12~18 months.
ZFS Fuse - Mature.  Adequate speed.  This filesystem seems to have been stable since roughly 2008.  Given the bullet proof Sun roots of the filesystem and relatively long term use, it seems reasonable that the Linux integration code is stable at this time.  While ZFS Fuse will not pick up bit rot and quiet corruption dynamically, it can be tested occasionally with "zfs scrub <pool>".
Risk assessment criteria:
- data integrity
Risk assessment in order of least risk to most risk
- ZFS Fuse
- md_mod/XFS
- hardware RAID/XFS
- native ZFS
- BTRFS
Conclusion:
If the criteria is purely data integrity in a large data store, it looks to me like ZFS Fuse is the system to go with.