To steal terminology from git, I'd say that brtfs has a lot of similar plumbing as ZFS, but hardly any of the porcelain. I think the lack of striped raid is the killer for a lot of people, in spite of the hate RAID5 seems to have gained lately.
I went to a half-day Suse brunch event 2 months ago and got myself a eval copy of SLES v11sp2, just to check out brtfs. I tried to be mindful of the "it's not ZFS" attitude, and gave it a lot of leeway. Without going into the maturity of the code bse (I have no idea how stable it is), I found the capabilities and commands a bit cumbersome, counter-intuitive, and the FS as a whole just plain lacking. The article summed it up much more succinctly than I ever could.
I've been using ZFS on my primary workstation on a daily basis since the early beta days of FreeBSD 8.0 (Jun '09, I believe), and it has been a pure joy to use. ZFS v28 (the last released version from Sun/OpenSolaris, I think) found on FreeBSD 9.x is rock-solid and has reasonable performance (as compared to the speed and memory problems seen in in earlier releases).
I've put the filesystem through its paces, doing things that are rightfully called foolhardy, and I have never lost data. I've painted myself into a corner a few times (I curse the fact that you cannot remove hardware from the pool, as with Linux or AIX LVM), but never have I lost data when redundancy was in use. I have had bad sectors crop up on a single-disk zfs pool (single-copy of data, should have known better), and a "scrub" let me know exactly which files had incorrectable problems. Heck, I routinely flip the switch on my PSU when I'm too lazy to walk around my desk to do a proper shutdown, and it comes right back at next boot, no lengthy fsck, no data loss. I usually scrub monthly to check for errors, and otherwise I don't do much maintenance.
Right now, I have 6 2TB Seagate "green" drives in a raidz2 array (raid5-like with 2 parity disks). One disk has been removed due to errors, so I still have a spare disk to tide me over until I can afford a replacement. It runs very well.
I wish native ZFS crypto was available. Right now, each physical device is fully-encrypted with FreeBSD's "geli" (customer data, tax records, etc.), so ZFS doesn't even really have full ___domain over the physical devices, which makes it even more impressive that I've never lost data.
I will say that enabling compression and/or dedup will cause performance issues. I've got an 8-core AMD processor (XF-1850 -- hardware AES support, yay!) w/ 16GB of DDR3, and I get interactive desktop lag when heavy I/O is going against compressed and/or de-duped data. I don't know if this is a FreeBSD scheduling issue , or inherent with ZFS (any Solaris users want to comment?). Since it was mostly just to test (not like I need the space savings), I just do without.
In any case, I hope Linux's ZFS native kernel port stabilizes. brtfs just isn't there yet.
I did lose data from a ZFS raidz pool once. The cause turned out to be a slowly failing power supply. (An expensive, high-end OCZ unit, no less, with a 5-year warranty. OCZ replaced it without argument. Had it been a lesser PSU I might have suspected it sooner... oh well.)
Of course no filesystem could have survived that. But I still could really have used a salvager (fsck). I actually recovered a couple of critical files by dd-ing blocks off the disks.
FYI, I had a big array of green disks that ended up going out with ZFS, luckily not all at once. I read online that Seagate said they were not designed for use in RAID so they didn't cover it under warranty. You should replace those two disks with the Seagate Black series.
I went to a half-day Suse brunch event 2 months ago and got myself a eval copy of SLES v11sp2, just to check out brtfs. I tried to be mindful of the "it's not ZFS" attitude, and gave it a lot of leeway. Without going into the maturity of the code bse (I have no idea how stable it is), I found the capabilities and commands a bit cumbersome, counter-intuitive, and the FS as a whole just plain lacking. The article summed it up much more succinctly than I ever could.
I've been using ZFS on my primary workstation on a daily basis since the early beta days of FreeBSD 8.0 (Jun '09, I believe), and it has been a pure joy to use. ZFS v28 (the last released version from Sun/OpenSolaris, I think) found on FreeBSD 9.x is rock-solid and has reasonable performance (as compared to the speed and memory problems seen in in earlier releases).
I've put the filesystem through its paces, doing things that are rightfully called foolhardy, and I have never lost data. I've painted myself into a corner a few times (I curse the fact that you cannot remove hardware from the pool, as with Linux or AIX LVM), but never have I lost data when redundancy was in use. I have had bad sectors crop up on a single-disk zfs pool (single-copy of data, should have known better), and a "scrub" let me know exactly which files had incorrectable problems. Heck, I routinely flip the switch on my PSU when I'm too lazy to walk around my desk to do a proper shutdown, and it comes right back at next boot, no lengthy fsck, no data loss. I usually scrub monthly to check for errors, and otherwise I don't do much maintenance.
Right now, I have 6 2TB Seagate "green" drives in a raidz2 array (raid5-like with 2 parity disks). One disk has been removed due to errors, so I still have a spare disk to tide me over until I can afford a replacement. It runs very well.
I wish native ZFS crypto was available. Right now, each physical device is fully-encrypted with FreeBSD's "geli" (customer data, tax records, etc.), so ZFS doesn't even really have full ___domain over the physical devices, which makes it even more impressive that I've never lost data.
I will say that enabling compression and/or dedup will cause performance issues. I've got an 8-core AMD processor (XF-1850 -- hardware AES support, yay!) w/ 16GB of DDR3, and I get interactive desktop lag when heavy I/O is going against compressed and/or de-duped data. I don't know if this is a FreeBSD scheduling issue , or inherent with ZFS (any Solaris users want to comment?). Since it was mostly just to test (not like I need the space savings), I just do without.
In any case, I hope Linux's ZFS native kernel port stabilizes. brtfs just isn't there yet.