Whenever a new version of OpenZFS is released, the same question always arises among administrators and enthusiasts: Should we update as soon as possible or wait until everything is running more smoothly? With the 2.4 branch, the question becomes even more intriguing, because it's not just a simple maintenance patch, but a significant leap in performance, space management, and advanced features for hybrid pools. Furthermore, there has been some debate within the community regarding the release candidates (RCs), especially concerning their integration with systems like FreeBSD.
In this article we will calmly review The most notable new features of OpenZFS 2.4.1This includes specific changes for Windows and macOS, the status of release candidates, and all those internal improvements that, while not immediately apparent, make a significant difference in a production environment. If you manage Linux, FreeBSD, or TrueNAS servers, or are struggling with ports for Windows or macOS, you'll find everything you need to know here to assess the upgrade.
OpenZFS 2.4.1 and specific changes in Windows
The label zfswin-2.4.1rc1 It includes the adaptation of branch 2.4.1 to the Windows environment, with a very clear focus on hybrid pools and special vdevsThis takes a step forward by making special vdevs key components of performance.
In this version, a special vdev can act as SLOG (ZFS Intent Log) for synchronous writes. This allows you to take advantage of fast SSDs or NVMe drives not only for metadata or small blocks, but also to centralize sync operations, which is especially useful for workloads like databases or messaging systems that rely on immediate write commits.
In addition, hybrid pools They can be designed to take full advantage of the combination of flash and mechanical disks, increasing efficiency in Windows environments with high IOPS requirements.
Another relevant change is the ability of the special vdev save filesystem metadata, small files or even all files in the dataset, depending on how the small block size is configured (special_small_blocksIf the block size is 0, only metadata is saved; if the size is less than the file size, small files end up in the special vdev; and if recsize If it is less than or equal to that threshold, it is possible that virtually all files in the filesystem will end up in the fast part of the pool.
Combining that flexibility with tools like zfs rewrite, it's possible move data between mechanical and flash drives without having to copy to user space. In Windows environments, where the random performance of small writes can be critical, this combination of zvol in special vdev + SLOG over flash + relocating data with rewrite allows for the design of highly fine-tuned hybrid architectures.
The OpenZFS on Windows team insists that, due to the idiosyncrasy of the operating system (mounting, file locking, integration with third-party drivers, antivirus, etc.) require significantly more testing on a variety of hardware than on Linux or macOS. Therefore, with each release candidate, they encourage reporting both new issues and those carried over from the 2.3 branch on GitHub, with the goal of bringing the Windows port to the same level of maturity as the macOS version as quickly as possible.
Default quotas and new space management capabilities
One of the most welcome changes in daily life is the possibility of define predetermined quotas for users, groups, and projects. Until now, assigning usage limits in multi-user environments required a case-by-case approach; with OpenZFS 2.4, default policies can be established for each dataset.
This allows you to set, for example, a base fee for all users These limits are created within a specific filesystem, or a standard project boundary is automatically applied when new resources are allocated. The goal is to prevent a single careless user or a misconfigured service from creating a problem. fill a complete pool by surprise.
These default quotas do not replace existing specific rules, but rather They complement each other as a global policyStarting from the base configuration, exceptions can be defined for specific users or groups, fine-tuning as needed. All of this is managed using standard ZFS properties, so anyone already familiar with the property model doesn't need to learn a completely new interface.
Direct I/O, cacheless IO, and misaligned writes
In terms of performance, OpenZFS 2.4 introduces a very interesting change in the management of the Direct I/OIn scenarios where misaligned writes are used, the use of O_DIRECT could trigger inefficient code paths.
To solve this, a mechanism is now incorporated whereby, when Direct I/O cannot be applied ideally, a fallback to a lightweight cacheless I/O modeThis alternative path is specifically designed to handle those problematic writes without penalizing performance more than necessary.
What does this mean in practice? That applications that mix aligned and non-aligned access points They cease to be a pathological case that triggers bottlenecks in the I/O stack. The behavior becomes more predictable and stable, especially in systems that serve databases, virtualization engines, or services with intensive direct I/O.
Unified allocation throttling and fragmentation reduction
Another profound, though less visible, change is the new algorithm of unified allocation throttlingIts goal is to better manage block allocation when the system is under high write pressure, reducing fragmentation of the vdev and maintaining a more organized space allocation.
Until now, under certain workloads it was relatively easy to eliminate write patterns that left the vdev files very fragmented and difficult to manage In the long term, this unified algorithm harmonizes the allocation rate, resulting in more stable behavior when the pool fills up or when many different block sizes are mixed.
This optimization is especially relevant in long-term poolswhere over the years vdevs expand, space is rebalanced, scrubs are performed, devices are added, and changing workloads are supported. Having a smarter allocation mechanism helps ZFS maintain good response times even when the pool is no longer as "clean" as on day one.
Encryption improvements with AVX2 and AES-GCM
In terms of security and performance, OpenZFS 2.4 improves the encryption implementation to better utilize AVX2 instructions for AES-GCMThe project has used BoringSSL's implementation as a reference to optimize this code on modern CPUs, especially on architectures like AMD Zen 3.
The result are significant performance increases (Improvements of up to 80% have been reported in certain scenarios), which reduces the impact of encryption on the CPU. This optimization is particularly noticeable in systems that store large volumes of encrypted data or perform many simultaneous operations on encrypted datasets.
In practice, this makes the ZFS native encryption is “cheaper”It doesn't become free, but it ceases to be such a significant bottleneck as in previous versions, facilitating its adoption in environments where, until now, there was a trade-off between security and performance.
ZIL in special vdevs and expanded special_small_blocks
The management of special vdevs This is another area where OpenZFS 2.4 makes an interesting leap. Traditionally, these devices have been used for metadata, small blocks, or deduplication tables, usually on SSDs or NVMe drives.
With this version, the system allows the ZIL (ZFS Intent Log) It is hosted on special vdevs if available. This means that synchronous writes can land on very low-latency media without needing a dedicated separate device like SLOG, opening up more flexible hybrid pool designs.
The property special_small_blocks It is expanded so that the ZVOL writings These special VDEVs can also fall into these special VDEVs, not just certain regular file blocks. Furthermore, it is no longer mandatory for the value of this property to be a power of two, which allows more flexibility in adjusting the "small block" threshold to the reality of each load.
By combining ZIL in special vdevs, ZVOL on flash and adjustable thresholdsArchitectures can be designed where metadata, small blocks, deduplication tables, clones, and synchronous writes are concentrated on the fastest devices, leaving spinning disks for less latency-sensitive mass storage.
zfs rewrite and zfs rewrite -P: relocate data without breaking anything
The 2.3 series introduced zfs rewrite as one of the most powerful features of recent times, and OpenZFS 2.4 takes it a step further by adding the option zfs rewrite -PThis tool allows data to be rewritten within the pool while maintaining its logical meaning intact.
With zfs rewrite you can, for example, change compression algorithm, checksum, deduplication or number of copies, rebalance data after adding vdevs or force certain files to move to special vdevs, all without having to copy them to user space and without altering metadata such as mtime.
The variant -P instituted preserve the logical birth time of the blocks Whenever possible. This has a direct impact on the efficiency of incremental send/receive, because by keeping these values stable, subsequent replications can better detect what has actually changed and reduce the volume of data traveling between systems.
Another important detail is that the rewriting process is protected with standard range locksThis allows it to run in parallel with real-world workloads without excessively blocking the dataset. In environments with sync=alwaysThe advantage is twofold, because the operation does not cause additional writes to the ZIL since there are no logical changes in content, reducing the impact on devices dedicated to synchronous writes.
New management options: -a, range scrub, and BRT prefetch
OpenZFS 2.4 also improves the administrator's life with minor changes to command-line toolsOne of the most practical is the addition of the option -a|--all in operations such as scrub, trim or initialization.
Thanks to this option, it is possible Run a scrub, trim, or init on all imported pools in a single pass, without having to manually iterate through each one. This reduces human error and simplifies maintenance scripts on servers with multiple pools.
Another new feature is the ability to run zpool scrub limited to specific time ranges through the options -S y -EThis time-window approach is ideal when problems are suspected during a specific period, or when you want to break down the cost of a large scrub into several less intrusive partial executions.
In addition, it is introduced zpool prefetch -t brt, which allows preloading into memory the Block Reference Table (BRT)That is, the internal table used for block cloning. Prefetching this structure reduces latency in operations that depend on cloning, which benefits workloads that heavily rely on clones.
Permissions, renamed tools, dedup, and block cloning
In the area of security and permissions management, OpenZFS 2.4 introduces a new permission called send:encryptedWith it, you can more finely control who is authorized to send encrypted datasets, separating responsibilities between those who manage snapshots, replication, and key access.
At the same time, utilities known as arc_summary y arcstat they become known as zarcsummary y zarcstatThis renaming helps avoid name conflicts with other system tools and makes it clearer that these are utilities linked to the ZFS ARC, which is useful in environments with many components.
Internally, branch 2.4 accumulates Optimizations and corrections in block deduplication and cloningData structures are refined, edge cases are corrected, and efforts are made to reduce the impact on memory and CPU. This isn't something the user will immediately notice as a new option, but it translates into fewer surprises when deduplication or block cloning are activated under heavy loads.
Gang blocks, ashift, slow vdevs, and special topologies
The new version includes a wide range of Improvements and fixes related to gang blocksThese are special blocks that ZFS uses when it cannot store data in the conventional way. Any flaw in this area of the code can be serious, so the numerous fixes that have been introduced provide added robustness.
The management of ashiftThe parameter that sets the minimum allocation size aligned with the physical sector size of the device. Smarter handling of `ashift` reduces unnecessary overwriting on disks with large sectors and helps maintain performance throughout the pool's lifetime.
Another very practical contribution is the ability to “to put on the bench” vdevs children who behave abnormally slowlyInstead of letting a problematic drive drag down the performance of the entire system, the system can temporarily stop relying on it, which is very useful with drives that start to fail intermittently or in configurations with heterogeneous hardware.
Finally They relax topology restrictions in special vdevs and deduplication.This opens up more possibilities when designing advanced pools. It's now easier to combine fast devices for metadata, deduplicated tables, ZILs, and other sensitive elements without constantly running into overly strict limitations in the topology definition.
OpenZFS 2.3.4 as the basis for the jump to 2.4
To fully understand the magnitude of the leap, it is worth remembering that OpenZFS 2.3.4 It was a key maintenance release that extended Linux kernel support up to version 6.16, keeping the minimum at 4.18, and confirmed compatibility with FreeBSD from 13.3 up to the 15.0 branches in preparation.
That review saw the release of the initial version of zfs rewrite, designed precisely for relocate data without changing its logical content and without having to resort to send/receive with dataset renaming or manual copies. The idea was to offer a tool capable of rebalancing pools after adding vdevs, reducing fragmentation caused by random writes, or applying new storage properties to existing data.
In contrast to classical strategies, zfs rewrite it was faster and less intrusive because it avoids taking the data to user space and doesn't force extra writes to the ZIL in datasets with sync=alwaysFurthermore, respect mtime and other visible metadataso that applications that live on top of the filesystem barely notice that anything has happened.
Taken together, OpenZFS 2.4 and its evolution 2.4.1 represent a A significant leap in performance, flexibility, and management toolsEspecially for those who rely on hybrid pools with special vdevs, intensive encryption, and multi-user environments with strict quotas. Improvements in encryption with AVX2, unified allocation throttling, ZIL in special vdevs, and the expansion of special_small_blocks, zfs rewrite And its variants, along with all the work on gang blocks, ashift, deduplication and block cloning, consolidate OpenZFS as one of the most advanced file systems in the free ecosystem, ready to be squeezed dry on Linux and FreeBSD as well as macOS and, little by little, also on Windows.
