Meanwhile, ZFS has over 10 years of history, stably implements most of Btrfs _planned_ features, and has battle tested deployments. Granted, the SPL for Linux adds variables, but there are some big users of this particular project.
So I approach Btrfs with the exact opposite mindset. It's guilty until innocent despite some FUD from the Linux camp early on that has settled down a bit since Oracle now has it's hands on both.
Honestly the same can be said about ZFS on Linux (and, quite frankly, even ZFS on Solaris). When it becomes "just the standard filesystem that everyone knows works", then people will stop yelling about the software (though the license mess will be with us forever, sadly).
The only time I've ever had a problem with btrfs was after a power failure, but btrfsck worked to fix it (although since it isn't in fsck.btrfs, it doesn't automatically run on boot, so I had to use the repair partition).
I've been using it for a year. I have around 8 hard disks in my machine, running half a dozen filesystems from fat32 to ntfs to ext4 to xfs, but I like btrfs the most of the native linux FSes atm.
It's been a multi-year mistake for us and we're busy changing these servers back to nice simple XFS volumes.
It may not have RAID 5/6, or time-proven stability, but it kicks ass and over time it will kick ZFS's ass not on technical grounds, but simply because ZFS has too much baggage and not enough community support.
But all that aside ZFS was great when it was first introduced a few years back, especially with Sun backing OpenSolaris, but we've been jerked around for a few years.
A ran a few ZFS pools on Linux a few builds ago and it was quite stable then. For something like a home storage system where I do not care about all the shortfalls vs. BTRFS I would reach to ZFS just because its what I know. For something that needs to be enterprise I'd hire someone that knows much more about it than me :).
Oracle's ZFS (and Solaris) fork is a deadish end. Most of the interesting action the past couple years has been happening among a collection of illumos (including critical ZFS members formerly from Sun), FreeBSD, OSX and even Linux hackers.
I don't follow their activities closely, except to observe that they've been anything but idle. A lot of work has happened in the meantime, and continues. Hopefully one shows up to comment about it.
For OSS ZFS the only upstream is 'collection of Illlumos'
In my opinion there are a were only a handful of reasons to use Solaris: Oracle, SPARC, ZFS and dtrace. The only reason to use it nowadays is because you can't scale x86 and need big iron for Oracle et al.
My earlier experiences with Solaris and OpenSolaris were mixed. SmartOS has been uniformly positive. Perhaps give it a try, although be aware that it (like everything illumos) is picky about the hardware.
Run began: Fri Mar 29 08:32:24 2013
Include fsync in write timing
Include close in write timing
Command line used: iozone -ec -r 32 -s 16380m -l 2 -i 0 -i 1 -i 8
Throughput test with 2 processes
Each process writes a 16773120 Kbyte file in 32 Kbyte records
Parent sees throughput for 2 initial writers = 996073.19 KB/sec
Avg throughput per process = 499898.70 KB/sec
Parent sees throughput for 2 rewriters = 216128.36 KB/sec
Avg throughput per process = 108075.14 KB/sec
Parent sees throughput for 2 readers = 1232245.62 KB/sec
Avg throughput per process = 616353.25 KB/sec
Parent sees throughput for 2 re-readers = 1240045.15 KB/sec
Avg throughput per process = 620251.62 KB/secNote also that rewriting drops to 108M/sec, which is pretty unimpressive.
I'm wondering which volume manager and fs under linux you'd expect better performance from in this configuration?
Enormous memory consumption = deduplication? Otherwise it doesn't seem enormous too me.
Sure ZFS made a lot of departures from the standard toolset with all its own stuff... but that stuff is better once you learn it.
I can easily get 600MB+/sec reads and writes on my pools with are pretty commodity stuff. One of my pools is 95% full, which is high, and I just tested it and got over ~100MB/sec write ~150MB read.... good enough for me. (Oh, and I just checked, it was scrubbing)
Here are my little ZFS peeves: 1. you can't grow raidZ vdevs. Reduces flexibility. 2. I wish there was a version of scrub that rebalanced data across vdevs.
By comparison BTRFS is nice, but nowhere close to ZFS. Last I saw a BTRFS scrub consists of cat'ing every file to null... which doesn't even cover the FS and metadata.
Yes, it will use whatever memory you allow it to, but this is purely dynamic just as caching is in Linux. If you're not talking about the ARC, but about deduplication, of course it uses more memory - how would it not?
"IO performance is generally not great (lower than with "simpler" FS)"
This is sounding troll-ish, as that statement equates to: A filesystem that checksums all data and metadata and performs copy-on-write to protect the integrity of the on-disk state at all times is slower than a filesystem that does neither.
Well, of course.
But do those "simpler FS" have the ability to massively negate that effect by use of an SSD for the ZIL and L2ARC? There have been many articles showing higher throughput with large, slow 5400RPM drives combined with an SSD ZIL & L2ARC massively outperforming much faster enterprise drives.
"managing your pools isn't that easy once you get serious about it"
I'm fairly stunned by this statement, as I've yet to see an easier, more elegant solution for such a task. Before ZFS, I liked VXVM with VXFS, but I now consider it obsolete. Linux's LVM is downright painful in comparison. I've yet to play with btrfs, so I'll bite my tongue on what I've read so far on it.
The deep integration of volume and pool management directly with the filesystem, essentially making them one and the same, is simply beautiful. Having these things separate (md, LVM, fs) after years of using ZFS seems so archaic and awkward to me.
Disclosure: 100% of my ZFS experience has been on Solaris (10-11.1) and OpenSolaris/Nevada. I've not tried it on Linux, yet.
My own anecdotal evidence is that btrfs is not ready for prime time. I ran a couple btrfs file systems from kernel about 2.6.30 to 3.4 and finally determined that my system was so slow because of btrfs. I switched to xfs and an operation that used to take weeks (literally) now takes hours.
Perhaps it's gotten significantly better in the last few revisions but I'd use caution if you want to use btrfs and still have good performance.
Don't use RAIDZ if you want performance with ZFS however, and you need to set it up twice before you get how to performance tune it.