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.
All file systems are approximately the same for most day to day users. I would be interested in knowing which is fastest at read/writes.
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.
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 ]
12.04 and 14.04 were kind of previous versions with updated programs, nice polished and updated drivers. But 16.04 will have exciting new stuff: privacy enabled by default, ZFS, new software centre, first LTS with systemd (yeap, mind that, I like it!) and kernel 4.
Every time I see news about ZFS and Linux, it's a little bit less of a mess. Eventually, I expect that all of the major distributions will go this route and sidestep the licensing issue by providing distro-supported modules that are installed by user request, sort of like the way that Nvidia drivers are provided.
I used the wrong tool for the job, therefore it sucks.
It's not quite abandonware, but the central impetus for it's creation and advancement is gone.
I wasn't planning to comment on this thread, but this is too big a lie to let stand -- unless by "not quite abaondonware" you mean "has absolutely nothing in common with abandonware besides being a type of software". Oracle was never the sole developer, and now that Oracle has lost interest, the developers just moved to other companies and kept doing the same thing. Its raison d'etre remains to provide an advanced filesystem that's easily integrated with linux, which for better or worse means being licensed under the GPL or something compatible.
As for encryption, yeah that would be nice to have, but it's not like zfs has all the features btrfs has. I'll take btrfs's online balancing (ability to add and remove drives at will) over built in encryption, but I realize that's a personal choice.
Finally, let's actually quote the FAQ correct only stability:
Short answer: Maybe.
Long answer: Nobody is going to magically stick a label on the btrfs code and say "yes, this is now stable and bug-free". Different people have different concepts of stability: a home user who wants to keep their ripped CDs on it will have a different requirement for stability than a large financial institution running their trading system on it. If you are concerned about stability in commercial production use, you should test btrfs on a testbed system under production workloads to see if it will do what you want of it. In any case, you should join the mailing list (and hang out in IRC) and read through problem reports and follow them to their conclusion to give yourself a good idea of the types of issues that come up, and the degree to which they can be dealt with. Whatever you do, we recommend keeping good, tested, off-system (and off-site) backups.
Pragmatic answer: (2012-12-19) Many of the developers and testers run btrfs as their primary filesystem for day-to-day usage, or with various forms of real data. With reliable hardware and up-to-date kernels, we see very few unrecoverable problems showing up. As always, keep backups, test them, and be prepared to use them.
For all practical purposes, btrfs is stable. Everything they say in the long answer basically applies to linux in general (unless you have a support contract with Red Hat or the likes).
Where's the lie?
Does systemd not replace the system log with a binary file that is unusable by every application that reads or writes to the system log?
No.
Does systemd not break the system administration tool chain?
No.
Does systemd not consume and discard STDERR making troubleshooting and debugging a masochist's delight?
No
Up until 14.04LTS everything dumps into /var/log/syslog, a standard text file. Beginning with 16.04LTS and thanks to systemd that is replaced by a binary file that is virtually inaccessible by everything else.
Run rsyslogd.
Won't bother with your boring crap about eth0. All my network interfaces have real names, which works with udev just like it used to.
Watch this Heartland Institute video
Do not, repeat DO NOT ENABLE DE-DUPE unless you have gargantuan amounts of RAM.
Rule of thumb is 5GB of RAM per 1TB of ZFS data: http://constantin.glez.de/blog...
If you ever enable dedupe on a pool, it's on forever. You can't actually turn off the extra RAM requirements since there *could* be de-duped blocks, and ZFS must check for those on every pool import. On a system with insufficient RAM, it's possible to end up with a pool that can take hours or days to import with no indication that it's actually still importing and not just dead.
Unless you have truly epic levels of duplication, it'll be cheaper to buy more disk to hold the extra copies than to buy enough RAM. (Also keeping in mind that with snapshots & copy-on-write clones, you essentially get dedupe of those blocks for "free" without enabling pool-wide dedupe.)
Why do you need the closed nvidia driver on a server? Nouveau should be fine or even just the vesa driver. (I could say why do you even need a video card on a server, but I guess some folk prefer that to using ssh or a serial connection from a laptop)
Also don't enable dedup if you have media with a nontrivial seek time. It's tolerable on flash (but you do lots of extra I/O on write) but the deduplication table (DDT) tends to develop a random layout with respect to device LBAs, and the DDT needs to be consulted on each write to a dataset/zvol with dedup enabled, and it also needs to be scanned *first* during scrubs and resilvers. DDTs with millions of entries can require hundreds of thousands of random I/Os, which means hundreds of thousands of seeks. At 10-30 ms/seek, you will have a bad time if you ever need to replace a disk in your pool, or scrub regularly.
Additionally, you have to update the DDT when you remove duplicates. When you remove a file from a deduplicated dataset: DDT consult. If DDT is not in memory, that means random I/O. When you remove a snapshot filled with data entered into the DDT: DDT consults for each record (128k, typically; sometimes smaller). Worse, asynchronous destruction of snapshots and datasets across a reboot boundary must be finished before the pool becomes available during the import process. And at the reboot, your ARC is empty and your L2ARC is unavailable before import, so each removed record is much more likely to result in a disk seek.
On SSDs, not so bad. On rotating media, deduplication can result in operational disasters -- I have personally seen pools take a WEEK to import after an unexpected restart during a "zfs destroy -R foo/bar" where bar has dedup=on.