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, 10:49:33 PM 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

40 sources
ryao·Dec 22, 2024
Thank you for posting your original comment. The process of writing my reply gave me a flash of inspiration: https://github.com/openzfs/zfs/pull/16896 I doubt that this will make us as fast as ext4 at unlinking files in a single thread, but it should narrow the gap somewhat. It also should make many other common operations slightly faster. I had looked into range lock overhead years ago, but when I saw the majority of time entering range locks was spent in an “unavoidable” memory allocation, I did not feel that making the operations outside the memory allocation faster would make much difference, so I put this down. I imagine many others profiling the code came to the same conclusion. Now that the memory allocation overhead will soon be gone, additional profiling might yield further improvements. :)
In Why we use our own hardware
ryao·Dec 22, 2024
Unlike ext4 that locks the directory when unlinking, ZFS is able to scale on parallel unlinking. In specific, ZFS has range locks that permit directory entries to be removed in parallel from the extendible hash trees that store them. While this is relatively slow for sequential workloads, it is fast on parallel workloads. If you want to delete a large directory subtree fast on ZFS, do the rm operations in parallel. For example, this will run faster on ZFS than a naive rm operation: find /path/to/subtree -name -type f | parallel -j250 rm -- rm -r /path/to/subtree A friend had this issue on spinning disks the other day. I suggested he do this and the remaining files were gone in seconds when at the rate his naive rm was running, it should have taken minutes. It is a shame that rm does not implement a parallel unlink option internally
Read the rest
(e.g. -j), which would be even faster, since it would eliminate the execve overhead and likely would eliminate some directory lookup overhead too, versus using find and parallel to run many rm processes. For something like fast mail that has many users, unlinking should be parallel already, so unlinking on ZFS will not be slow for them. By the way, that 80% figure has not been true for more than a decade. You are referring to the best fit allocator being used to minimize external fragmentation under low space conditions. The new figure is 96%. It is controlled by metaslab_df_free_pct in metaslab.c: https://github.com/openzfs/zfs/blob/zfs-2.2.0/module/zfs/met... Modification operations become slow when you are at/above 96% space filled, but that is to prevent even worse problems from happening. Note that my friend’s pool was below the 96% threshold when he was suffering from a slow rm -r. He just had a directory subtree with a large amount of directory entries he wanted to remove. For what it is worth, I am the ryao listed here and I was around when the 80% to 96% change was made: https://github.com/openzfs/zfs/graphs/contributors
In Why we use our own hardware
ryao·Dec 11, 2024
You can, but gcc may replace it with an equivalent set of instructions as a compiler optimization, so you would have no guarantee it is used unless you hack the compiler. On a related note, GCC optimizing away things is a problem for memset when zeroing buffers containing sensitive data, as GCC can often tell that the buffers are going to be freed and thus the write is deemed unnecessary. That is a security issue and has to be resolved by breaking the compiler’s optimization through a clever trick: https://github.com/openzfs/zfs/commit/d634d20d1be31dfa8cf06e... 12352 Similarly, GCC may delete a memcpy to a buffer about to be freed, although I have never observed that as you generally don’t do that in production code.
In Making memcpy(NULL, NULL, 0) well-defined
klarainc·Dec 2, 2024
Klara Inc | Fully Remote | Global | Full-time Contract Developer Klara Inc (klarasystems.com) provides development & solutions focused on open source software and the community-driven development of OpenZFS and FreeBSD. We develop new features, investigate/fix bugs, and support the community of these important open source infrastructure projects. Some of our recent work includes major ZFS features such as Linux Containers support (OpenZFS 2.2: https://github.com/openzfs/zfs/pull/12263), and Fast Deduplication (OpenZFS 2.3: https://github.com/openzfs/zfs/discussions/15896). We're looking for OpenZFS Developers (3+ years of experience) to join our team: - Strong skills with Kernel C programming and data structures - Experience with file systems, VFS, and related operating system concepts (threading, synchronization primitives/locking) - Awa
Read the rest
reness of ZFS (MOS, DMU, ZPL, pooled storage, datasets, vdevs, boot environments, etc) concepts. You can submit an application on our website: https://klarasystems.com/careers/openzfs-developer/ If you'd rather talk to us via e-mail, just drop us a line at joinus@klarasystems.com.
In Ask HN: Who is hiring? (December 2024)
ryao·Nov 21, 2024
_Pragma("GCC unroll 9") while (nelems > 1) { auto half = nelems / 2; nelems -= half; first += (comp(first[half - 1], value)) * half; } return first; As long as we are sharing improvements, here is mine. Microbenchmarking numerous variations found this performed the best. If your arrays are smaller than the unrolling factor, you don’t even loop. You have exactly 1 branch that is executed exactly once in that case. This is the closest to branch free that a binary search can be. I devised this a couple years ago for use in ZFS’ btree code: https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a... Feel to have it under your choice of OSI approved license, including CC-0.
In Fastest Branchless Binary Search
ryao·Nov 21, 2024
I implemented a variation of this in ZFS’ btree implementation a few years ago: https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a... It only works if the comparator is inlined, which is why I had to use a macro and duplicate the code everywhere. C++’s templates effectively do the same thing. By the way, I notice that C++ favors comparators returning a boolean while C favors comparators returning -1, 0 or 1. Let me share this simple macro from ZFS: #define TREE_CMP(a, b) (((a) > (b)) - ((a) < (b))) Use that to generate -1, 0 or 1. Then if you want a boolean, compare the output to < 0 to get the boolean that a C++ comparator would return and as long as the comparator is inlined, the compiler will automatically simplify, such that you get only 1 comparison. The C++ STL designers who opted for a boolean return value from comparator
Read the rest
s did premature optimization, since they had no reason to break with the C convention under C++’s "the compiler will inline and optimize" philosophy. The neat thing about the C way is that if you want to generate a boolean from the comparator, you have a choice for the boolean’s semantics (< 0 or <= 0) while C++ made that choice for you. That said, I have never needed the latter and as a much younger developer, I thought that the C++ way was superior, but time has caused me to conclude the C guys got this right. Finally, since I am on topic of comparators, there is a fairly famous example of how to generate -1, 0 or 1 when comparing against 0: https://www.cs.cornell.edu/courses/cs6120/2020fa/blog/super-... I only mention it since it is interesting and I like sharing interesting things. Reimplementing the signum function from there with TREE_CMP() does not generate code as good as the superoptimized example in godbolt: https://godbolt.org/z/1j8nWjnqP It is probably an optimization opportunity for GCC.
In Fastest Branchless Binary Search
magicalhippo·Oct 30, 2024
> and fixup the block pointers That's why. Due to reasons[1], ZFS does not have the capability to rewrite block pointers. It's been a long requested feature[2] as it would also allow for defragmentation. I've been thinking this could be solved using block pointer indirection, like virtual memory, at the cost of a bit of speed. But I'm by no means a ZFS developer, so there's surely something I'm missing. [1]: http://eworldproblems.mbaynton.com/posts/2014/zfs-block-poin... [2]: https://github.com/openzfs/zfs/issues/3582
In OpenZFS deduplication is good now and you shouldn't use it
amano-kenji·Oct 1, 2024Submission

ZFS native encryption is currently broken for encrypted backups

There are various issues on ZFS native encryption. ZFS native encryption has been especially buggy when raw encrypted zfs snapshots are being sent or received. https://github.com/openzfs/zfs/issues/11679 https://github.com/openzfs/zfs/issues/15989 https://github.com/openzfs/zfs/issues/15924 https://github.com/openzfs/zfs/labels/Component%3A%20Encryption https://www.reddit.com/r/zfs/comments/10n8fsn/does_openzfs_have_a_new_developer_fo… On https://github.com/openzfs/openzfs-docs/issues/494 people unanimously agree that zfs native encryption is broken especially when sending or receiving raw encrypted zfs snapshots, and they blame the zfs leadership for refusing to admit that zfs native encryption is buggy because admitting that it is buggy is bad for the reputation of zfs. zfs native encryption has been fine for local usage on
Read the rest
my machine, but I have never attempted to send raw encrypted zfs snapshots due to numerous warnings. Thus, I want to offer alternatives to zfs native encryption. 1. If your zfs pool is not large, LUKS is going to be faster than zfs native encryption. I don't know whether LUKS is going to be still faster if zfs pool contains many disks. ZFS native encryption can be as fast as LUKS or faster than LUKS, but it is not for now. 2. For making incremental encrypted backups, I recommend restic. Restic can make incremental encrypted snapshots of ZFS snapshots. You can delete any restic incremental snapshots without losing data in other snapshots. Restic 0.17 started supporting RESTIC_FEATURES=device-id-for-hardlinks which supports backing up $ZFS-MOUNTPOINT/.zfs/snapshot/$SNAPSHOT-NAME efficiently. Restic 0.18 will remove device-id-for-hardlinks feature flag and support .zfs/snapshot directories efficiently witout any feature flag. If you want to back up zfs dataset, you can take restic ZFS snapshot, back up .zfs/snapshot/restic as a new restic snapshot, and delete restic ZFS snapshot after backing it up. In this way, restic doesn't need to know about local sanoid ZFS snapshots which are independent from restic snapshots. Restic supports compression, encryption, and deduplication. Thus, you can send incremental encrypted backups to untrusted machines. For remote backups, you can use amazon cloud storage, https://rsync.net, https://zfs.rent, and other cloud storage services. I don't have any association with any of these services. I don't recommend any. Do your own research if you want to pick a cloud storage provider.
17 points · Open discussion
mrighele·Sep 27, 2024
> As soon as I've set up a file system with the drives I already have the only solution is to buy the same amount of drives with more space once I run out. Recent versions of zfs support raidz expansion [1], which let you add extra disks to a raidz1/2/3 pool. It has a number of limitations, for example you cannot change the type of pool (mirror to raidz1, raidz1 to raidz2 etc.) but if you plan to expand your pool one disk at a time it can be useful. Just remember that 1) old data will not take advantage of the extra disk until you copy it around and 2) the size of the pool is limited by the size of the smallest disk in the pool. [1] https://github.com/openzfs/zfs/pull/15022
In Why are my ZFS disks so noisy?

Showing the 15 most recent of 40 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.