RAIDZ Expansion (#15022): Add new devices to an existing RAIDZ pool, increasing storage capacity without downtime.
Fast Dedup (#15896): A major performance upgrade to the original OpenZFS deduplication functionality.
Direct IO (#10018): Allows bypassing the ARC for reads/writes, improving performance in scenarios like NVMe devices where caching may hinder efficiency.
JSON (#16217): Optional JSON output for the most used commands.
Long names (#15921): Support for file and directory names up to 1023 characters.
Bug Fixes: A series of critical bug fixes addressing issues reported in previous versions.
Numerous performance improvements throughout the code base.
Supported Platforms:
Linux kernels 4.18 - 6.12,
FreeBSD releases 13.3, 14.0 - 14.2.
“Performance delta focuses on the relationship of each dedup routine compared to un-deduped storage on the same hardware. It’s the same data but organized differently.
Fast dedup outperforms legacy dedup by almost 25% of the raw performance.“
“OpenZFS 2.2.5 is now available as the newest stable update to this open-source ZFS file-system implementation for Linux and FreeBSD systems.
OpenZFS 2.2.5 adds official support now for Linux 6.9 while continuing to retain support back through Linux 4.18 kernels. Yes, Linux 6.10 is out as stable now for the past three weeks and there are some Linux 6.10 compatibility patches in OpenZFS 2.2.5 but apparently not yet enough to claim full support. On the FreeBSD side there is support with FreeBSD 12.2 and later.
Besides supporting Linux 6.9 and some Linux 6.10 bits, OpenZFS 2.2.5 brings dozens of various bug fixes. There is improved dnode hashing, cleaning up buffer re-compression in L2ARC, various libspl fixes, various ZTS fixes, and other fixes scattered throughout.”
“The current implementation of zvol uses a single taskq, leading to lock contention under heavy load and consequently decreased throughput. Introducing multiple taskqs and implementing a switch based on IO offset can alleviate this lock contention, thus improving overall throughput.”
Fast Deduplication was developed by Klara Inc and iXsystems and offers up to x20 greater performance.
“With the introduction of Fast Dedup, there have been several major innovations including:
The size of metadata is now dynamically sized to fit in either RAM or dedicated flash devices to avoid hitting the performance penalty wall.
The metadata structure has been completely re-engineered to enable efficient updates using a log append process, greatly improving performance for large updates such as deletions.
The dedup table will favor dedup-able data and prune blocks that show no dedup potential.
Combining metadata improvements with properly configured storage, including dedicated metadata flash devices, will improve the sustained dedup performance by over an order of magnitude for larger systems.”
Some users are sceptical about potential data loss issues, as with any filesystem technologies..
Ed Maste, the Director of Project Development for The FreeBSD Foundation, sent the following email in the freebsd-stable mailing list, regarding a new ZFS issue. It appears that it affects earlier versions of OpenZFS and it is not related to block cloning.
Dear FreeBSD community,
We want to bring your attention to a potential data corruption issue affecting multiple versions of OpenZFS. It was initially reported against OpenZFS 2.2.0 but also affects earlier and later versions.
This issue can be reproduced with targeted effort but it has not been observed frequently in real-world scenarios. This issue is not related to block cloning, although it is possible that enabling block cloning increases the probability of encountering the issue.
It is unclear if the issue is reproducible on the version of ZFS in FreeBSD 12.4.
A short term workaround is available for FreeBSD 14.0 and 13.2 by setting the vfs.zfs.dmu_offset_next_sync sysctl to 0:
The workaround may result in inaccurate reporting of file holes in sparse files, reintroducing OpenZFS issue 6958[1]. See the ZFS(4) man page for more information on this setting.
The workaround does not deterministically prevent the issue but does drastically reduce the likelihood of encountering it.
For more information, see OpenZFS issue 15526[2] and OpenZFS pull request 15571[3]. FreeBSD bug report PR 275308[4] is open to track the FreeBSD erratum update which will bring in the fix, after it is committed to OpenZFS. Please check the FreeBSD PR regularly if you are looking for details on the timeline of the FreeBSD erratum update.
We want to assure the FreeBSD community that we are actively monitoring the situation. Thank you for your understanding and continued support.
/root 