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:01:16 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

29 sources
mastax·Dec 22, 2021
Trying to remember what I researched 6 months ago. 1. You don't want to use AIO on Linux because "the driver’s AIO implementation is a compatibility shim that just barely passes the POSIX standard"[0] and is bad for performance, at least in database-like applications that have an alternate threaded sync implementation. 2. You probably don't want to use O_DIRECT since it's currently implemented using a shim on top of AIO[1]. 3. `primarycache=metadata` + fsync + sync I/O works just fine for databases unless you have a very fast SSD array[2] in which case you'll have to wait for real O_DIRECT support[3]. [0]: https://openzfs.github.io/openzfs-docs/Performance%20and%20T... [1]: https://github.com/openzfs/zfs/pull/7823 [2]: https://github.com/openzfs/zfs/issues/8381 [3]: https://github.com/openzfs/zfs/pull/10018
In Everything I've seen on optimizing Postgres on ZFS
xoa·Nov 19, 2021
>It's said to be a good fit for ZFS. I tend to lz4 because its baked into the older systems I use, but it may be at a point where my default should be zstd. It is, and you should definitely at least give it a look. I posted a comment mentioning it the other day in the OpenZFS 2.0 thread [0], and it also came up recently on HN in a thread linked there, but there are some interesting performance graphs comparing different standards in the github PR for zstd in ZFS [1]. LZ4 still has its place IMO, ZFS is not run nor good for exclusively heavier metal, people use it to good effect on the likes of things like RPis as well. Sometimes CPU cycles is still the limiter or every last one is needed elsewhere. I also think it matters a lot less on spinning rust, where $/TB tends to be so much lower. How much one gets out of it also is influenced by a
Read the rest
pplication, general NAS with larger record size is going to see different gains vs a database. But with even vaguely modern desktop CPUs (and their surfeit of cores) and SSDs, particularly in network storage dedicated devices, an extra 10-30% even is worth a lot and there's usually plenty of CPU to throw at it. Even more so if primary usage is limited to only a 10-50 Gbps connection. As always though probably best if you can benchmark it with your own stuff and play around a bit pulling different levers. ZFS is nice that way too since it's so easy to create a bunch of different test FS at the same time. ---- 0: https://news.ycombinator.com/item?id=29268907 1: https://github.com/openzfs/zfs/pull/9735#issuecomment-570082...
In Zstandard RFC 8878
xoa·Nov 18, 2021
Looks like a decent basic rundown of what was another nice jump forward (2020 fwiw, 2.0 wasn't just introduced it launched about 1 year ago, current version is 2.1.1). Worth noting a number of these have significant implications for tuning performance in common use cases, so some resources from even a few years ago are now a bit out of date. I know a lot of people for example have followed JRS' "ZFS tuning cheat sheet" [0], and a lot of that still applies. But given the increasing usage of enormously faster but pricier solid state drives, commonly a relative surfeit of processing power, and the performance of ZStandard, I think most people should now consider it over lz4 by default when using solid state drives unless using a very weak system or every last cycle is needed for other tasks (VMs perhaps). A bunch of detailed performance grap
Read the rest
hs comparing different compression algorithms were posted in the ZSTD feature introduction [1] which can help give a better idea of the right balance. HN had a long discussion on the kind of improvement it can make at scale just a few days ago [2]. Persistent L2ARC has also potentially changed the math there in some cases, though that one in turn may well be obsoleted entirely for SSD pools. And not new here I think but somewhat more recent, for those who do still have things that make use of atime ZFS now includes the Linux style 'relatime' support which does a nice job of splitting the difference between noatime and full atime. Also, since a reasonable number of people may use ZFS via TrueNAS (formerly FreeNAS), note the GUI there doesn't expose a ton of useful features itself but can still be told to do them since it handles interfacing with ZFS via a plain Python. Currently, GUI pool/fs creation stuff is handled via: /usr/local/lib/python3.9/site-packages/middlewared/plugins/pool.py 'options' handles pool flags and 'fsoptions' fs ones. Modifying that (reboot seems needed to make it take effect afterwards though perhaps reloading something else would do it) will then allow all the GUI setup to work and slice things the way TrueNAS wants while still offering finer grained property control. Particularly useful for things that can only be set at creation time, like pool properties such as ashift/feature flags or fs properties like utf8/normalization. ---- 0: https://jrs-s.net/2018/08/17/zfs-tuning-cheat-sheet/ 1: https://github.com/openzfs/zfs/pull/9735#issuecomment-570082... 2: https://news.ycombinator.com/item?id=29164727
In Demystifying OpenZFS 2.0
magicalhippo·Nov 9, 2021
After a bit of digging, yes but no. So turns out it's a bit more involved than what's been commonly told as a straight up 80% == bad scenario. ZFS by default divides[1] each vdev (RAIDZ or mirror set) into ~200 allocation regions called metaslabs[2]. When allocating from a metaslab[3] it will check if the free space in that metaslab is below the threshold defined by metaslab_df_free_pct. It seems the threshold was changed to 4% free space at some point[4]. If the free space is above the limit it will use the fast first-fit search, if not it will use the expensive best-fit search. However, as noted that threshold is per metaslab. So if the pool is fragmented, even though the overall free space in the pool is above the 4% threshold, there might be metaslabs with less than that free, which will lead to the expensive best-fit search. So it's
Read the rest
not a hard limit, but it should start to be noticeable above 80%. [1]: https://www.delphix.com/blog/delphix-engineering/openzfs-cod... [2]: http://dtrace.org/blogs/ahl/2012/11/08/zfs-trivia-metaslabs/ [3]: https://github.com/openzfs/zfs/blob/master/module/zfs/metasl... (note metaslab_df_free_pct) [4]: https://www.truenas.com/community/threads/zfs-tweak-for-firs...
In We saved millions in SSD costs by upgrading our filesystem
throwdbaaway·Nov 8, 2021
With cloud network-based storage like EBS or pd-ssd, I doubt you will notice any IOPS-related perf penalty when running a RDBMS on top of ZFS. Assuming a mixed read/write workload, you will likely hit the disk write throughput limit first, as ZFS just writes ... a lot more, due to how blocks are stored internally: https://github.com/openzfs/zfs/issues/6584#issuecomment-3848... On an innodb database, I get about 3x compress ratio with ZSTD compression, and ZFS still has to write about 2x more than EXT4.
In The LZ4 introduced in PostgreSQL 14 provides faster compression
yjftsjthsd-h·Nov 2, 2021
I was thinking specifically in the context of ZFS, which break on minor releases because kernel-internal symbols are not fully stable (unless I've seriously misunderstood https://github.com/openzfs/zfs/issues/11320). And since Stream is a rolling release, users will therefore experience breakage unless they specifically pin their kernel version (or possibly use DKMS). That's ABI breakage, and RH explicitly saying that it doesn't count doesn't stop it breaking stuff that would work in a non-rolling release.
In Fedora 35
noaheverett·Oct 26, 2021
A Github issue for OpenZFS I was following for a year was recently closed via stale bot. I just assumed the feature was dead, however on Twitter (yesterday) they announced the feature's author was giving a talk about implementing it, so I guess it's back on! I personally wish issues weren't auto-closed as it can give the wrong (i.e. feature is dead) impression, however I know popular OSS maintainers get a TON of issue requests and are doing a work of love. So, thank you OSS maintainers, you the real MVP. P.S. For those interested, the issue[1] is NVMe performance for OpenZFS[2] [1] https://github.com/openzfs/zfs/issues/8381 [2] https://twitter.com/OpenZFS/status/1452762896769953795
In GitHub stale bot considered harmful

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