HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
openzfs
zfs
C2013–2026
openzfs / zfs

zfs

OpenZFS on Linux and FreeBSD

Systems & Infrastructure
Explore on GitHubRead Hacker News discussions
226Distinct people
423Mentions
4Explicit recommenders
12.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

OpenZFS on Linux and FreeBSD

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I will soon prepare some scripts to do that, but I first want to confirm the core ideas and design something that I will only have to do once, and the discussion on…

csdvrx used a recommendation phrase. 4 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:28:18 AM UTC.

Mentions over time

HN mentions by year423 dated mentions

Observed mentions: 2013-03-29 20:43:14 UTC to 2026-10-12 18:23:23 UTC.

0204060802013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 17 mentions; 0 submissions, 17 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 25 mentions; 3 submissions, 22 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 32 mentions; 4 submissions, 28 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 29 mentions; 9 submissions, 20 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 50 mentions; 14 submissions, 36 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 29 mentions; 8 submissions, 21 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 31 mentions; 3 submissions, 28 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 86 mentions; 13 submissions, 73 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 40 mentions; 6 submissions, 34 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 59 mentions; 7 submissions, 52 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 10 mentions; 3 submissions, 7 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC202
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC17017
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC321
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC25322
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC32428
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC1028
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC29920
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC501436
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC29821
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC31328
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC861373
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC40634
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC59752
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC1037

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
OpenZFS is an advanced file system and volume manager which was originally developed for Solaris and is now maintained by the OpenZFS community. This repository contains the code for running OpenZFS on Linux and FreeBSD. Official Resources Documentation - for using and developing this repo ZoL site - Linux release info & links Mailing lists OpenZFS site - for conference videos and info on other platforms (illumos, OSX, Windows, etc) Installation Full documentation for installing OpenZFS on your favorite operating system can be found at the Getting Started Page. Contribute & Develop We have a separate document with contribution guidelines. We have a Code of Conduct. Release OpenZFS is released under a CDDL license. For more details see the NOTICE, LICENSE and COPYRIGHT files; UCRL-CODE-235197 Supported Kernels and Distributions Linux Given the wide variety of Linux environments, we prioritize development and testing on stable, supported kernels and distributions. Kernel (kernel.org) All longterm kernels from kernel.org are supported. stable kernels are usually supported in the next OpenZFS release. Supported longterm kernels: 6.18, 6.12, 6.6, 6.1, 5.15, 5.10. Red Hat Enterprise Linux (RHEL) All RHEL (and compatible systems: AlmaLinux OS, Rocky Linux, etc) on the full or maintenance support tracks are supported. Supported RHEL releases: 8.10, 9.7, 10.1. Ubuntu All Ubuntu LTS releases are supported. Supported Ubuntu releases: 26.04 “Resolute”, 24.04 “Noble”, 22.04 “Jammy”. Debian All Debian stable and LTS releases are supported. Supported Debian releases: 13 “Trixie”, 12 “Bookworm”, 11 “Bullseye”. Other Distributions Generally, if a distribution is following an LTS kernel, it should work well with OpenZFS. FreeBSD All FreeBSD releases receiving security support are supported by OpenZFS. Supported FreeBSD releases: 15.1, 14.4.
Read the full README on GitHub

What Hacker News says

32 sources
yourapostasy·Oct 1, 2017
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...
In How to Use the ZFS Filesystem on Ubuntu Linux
pmarreck·Oct 1, 2017
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-...
In How to Use the ZFS Filesystem on Ubuntu Linux
raattgift·Aug 6, 2017
That was strictly speaking an openzfs bug that hit all the ports. There's another one, somewhat related: https://github.com/zfsonlinux/zfs/issues/6224 which (so far) seems tied to using recordsize > 128k without either of the -L or -c flags on the zfs send side, with the result that the sendstream is corrupted in such a way that the receiver cannot detect the corruption. As with the filled-holes problem, the problem is real but rare. Unlike the filled-holes problem, it is unlikely to affect many people since it is (probably) very rare that anyone uses large records and does not use -L (or -c, or both), although there are certainly automatic snapshot-send systems (e.g. znapzend) that use a common minimal set of options to zfs send. This is especially unfortunate because of the rarity of the corruptions, the apparent rarity of people u
Read the rest
sing POSIX-layer checksumming (e.g. rsync -c, or sha256deep or the like) on large datasets (with large files that had holes made and refilled, for example) to validate that a received dataset really is the same as the original, and the apparent rarity of people doing this sort of validation specifically targetting backwards compatibility mechanisms (e.g. zfs recv into a version 28 or earlier pool from a source dataset that uses all the most recent bells and whistles). Finally, it is extra-especially unfortunate because recovering from this sort of corruption is awkward and time-consuming; at the minimum the source and destination have to be entirely read at least once or alternatively the destination needs to be destroyed and sent again from scratch once the fix or workaround for send|recv corruptions is known.
In 832 TB – ZFS on Linux
e12e·Aug 2, 2017
This stackoverflow question have some good points (notably, the accepted answer, and the bit about limitations - the CDDL section 6.2, for example revokes the CDDL in case of patent infringement, something that might be considered an "extra limitation" under the GPL (you're not allowed to add additional limitations to either the GPL or the CDDL). As such, the CDDL might be incompatible with the GPL up to and including v2 - while GPL3 might also be incompatible with the CDDL): https://opensource.stackexchange.com/questions/2094/are-cddl... https://github.com/zfsonlinux/zfs/blob/master/OPENSOLARIS.LI... Also, the SO answer mentions consumer protection laws - but AFAIK they generally only apply to consumers - not businesses. So the GPL 0 clause might be void in many jurisdictions for individuals but still valid for businesses.
In ⁠Btrfs has been deprecated in RHEL
cyphar·Jul 27, 2017
I'm going to repeat this again. It's got nothing to do with copyright assignment. The license that the code is under (CDDL), by default, allows Oracle to provide newer versions that anyone can update their copy of the code to. It's effectively the same mechanism as MPL's update system, and also effectively the same as GPL's update mechanism. You can take a GPLv2-or-later codebase and redistribute it as GPLv3-or-later because the FSF has released GPLv3. Similarly, you can take a CDDL-1.0 codebase and redistribute it as CDDL-2.0 because the "or any later version" clause is implicit and opt-out. If you agree that GPLv2-or-later code (regardless of who owns the copyright) can be redistributed or combined with GPLv3-or-later code, then you agree with the basic point of what I'm saying. Obviously the specifics are different but the basic idea i
Read the rest
s the same. Seriously. Read section 4 of the CDDL[1]. It's only three short paragraphs. [1]: https://github.com/zfsonlinux/zfs/blob/master/OPENSOLARIS.LI...
In GPL Violations Related to Combining ZFS and Linux (2016)

Showing the 15 most recent of 32 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.