How to Use the ZFS Filesystem on Ubuntu Linux | Hacker News Reader

How to Use the ZFS Filesystem on Ubuntu Linux

maketecheasier.com

34 pointsrayascott26 comments

Will there be a time when ZFS is the defacto standard on Linux or is it only suited to specific use cases?

I too would like to know the answer to this.

I think ZFS for a long time (if not still) has some... patent issues associated with it which could be problematic in an open-source context.

I think BTRFS was (or is still) trying to fill this niche (and is open-source), but the perception is that it is not 100% reliable, and unfortunately, a first-class filesystem kind of has to be.

Here's a guide on how to use ZFS as the root filesystem on Ubuntu: https://github.com/zfsonlinux/zfs/wiki/Ubuntu-16.10-Root-on-...

I personally dont think it will because most systems still only have one main drive and ZFS really shines best with multiple disks. I think something more like Apples new file system is more likely but im basing this off of gut alone

The more drives the better, obviously, but ZFS has advantages even for single-disk pools (e.g. checksumming).

What good is checksumming with no parity? You’re just losing capacity for no reason since drives already have bad sector protection

Other two to watch out for are Hammer2 (https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEA...) and bcachefs (http://bcachefs.org/), but both will take a while before being available in a standard distro. Hammer is only in bsd for now, so would need a big port. bcachefs is making slow progress in linux - maybe in a year or two.

I don't think ZFS has patent issues, I think the issue is that it has a BSD-like license, and it's too free for the linux people. BTRFS just isn't good enough. I'm waiting for bcachefs.

I don't know where you got that impression, but it is not at all accurate: the issue is that ZFS is licensed under the CDDLv1, which some key players (but clearly not all; it is not even clear if it is a majority, but I don't know if the people claiming it isn't are motivated to do so) believe to be incompatible with the GPLv2.

https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-lin...

vs.

https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

I think that as long as ZFS is licensed under CDDL [1], it will never be part of the Linux kernel proper. However, I'm not aware of any factor that prevents a distribution from selecting ZFS as the default filesystem [2]. Perhaps it forces forking rescue disks onto a different, simpler filesystem type, which would add work for the distributions, but I can't think of a good list of drawbacks off the top of my head.

It would be awesome if someone from one of the big distributions chimed in why ZFS is passed over, from their perspective, and perhaps the ZoL project might be able to help address their concerns.

[1] https://github.com/zfsonlinux/zfs/wiki/FAQ#licensing

[2] http://warpmech.com/?news=myth-busting-series-zfs-on-linux-h...

Yeah, Linux is never going to merge something CDDL into the mainline short of people achieving porcine aviation.

Among other things, booting from ZFS on Linux can still be an experience with rough edges - I think one distro makes it easy to do from the installer (Slackware?), but otherwise you get to follow instructions which are opaque to someone not already familiar with running Linux, and debugging can be weird even if you are (the most common thing I've seen is the initramfs failing to import the pool and dropping to a rescue prompt, then succeeding at importing there - for a variety of reasons, usually not "the disks weren't spun up yet when it tried importing" any more).

There's also the caveat that frequently ZFS gains feature flag support faster than GRUB2 gets updated to boot from those features, particularly since you can't just shove CDDL code into GRUB2, so you get to reimplement the wheel, and zpool upgrade/zpool set doesn't currently warn you that you're gonna make your pool unbootable if you turn on those features.

I'm not a distro maintainer or anything of the sort, but between the above rough edges and concerns about redistributability of CDDL modules compiled against the Linux kernel and patents, I'm not surprised that people shy away from it unless $BIG_CUSTOMER throws a lot of money at them to make it a first-class citizen.

(I'm also really curious, consequently, why Canonical is diving headfirst onto the wagon...)

> (I'm also really curious, consequently, why Canonical is diving headfirst onto the wagon...)

I think it's a combination of being fans of ZFS and needing something to differentiate them from Red Hat.

ZFS as such will probably never make it (CDDL/GPL incompatibility - unless Oracle will relicense it).

But what _could_ make it is a reverse-engineered "GPLed" ZFS (and, being that OpenZFS code is available, it shouldn't be that hard for a largeish team - someone just has to audit the code to make sure nothing slips through). The other big issue is patents (meaning that this "GPLed ZFS" will be subject to patent lawsuits).

But: 1. Not all countries have software patents. 2. Most patents should expire within a decade (I think. I didn't do a lot of research, but the earliest lawsuits I found were around 2006?)

I don't think so, xfs is looking pretty good as a general purpose alternative to ext4 and there's no real reason to throw your average user on something more complicated.

I'd love to see a modern filesystem comparison featuring etx4, zfs, xfs, btrfs, hammer2, etc. Anybody know of a good resource for this?

One interesting use case for zfs is striping eg you add a bunch of left over disks with different speeds and sizes to a zfs pool, then zfs automatically optimize. It can be used on for example dev machines where everything lives in repositories and all you care for is getting as much performance and storage out of the disks as possible. For serious use you should always use zfs with two or three-way mirrors. If the disks have different sizes you can make partitions, then add the partitions instead of the whole disks to zfs. zfs software raid is very popular but really the poor mans choice, and will not give you any benefit over hardware raid, so always use mirrors !! My current setup is ZOL with 4 ssds in stripe and 2 hhds in mirror. Yep if one of those ssds dies I'll lose all my data, but this gives me GB r/w speeds and over a TB of total storage for very cheap.

> ...zfs software raid ... will not give you any benefit over hardware raid...

Except that you can pull the disks, stick them in another machine, import the pool, and immediately have access to your data -- as well as, in the case of a failed RAID controller, not having to worry about finding a spare, working, replacement card of the exact same type (which isn't an uncommon occurrence).

And having the exact same raid firmware (yes this has has hit me in the past), crap like this is why I never use hardware raid.

Call me crazy, but at work I'd love to have the snapshot capability. I mostly run linux in a VM. Usually we use Exceed on Demand and operate remotely, but the satellite office I'm in has terrible internet.

So I run locally. And I have thought about running with ZFS and exporting it through an SMB share. I realize I wouldn't really be getting much of the safety benefit (beyond checksumming I guess), but being able to snapshot would be lovely.

I keep an external backup, and I use git on windows for manually snapshotting, but it's still a bit of a pain, and to be able to snap the whole filesystem seems awesome.

I have 32 gigs of ram, and give half to the VM... Any opinions on this idea?

To clarify a little, half my work happens in windows due to using office and outlook extensively. And before anyone suggests open office type options, just don't. For the size and complexity of our documents, it's just not feasible.

You might want to read about NTFS's Volume Shadow Copy functionality, or I believe there's glue code so that you can expose ZFS snapshots on datasets when they're shared over CIFS, but I haven't tried that in a long time.

Heres an article on how to create snapshots with ZFS

http://docs.oracle.com/cd/E19253-01/819-5461/gbcya/index.htm...

Why not invert? Run linux as the main system and office + outlook in the VM. There are some pretty good seamless solutions for window display as well. (vbox, vmware)

Then you can have everything on ZFS and you can keep the whole windows disk as a separate volume. Snapshoting both should be trivial in that case.

I'd get dinged for putting an unauthorized computer on the network. with linux in the VM I can masquerade. I'd love to do the reverse though, windows on my laptop is maddening. 7 minute boot times.

I'm not sure what you're referring to, but any network changed you can do on windows, I'm pretty sure you can replicate on Linux. (TTL fixes included)

> I realize I wouldn't really be getting much of the safety benefit ...

You'd get volume shadow copies and your users would get the ability to rollback files on their own.

I have a large media collection ranging on the order of 10TB collected over many years. One day I started noticing that videos i havent watched in a while would occasionally have these weird green artifacts during playback that didnt exist when I first stored them.

My research lead me to discover what bit-rot was and how most filesystems dont actually ensure that what was read from disk is precisely what was written to it.

Enter ZFS, an incredible filesystem that makes ensuring data integrity a breeze. I run 12x2TB disks in a raidz2 running bi-monthly scrubs and not a single corrupted byte since

Reply on news.ycombinator.com