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.
Liar.
Show me this ZFS on windows.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
It was a joke :-)
ZFS is seriously cool in many ways, but you pay for that with some pretty significant RAM requirements for a file system driver. If I remember correctly, you need about 8GB of RAM to really make use of ZFS. I think it's great that they're including it with the distribution, but it wouldn't make sense to have this as the default file system. At least not until the average system out there is running with 16GB of RAM.
Alex, I'll take keybindings not used by Emacs for $400....
I use both.
And for the reference, theres a REALLY REALLY good chance that you've had phone calls that have traversed one of the ubuntu machines that aren't for serious environments.
The fact that you make such a retarded statement shows how utterly clueless you are about Linux. You're one of those guys who thinks distros are different from each other ... Just because Linux distros can't decide on where they want to put a given set of files and they all must use their own package manager that does the same thing as all the others ... doesn't actually make them different.
It makes them different to people who don't know how to be an admin, but can add users on their preferred OS can as such call themselves an admin.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Last time I looked... Ubuntu was the most popular Linux on AWS, not sure about OpenStack, but I got the impression it was doing well there as well. I think it's a bit harsh to say "It's not like anyone uses woobuntu in serious environments."
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.
Uber alles. Default in CentOs 7. Why ZFS? It's not like anyone uses woobuntu in serious environments.
Ubuntu is the biggest OS for enterprise cloud deployments in the world.
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
I was joking :-)
As far as I know, ZFS is the only file system that can deal with duplicating hard links appropriately. Say you have a backup pool that works with hard links, and you want a clone of that pool, very difficult with anything else.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
The NIC name change predates systemd by quite a bit and is unrelated - that change happened in udev IIRC.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Posting AC? Why?
Export a ZFS volume via iSCSI, mount it on a remote machine and install Windows on it. The ZFS machine can now snapshot and clone the Windows install at will!
To clarify this, the main advantage of (read-only) nullfs is patching/upgrading. COW doesn't help there, but with nullfs because they are all pointing at the same files, upgrading one upgrade them all.
This would work for very small updates (e.g.: where a library .so file is replaced).
- before the update, the container was pulling a library from the template
- after the update, the container is still pulling from the same location, and now the template provides the updated version.
For large scale upgrade, that touch many files, including files - like config files - that got changed in the container and thus reside in the nullfs' overlay directory.
These files won't get automatically updated. You'd be upgating the original copy in the template, but the container would still be pulling their own local copies from the overlay.
The only solution would be to either:
- do an rsync from the updated template to the container you want to update (and hope you won't override some container-specific modification in the process)
- or do a separate update within the container (and that is going to work as expected under most circumstances).
and then subsequently run a de-dup.
(Which, in case of overlays, would be removing any file from the overlay directories that is actually exactly the same as one in the updated template).
(And wich is simply using the de-dup tool of the CoW filesystem)
Beside, the whole point of container with CoW, is that they are very thin and very light, and thus really easy to quickly spin on the flight.
(think systemd's nspwan).
Thus, depending on the circumstances, you might be better off just respining a new container.
(Specially since systemd's is supposed to be stateless and completely transparent to spin).
And in that circumstance, there's a slight performance benefits of using snapshots instead of overlays:
- no overhead of the overlay mecanism (e.g.: everything stays in the BTRFS layer)
- CoW works at the extent level (only the sub part of giant file that diverged gets writen) wheseas most overlays I know of work at the file level (a whole new copy of the file gets written).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Diff AC here.
When I weigh the evidence, I have to put far more trust in the anti-systemd comments presenting real technical arguments, and no trust at all into the pro-systemd comments filled with insults, vitriol, and sometimes even gibberish.
I'm not exactly sure where you're getting this from. The "real technical arguments" are all lies (you can use syslogd with systemd, you can configure systemd to not use binary logs at all, there's still STDERR). Saying so is not "insults, vitriol," or "gibberish." Maybe if you actually tried it, you'd see so.
N.B. I'm not "pro-systemd" by any measure, it's just another set of tools I use, no different from the classic Unix utilities or X.org and what not. It's much more similar to launchd used in OS X than SysVinit was, so you'd likely feel right at home.
I've also found JFS to work best for me on a MythTV box. Aside from the file deletion issue, there's also streaming throughput during recording (especially if the storage is accessed via NFS). As much of a ZFS fan as I may be, I prefer using the best tool for the job, and MythTV is where JFS shines.
Oh, no! You have walked into the slavering fangs of a lurking grue!
I, for one, would absolutely love to have official ZFS modules in CentOS instead of relying on DKMS. DKMS on a CentOS box is a nightmare, because of the "weak-updates" shortcut that it likes to take (where it symlinks the modules from a previous kernel into /lib/modules/foo/weak-updates instead of, you know, actually rebuilding the modules). Sure, that's nice and fast, but it falls apart horribly once that old kernel gets deleted.
Oh, no! You have walked into the slavering fangs of a lurking grue!
While true, many (all?) distros let udev screw with interface names, most of them leave the name eth# and remember which was which by MAC. Most important here is how simply an admin could turn that crap off. systemD doesn't use "eth" anymore, and the formerly simple methods of stopping this (lock a file, remove a script, etc.) are no longer that simple. Is it the end of the world, no. But it is still a needless pain in the ass.
I found something a while back that seems to work:
cp /bin/true /bin/true.bak /usr/sbin/weak-modules /usr/sbin/weak-modules.NONONONONO /bin/true /usr/sbin/weak-modules
mv
ln -s
Oh, no! You have walked into the slavering fangs of a lurking grue!