The State of ZFS On Linux

An anonymous reader writes: Richard Yao, one of the most prolific contributors to the ZFSOnLinux project, has put up a post explaining why he thinks the filesystem is definitely production-ready. He says, "ZFS provides strong guarantees for the integrity of [data] from the moment that fsync() returns on a file, an operation on a synchronous file handle is returned or dirty writeback occurs (by default every 5 seconds). These guarantees are enabled by ZFS' disk format, which places all data into a Merkle tree that stores 256-bit checksums and is changed atomically via a two-stage transaction commit.. ... Sharing a common code base with other Open ZFS platforms has given ZFS on Linux the opportunity to rapidly implement features available on other Open ZFS platforms. At present, Illumos is the reference platform in the Open ZFS community and despite its ZFS driver having hundreds of features, ZoL is only behind on about 18 of them."

Comments

Re:License mismatch

[jedidiah]

The GPL only hates Mad Max post apocalyptic style "freedom".

The FSF rightfully understands that the complete absence of the rule of law simply enables the person with the biggest pile of guns to control things.

Sun seemed like a benign enough master but Oracle far less so.

Re:License mismatch

[Anrego]

They are strongly against one set of freedoms in support of the subset of freedoms they deem more important.

Which is fine, but I've always found their choice in terminology and strong focus around the word "free" to be annoying. Consequently I try to avoid using the term "free software" and instead usually opt for "open source", which while it doesn't convey the idea that it's restrictively licensed to ensure it and any derivatives remain open source, it also doesn't falsely convey that it is entirely free (as in do whatever you want with it free of restrictions).

Re:rsync causes lockups?

[yup2000]

I've been using ZFS on linux for years with nightly backup jobs that rely on rsync. I've never had a problem.

Re:Unfamiliar

[mcrbids]

There are so many pros for ZFS that I don't even. Until you try it, you won't "get it" - it's more like trying to describe purple to a life long blind guy. But, I'd adjust your list to at least include:

Pros:
- Data integrity
- Effortless handling of failure scenarios (RAIDZ makes normal RAID look like a child's crayon drawing)
- Snapshots.
- Replication. Imagine being able to DD a drive partition without taking it offline, and with perfect data integrity.
- Clones. Imagine being able to remount an rsync backup from last tuesday, and make changes to it, in seconds, without affecting your backup?
- Scrub. Do an fsck mid-day without affecting any end users. Not only "fix" errors, but actually guarantee the accuracy of the "fix" so that no data is lost or corrupted.
- Expandable. Add capacity at any time with no downtime. Replace every disk in your array with no downtime, and it can automatically use the extra space.
- Redundancy, even on a single device! Can't provide multiple disks, but want to defend against having a block failure corrupting your data?
- Flexible. Imagine having several partitions in your array, and be able to resize them at any time. In seconds. Or, don't bother to specify a size and have each partition use whatever space they need.
- Native compression. Double your disk space, while (sometimes) improving performance! We compressed our database backup filesystem and not only do we see some 70% reduction in disk space usage, we saw a net reduction in system load as IO overhead was significantly reduced.
- Sharp cost savings. ZFS obviates the need for exotic RAID hardware to do all the above. It brings back the "Inexpensive" in RAID. (Remember: "Redundant Array of Inexpensive Disks"?)

Cons:
- CPU and RAM overhead comparable to Software RAID 5.
- Requires you to be competent and know how it operates, particularly when adding capacity to an existing pool.
- ECC RAM strongly recommended if using scrub.
- Strongly recommended for data partitions, YMMV for native O/S partitions. (EG: /)

Re:Unfamiliar

[MightyYar]

I would add to you "cons" list that it requires* ECC RAM, though you should probably be using that anyway.

* It's not technically a requirement, but you'll probably be sorry if you don't use it.