Slashdot Mirror
Ubuntu 16.04 LTS To Have Official Support For ZFS File System (dustinkirkland.com)
LichtSpektren writes: Ubuntu developer Dustin Kirkland has posted on his blog that Canonical plans to officially support the ZFS file system for the next Ubuntu LTS release, 16.04 "Xenial Xerus." The file system, which originates in Solaris UNIX, is renowned for its feature set (Kirkland touts "snapshots, copy-on-write cloning, continuous integrity checking against data corruption, automatic repair, efficient data compression") and its stability. "You'll find zfs.ko automatically built and installed on your Ubuntu systems. No more DKMS-built modules!" N.B. ext4 will still be the default file system due to the unresolved licensing conflict between Linux's GPLv2 and ZFS's CDDL.
More precisely, the blog bost is about using ZFS' copy-on-write (CoW) capabilities in the context of linux containers.
(thin virtualized machines. The guest share the same kernel as the host, but the userspace is separated and compartmentalized using the kernel's cgroup feature.
Similar to BSD Jails and Solaris containers.
Think like a chroot, except extented to all the other concepts beside file system).
The fast and easy snapshoting that come with CoW filesystems like ZFS (or BTRFS for that matters) makes it very easy to spin new virtualized containers simply by snapshoting the subtree holding the empty template, while wasting only minimal resource (only the differences are stored as the two copies diverge over time).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
It's a promising fs, but is not very stable now: I've tried BTRFS in a netbook (with Arch): it corrupted a micro-SD disk so many times that I've gived up and used ext4 (from it: a never have considered to use BTRFS in production systems yet like I do with ZFS])
Liar.
Show me this ZFS on windows.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I think you don't know what ZFS really is. It's a very different deal than etx4, ufs etc... It is the file system that made HW raid controllers obsolete. Even with a single disk setup you get a lot of features that you don't have on most of the other FS. It is a big deal just because of cheap snapshots, and data integrity checks.
And no, BTRFS is not even close... yet.
I'll stick with BTRFS thanks. It gives me all those features, is GPL and has been trouble free for me on many TB of disks for several years.
Encryption? Oh yeah:
Btrfs does not support native file encryption (yet), and there's nobody actively working on it. It could conceivably be added in the future.
"Nobody actively working on it" is a big problem with BTRFS.
BTRFS comes from Oracle - pre-Sun purchase. It was Oracle's answer to ZFS. And now Oracle owns ZFS and doesn't need a copy of the original. It's not quite abandonware, but the central impetus for it's creation and advancement is gone.
And most of all:
Is btrfs stable?
Short answer: Maybe.
Ouch. That's the official BTRFS wiki page.
As a die hard BTRFS user that chases kernel releases like a addict chases crack, I can't help but say that there are still some annoying issues out there.
While none have given me data loss, you'll get the occasional deadlock from a set of kthreads that do compression or a severe slowdown with next to no disk I/O and big WAITIO (usually get 16.xx Load in such cases on a quad core machine). For the slowdown case you'll get a speed drop from 150MB/s to 900~KB/s on spinning rust for a couple of minutes. Happens only after heavy use in the range of 2+TB written with forced compression.
ENOSPC? Not on my end. Trying to copy a file and running out of space results in WAITIO through the roof while BTRFS tries to find free space. I've had a job that stalled and thrashed the hard drive for 9 hours while it tried to recover space. At no point did it simply kill the transfer due to out of space, btrfs usage showed around 1GB of space left with plenty for metadata. It's at 1GB free for data extents and that's what kills the whole deal. You can't use that last 1GB, you'll just deadlock until some space is recovered by deleting files manually. Happens every time, just make sure to transfer something that is larger than the available free space and watch it suffer.
All this with Linux kernel 4.4.2. Looking at the various mailing lists with regular posts from people with obscure problems I've never encountered before, can't really say it's on par with ZFS stability. And ZFS On Linux is still missing a few things last I checked from the true ZFS implementation, but it's usable. Can't comment on ZOL long term stability, but I would feel comfortable enough using it instead of BTRFS for say a production server.
> I would be interested in knowing which is fastest at read/writes.
Ignoring the fact that this is a HIGHLY ambiguous question, i.e. you don't specify _which_ RAID setting, here are some benchmarks:
= 2010 =
http://www.zfsbuild.com/2010/0...
= 2013 =
ZFS On Linux 3.8 Kernel, ZOL 0.6.1
https://openbenchmarking.org/r...
= 2015 =
A PERFORMANCE COMPARISON OF ZFS AND BTRFS ON LINUX
* https://www.diva-portal.org/sm...
I used to use Ubuntu for my file server. Since the desktop motherboard didn't have a built-in video, I used an old Nvidia video card to configure the installation. Every time Ubuntu did an automatic upgrade of the video driver, it hosed the installation and I would have reinstall. I switched over to FreeNAS five years ago and haven't looked back. I've rebuilt my server box last year to meet the beefier hardware requirements for ZFS. Bad things will have if you run ZFS on less than adequate hardware.