Slashdot Mirror
Ubuntu Plans To Make ZFS File-System Support Standard On Linux
An anonymous reader writes: Canonical's Mark Shuttleworth revealed today that they're planning to make ZFS standard on Ubuntu. They are planning to include ZFS file-system as "standard in due course," but no details were revealed beyond that. However, ZFS On Linux contributor Richard Yao has said they do plan on including it in their kernel for 16.04 LTS and the GPL vs. CDDL license worries aren't actually a problem. Many Linux users have been wanting ZFS on Linux, but aside from the out of tree module there hasn't been any luck in including it in the mainline kernel or with tier-one Linux distributions due to license differences.
I run ZFS on any / every machine I can, server or not. That is one filesystem where the features outweigh all possible concerns.
If it's in you sig, it's in your post.
So how are they doing this without license conflict? Are they doing a clean-room implementation of ZFS?
Hell, it's already in many cases a superior experience on Linux, starting with that you can shrink a BTFS volume but you still can't shrink a ZFS volume. I suppose in the enterprise-centric world that ZFS is aimed at that's pretty much never an issue, but I've even run into it personally multiple times myself working for a small business and have been glad that I was running BTRFS instead. Frankly, for many use-cases it seems like running ZFS on Linux is more hassle for the sake of then more hassle later on.
I remember sigs. Oh, a simpler time!
Because BTRFS is and has always been redundant? ZFS is far more mature, and stories abound of BTRFS failing on people. BTRFS is still unstable, particularly their RAID5/6 support. Developers should be putting their efforts into ZFS instead of BTRFS.
I don't why so many in the Linux community are so hooked on ZFS. BTRFS has a feature set that is rapidly getting there, its becoming more a more mature in terms of code that is already in the upstream.
Why not just put your energy there?
As someone who uses both zfs (for file server storage) and btrfs (for the OS), my reason for using zfs is raidz. If btrfs implemented something similar, I'd drop zfs.
Warning: Opinions known to be heavily biased.
I've been using ZFS on Linux for about 3.5 years now, it's been pretty stable. I can't say I've heard of a case of it failing for somebody other than user error.
Because there's really no comparison between btrfs and ZFS. ZFS is years ahead in both stability and features. Only someone who's never used both would say that they are in any way close.
The only really useful thing that btrfs does that ZFS does not is rebalancing - that's a great feature and i'd love to see it in ZFS (but it will probably never get there).
ZFS has lots of features that btrfs doesn't have and likely never will.
You mean the recordsize. You can adjust that easily on ZFS:
http://open-zfs.org/wiki/Performance_tuning#Dataset_recordsize
There is even explicit documentation for running databases on ZFS:
http://open-zfs.org/wiki/Performance_tuning#Database_workloads
13.1% of the code changed between 0.6.4 and 0.6.5:
http://fossies.org/diffs/zfs/0.6.4_vs_0.6.5/index.html
That is far from being frozen. Even Linux does not have that percentage of its code change between releases:
http://fossies.org/diffs/linux/4.2_vs_4.3-rc1/
It would be interesting if someone checked out much fs/btrfs changes between releases.
Likewise; we use it all over the place in our department. We have a bunch of 96TB/80TB usable ZFS file servers based on 24 4TB SATA drives. The performance is amazing for the price and they are rock solid under all kinds of heavy load, except for one tiny bug we hit recently that has been fixed already.
BTRFS is the SystemD of filesystems. Lots of features, poor design. Features can be great, but they come at a cost. To summarize the issues with BTRFS, is it violates the principle of least surprise, which can result in some completely unexpected gotchas. The other thing is it is not truly transactional/atomic. By design, it requires fsck, which means the filesystem can be left in an inconsistent state. This opens the doors for a host of issues that ZFS is guaranteed to never have.
Not to mention, there are still plenty of people complaining about it eating their data.
I recently "fixed" one of our ZFS fileservers at work which was performing very poorly by *removing* a failing drive. The drive was taking a few seconds to read blocks, obviously dying, so it was slowing down the entire system. As soon as I pulled it ZFS finally declared it dead and the filesystem was running at full performance again.
I felt so confident being able to just walk up and yank the troublesome drive; that's how much trust I've built in ZFS. It's incredibly stable and fault tolerant.