ZFS on Linux

by
in linux on (#2SAR)
Richard Yao has written a provocative piece detailing the state of the ZFS filesytem on Linux. It's made the rounds on other sites, where it's generating a lot of buzz. The reason is twofold: (1) ZFS is such a phenomenal piece of software, and (2) Yao insists the ZFSonLinux project (ZoL) is ready for primetime.
Linux users familiar with other filesystems or ZFS users from other platforms will often ask whether ZFS on Linux (ZoL) is "stable". The short answer is yes, depending on your definition of stable. The term stable itself is somewhat ambiguous. While one would think that stable means "ready for production use", that can mean that it does not lose data, that it does not crash, that it is a drop-in replacement for an existing filesystem, that changes to the disk format are forward compatible, that updates are always flawless or some combination thereof. Consequently, the long answer is much more nuanced than a single word can express. ...
He continues: I believe ZoL is production ready for the following reasons:
  1. Key ZFS data integrity features work on Linux like they do on other platforms.
  2. ZFS runtime stability on Linux is comparable to other filesystems, with certain exceptions that I document below.
  3. ZoL is at near feature parity with ZFS on other platforms.
Read on for the rest.
Reply 12 comments

What about her face? (Score: 2, Insightful)

by fishybell@pipedot.org on 2014-09-12 16:45 (#2SBA)

I always thought btrfs was the answer (also brought to you by Sun) for the same feature-set as ZFS, but in a linuxy way.

I hail all progress made on this front. I dinked around with running a failover ZFS before, and I can say it is pretty awesome stuff (as is btrfs).

Competition in the filesystem field is slow going (as it should be), but fierce. That's the ways I's likes it.

Re: What about her face? (Score: 1)

by fishybell@pipedot.org on 2014-09-12 16:47 (#2SBC)

...erm...my mistake...Sun had nothing to do with btrfs. I misread the wiki article many moons ago.

Re: What about her face? (Score: 1, Interesting)

by Anonymous Coward on 2014-09-12 18:43 (#2SBP)

btrfs doesn't have anywhere near the same featureset as ZFS. Here's a few examples:
ZVOLs for virtual machines. I extensively run VMs under Linux, they all need a block device(ideal) for their disk IO performance. ZVOL
is perfect, add in easy ZFS replication and I can back up virtual machines every day offsite, with absolutely no service interruption. BTRFS
is ages behind in this category.

The 'linuxey' syntax of btrfs is cute and all..but exactly why are my snapshots mounted, and read-write? I keep A LOT of snapshots, and having my mount tab polluted by thousands of entries not to mention users being able to write to the things?

Also I found the syntax of ZFS completely intuitive. tank/movies is my movies filesystem, tank/movies@20140701 is my 2014-07-01 snapshot of movies. All commands reference snapshots as a clear subcategory of it's parent filesystem. If I -r recursively remove a snapshot, I can take out a bunch of depending snapshots wihtout screwing around with them individually.

In short, ZFS naturally seems to work like I do... In my opinion BTRFS should mimic the syntax instead of going it's own way, and differentiate in the implementaiton.

Re: What about her face? (Score: 1)

by fishybell@pipedot.org on 2014-09-12 18:50 (#2SBR)

Because ZFS does those things, btrfs will have to add them, or die (well, receive less marketshare). Woo competition! I win! You win! We all win!

I 100% agree with you on the snapshots and syntax thing though.

Re: What about her face? (Score: 1)

by entropy@pipedot.org on 2014-09-12 19:14 (#2SBT)

So this isn't completely abstract, here are a couple examples:

BTR: btrfs subvolume snapshot /tank/subvolume /tank/snapshots/subvolume/20140721 ... 75 characters
ZFS: zfs snapshot tank/subvolume@20140721 ... 36 characters.

Plus you have to maintain a separate directory to manage snapshots... As snapshots grow to hundreds, or thousands your mount screen becomes a worthless jumble of crap. Fundamentally snapshots are treated as peers with filesystems in btrfs, and I believe this is absolutely incorrect. Also apparently not only are a bunch of things required to be mounted(subvolumes) BTRFS pretends it can't figure out how to mount a full volume without playing around in fstab for each things I create. In short it mounts what I don't want mounted, and doesn't mount what I do.

Compression?
BTR: you go into fstab, which is apparently mandatory(really?) and set compress=lzo.
ZFS: zfs set compression=on tank/textfiles

For a use case involving ZVOLs(block devices) it's very simple, in ZFS it's possible:
zfs create -V 20G tank/vm/pgserver0
In BTR? It's impossible. You're dealing with files in a filesystem which if you've ever benchmarked is tragically underpowered. Personally I think this is the first thing BTRFS should have implemented but perhaps not as many people use VMs or iSCSI? To me those are critically important.

Re: What about her face? (Score: 0)

by Anonymous Coward on 2014-09-12 19:34 (#2SBV)

AC and entropy, thanks so much! I haven't used either file system but that seems like very good info to have. I wonder if either of them are doable on a VPS? Last time I tried something like that I needed FUSE to be enabled by the host.

Re: What about her face? (Score: 1)

by entropy@pipedot.org on 2014-09-13 01:45 (#2SC3)

zfsonlinux.. The "actual" ZFS Linux implementation requires a kernel module. There's a more widely distributed FUSE module, but that one is buggy, and I don't recommend it's use. Check out zfsonlinux.org they should have install instructions for your flavor of Linux. For instance: Ubuntu PPA. It went extremely smoothly for me.

Story Missing? (Score: 0)

by Anonymous Coward on 2014-09-12 16:46 (#2SBB)

Sorry this is off topic, but the AntRadio story below seems to have a bad link now?

I can still get to the story with

http://pipedot.org/story/2014-09-12/stanford-engineer-aims-to-connect-the-world-with-antsized-radios

but the current front page points to
http://pipedot.org/story/2014-09-12/stanford-engineer-aims-to-connect-the-world-with-ant-sized-radios

which results in

"story not found - date [2014-09-12] title [stanford-engineer-aims-to-connect-the-world-with-ant-sized-radios]

Back on topic, I'm happy to know that ZFS is finally getting there, but is there any reason I wouldn't use BTRFS instead?

Re: Story Missing? (Score: 0)

by Anonymous Coward on 2014-09-12 16:53 (#2SBD)

those damn hyphens will be the death of us all...

Re: Story Missing? (Score: 1)

by bryan@pipedot.org on 2014-09-13 12:04 (#2SCC)

Small bug when I added "-" to the list of allowed characters in a URL for a title. Should be fixed now.

Re: Story Missing? (Score: 1)

by fnj@pipedot.org on 2014-09-13 09:58 (#2SCA)

The question makes no sense. The question you should be asking is "is there any reason to prefer btrfs", and the answer is, at this time, no. ZFS is not "getting there", it is THERE. Has been for a while. Super stable. btrfs is still very much in development. A very slow development.

If you really, really, really must insist on the question as framed, here are some reasons:
* I do not believe btrfs has as yet any counterpart to raidz, raidz2, or raidz3
* snapshots are handled in a very clumsy manner in btrfs, and very succinctly in ZFS
* ZFS has no fsck because by design it doesn't need one. btrfs needs fsck and has only a limited version as yet.
* ZFS filesets are much more versatile than btrfs subvolumes.
* Creation and destruction of ZFS filesets is essentially instantaneous. As I remember it, btrfs like ext2/3/4, etc, is emphatically not.
* Many, many more reasons.

Re: Story Missing? (Score: 1)

by scotch@pipedot.org on 2014-09-14 14:19 (#2SCT)

What about CEPH on btrfs versus CEPH on ZFS ? Does anyone have some clue baout that? I would be _verY_ interseted about this one topic but never cross any reading about the later...