On Sun, Feb 28, 2016 at 8:34 AM, Tanstaafl <[email protected]> wrote: > > Also, it has been a while since I read anything - what is the current > state of BTRFS vs ZFS? Is it stable/mature enough to use for production? > What can ZFS do that it cannot? >
This is obviously a topic people will have various opinions on. I'd say that zfs is more stable, but long-term less likely to be the mainstream linux solution. At the current time I'd say that btrfs single-disk or in raid1 is mature enough to be usable, with a bunch of caveats. It definitely isn't up there with the likes of ext4. Besides some stuff just not being handled gracefully like low-disk-space it is fairly prone to regressions. I've found I've gotten the best experience by sticking with longterm kernels and not updating to the next one until it reaches maybe x.x.16 or so (maybe 6mo after release), and I always check the lists before updating. As far as features go, zfs tends to have more enterprise-oriented features and btrfs tends to have more small-system-oriented features. For example, in zfs with 100 drives you can arrange them into 10 neat raid-6s with 10 drives each or something along those lines, and have a few SDDs servicing the entire array as read and write caches. On the other hand, if you have a 4-drive raid5 and want to turn it into a 5-drive raid5 this is impossible to do in zfs without copying all the data off the drives, but trivial to do in btrfs. When you have 100 drives adding or removing 10 at a time probably isn't a big deal, but when you 4 drives having to first add 5 drives and then remove the previous 4 seems almost comical. It just has to do with the original goals of the two filesystems. Oh, I've heard that zfs is ram-hungry, and many of its advocates suggest it should only be used with ECC RAM. Honestly, I've never seen an argument for ECC on zfs that wouldn't apply equally to any other filesystem, but whatever. I haven't found btrfs to be terribly RAM hungry, but I have found that it doesn't seem to do a good job with IO scheduling classes (though I have no idea how zfs does on this front). Btrfs at least seems to accept too many writes into its queue and then everything backlogs with getting it all out to disk, resulting in processes that should be low-priority blocking writes even on processes marked as realtime. I suspect that this is just the whole bufferbloat phenomena in another context. I'm not really sure what the "conservative" recommendation. Ext4 (or even ext3) is the obvious one, but both zfs and btrfs have checksumming of all data written to disk which is a huge data security improvement. That is a compelling feature that should give even conservative sysadmins pause before just rejecting them, unless they're mitigating silent corruptions in some other way. -- Rich
