ZPOOL-FEATURES(7)

zpool-features 💖✨

okay bestie, pull up a chair, this is zpool-features(7) from the Miscellaneous Information Manual and it's a LOT, but we're gonna get through it together, i promise 🫶

---

✨ NAME ✨

zpool-features — the whole entire rundown on ZFS pool features 🎀

---

💅 DESCRIPTION 💅

so like, ZFS pool on-disk format versions? they're specified via “features” now, which fully replaced the old-school on-disk format numbers (and heads up: the last on-disk format number that's still supported is 28, that's the end of the line for the old way 👋).

wanna enable a feature on a pool? two ways, bestie:

• use zpool upgrade
• or set the feature@feature-name property to enabled

also go read the “Compatibility feature sets” section down below if you wanna know how whole sets of features get enabled together, it's giving group project energy 👯‍♀️

real talk though — the pool format does NOT affect file system version compatibility, and it does NOT affect whether you can send file systems between pools. so breathe, it's fine 💆‍♀️

and since most features can be enabled independently of each other, the on-disk format of the pool is literally just defined by the set of all features marked as active on the pool. that's it. that's the format. if the pool was created by some other software version, that set might include features your system doesn't support at all 😭

🔍 Identifying features

every single feature has a GUID that looks like com.example:feature-name. the reversed DNS name is doing the work of making sure the GUID is unique across all ZFS implementations, no cap 🌍

when unsupported features show up on a pool, they get identified by their GUIDs, and you gotta go read the docs for whatever ZFS implementation made that pool to find out what they even are 📖

every supported feature also has a short name. by convention, the short name is just the part of the GUID after the ':' — so com.example:feature-name would have the short name feature-name. BUT (plot twist) a feature's short name can differ between ZFS implementations if following the convention would cause name conflicts 💀

🌈 Feature states

features live in one of three states, pick your fighter:

• active — this feature's on-disk format changes are in effect on the pool. support for it is required to import the pool in read-write mode. and if this feature isn't read-only compatible, support is also required to import the pool in read-only mode too (peep “Read-only compatibility” below).
• enabled — an admin has marked this feature as enabled on the pool, but the on-disk format changes haven't actually been made yet. the pool can still be imported by software that doesn't support this feature, BUT changes may be made to the on-disk format at any time, which will move the feature to active. some features support going back to enabled after becoming active — check the feature-specific docs for that tea 🍵
• disabled — the on-disk format changes haven't been made and won't be made unless an admin moves the feature to enabled. and listen: features cannot be disabled once they've been enabled. that door only swings one way 🚪😭

the state of supported features is exposed through pool properties that look like feature@short-name.

👀 Read-only compatibility

some features make on-disk format changes that don't get in the way of other software's ability to read from the pool. these are called “read-only compatible” and they're the chill ones 🧊

if all the unsupported features on a pool are read-only compatible, the pool can be imported in read-only mode by setting the readonly property during import (go see zpool-import(8) for the deets on importing pools).

🚫 Unsupported features

for every unsupported feature enabled on an imported pool, there's a pool property named unsupported@feature-name that tells you why the import was allowed despite the unsupported feature. possible values:

• inactive — the feature is in the enabled state, so the pool's on-disk format is still compatible with software that doesn't support this feature.
• readonly — the feature is read-only compatible and the pool has been imported in read-only mode.

🔗 Feature dependencies

some features depend on other features being enabled in order to function. enabling a feature will automatically enable anything it depends on. it's giving "i'm not going anywhere without my bestie" 💅

🎀 Compatibility feature sets

sometimes a pool has to maintain compatibility with a specific on-disk format by enabling and disabling particular features. the compatibility feature makes this possible by letting feature sets be read from text files. here's the whole menu:

• set to off (which is the default) → compatibility feature sets are disabled, i.e. all features are enabled.
• set to legacy → no features are enabled.
• set to a comma-separated list of filenames → each filename can be an absolute path, or relative to /etc/zfs/compatibility.d or /usr/share/zfs/compatibility.d. the lists of requested features are read from those files, separated by whitespace and/or commas. and heads up: only features present in all the files are enabled.

simple sanity checks get applied to the files, no exceptions:

• they must be between 1 B and 16 KiB in size
• they must end with a newline character

the requested features get applied when a pool is created using zpool create -o compatibility=…, and it also controls which features are enabled when using zpool upgrade. and zpool status will not show a warning about disabled features that aren't part of the requested feature set. so no drama there ✨

the special value legacy prevents any features from being enabled — whether that's via zpool upgrade or zpool set feature@feature-name=enabled. it also stops pools from being upgraded to newer on-disk versions. this is a safety measure so new features don't get accidentally enabled and break compatibility. protective queen behavior honestly 👑

by convention, compatibility files in /usr/share/zfs/compatibility.d are provided by the distribution, and they include feature sets supported by important versions of popular distros, plus feature sets commonly supported at the start of each year 🗓️ and files in /etc/zfs/compatibility.d, if they're there, take precedence over files with the same name in /usr/share/zfs/compatibility.d.

now, if an unrecognized feature shows up in these files, you get an error message. and it depends on where:

• unrecognized feature in a file in /etc/zfs/compatibility.d → treated as an error and processing stops 🛑
• unrecognized feature under /usr/share/zfs/compatibility.d → treated as a warning and processing continues ⚠️

the difference is on purpose, so distributions can include features that might not be recognized by the currently-installed binaries. thoughtful fr fr 🫶

compatibility files can also include comments: any text from '#' to the end of the line is ignored 💬

example time, look at this:

example# cat /usr/share/zfs/compatibility.d/grub2
# Features which are supported by GRUB2 versions from v2.12 onwards.
allocation_classes
async_destroy
block_cloning
bookmarks
device_rebuild
embedded_data
empty_bpobj
enabled_txg
extensible_dataset
filesystem_limits
hole_birth
large_blocks
livelist
log_spacemap
lz4_compress
project_quota
resilver_defer
spacemap_histogram
spacemap_v2
userobj_accounting
zilsaxattr
zpool_checkpoint

example# cat /usr/share/zfs/compatibility.d/grub2-2.06
# Features which are supported by GRUB2 versions prior to v2.12.
#
# GRUB is not able to detect ZFS pool if snapshot of top level boot pool
# is created. This issue is observed with GRUB versions before v2.12 if
# extensible_dataset feature is enabled on ZFS boot pool.
#
# This file lists all read-only compatible features except
# extensible_dataset and any other feature that depends on it.
#
allocation_classes
async_destroy
block_cloning
device_rebuild
embedded_data
empty_bpobj
enabled_txg
hole_birth
log_spacemap
lz4_compress
resilver_defer
spacemap_histogram
spacemap_v2
zpool_checkpoint

example# zpool create -o compatibility=grub2 bootpool vdev

and for more on how these commands are affected by feature sets, go see zpool-create(8) and zpool-upgrade(8) 💖

---

🔥 FEATURES 🔥

the following features are supported on this system, bestie. buckle up 🎢

allocation_classes

• GUID — org.zfsonlinux:allocation_classes
• READ-ONLY COMPATIBLE — yes

this feature enables support for separate allocation classes 🎯

it becomes active when a dedicated allocation class vdev (dedup or special) is created with the zpool create or zpool add commands. and with device removal, it can be returned to the enabled state if all the dedicated allocation class vdevs are removed. flexible icon 💅

async_destroy

• GUID — com.delphix:async_destroy
• READ-ONLY COMPATIBLE — yes

okay so destroying a file system requires traversing all of its data in order to return its used space to the pool. without async_destroy, the file system is not fully removed until all that space has been reclaimed. and if the destroy operation gets interrupted by a reboot or a power outage 😭 the next attempt to open the pool will need to complete the destroy operation synchronously.

when async_destroy is enabled, the file system's data gets reclaimed by a background process, which lets the destroy operation complete without traversing the entire file system. that background process can resume interrupted destroys after the pool has been opened, so you don't have to finish interrupted destroys as part of the open operation. iconic honestly ✨ the amount of space still waiting to be reclaimed by the background process is available through the freeing property.

heads up: this feature is only active while freeing is non-zero. 👀

blake3

• GUID — org.openzfs:blake3
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — no

this feature enables the use of the BLAKE3 hash algorithm for checksum and dedup. BLAKE3 is a secure hash algorithm focused on high performance 🏎️💨

when the blake3 feature is set to enabled, the administrator can turn on the blake3 checksum on any dataset using zfs set checksum=blake3 dset (see zfs-set(8)). this feature becomes active once a checksum property has been set to blake3, and it will return to being enabled once all filesystems that have ever had their checksum set to blake3 are destroyed. so it's reversible, but only the slow way 🐌

block_cloning

• GUID — com.fudosecurity:block_cloning
• READ-ONLY COMPATIBLE — yes

Okay so when this feature is on, ZFS will use block cloning for operations like copy_file_range(2). Block cloning lets you create multiple references to a single block — it's so much faster than copying the data (because the actual data is neither read nor written) and it takes up zero additional space. Blocks can be cloned across datasets under some conditions (like equal recordsize, the same master encryption key, etc.). ZFS tries its best to clone across datasets including encrypted ones. This is limited for various (nontrivial) reasons depending on the OS and/or ZFS internals. 🦋

This feature becomes active when first block is cloned. When the last cloned block is freed, it goes back to the enabled state.

---

🌈 block_cloning_endian

• GUID — com.truenas:block_cloning_endian
• READ-ONLY COMPATIBLE — yes

This feature corrects ZAP entry endianness issues in the Block Reference Table (BRT) used by block cloning. During the original block cloning implementation, BRT ZAP entries were mistakenly stored as arrays of 8 single-byte entries instead of single 8-byte entries, making pools non-endian-safe. 💀 (<- the typo era, we don't talk about it)

This feature is activated when the first BRT ZAP is created (that way ensuring compatibility with existing pools). When active, new BRT entries are stored in the correct endian-safe format. The feature becomes inactive when all BRT ZAPs are destroyed.

---

🎀 bookmarks

• GUID — com.delphix:bookmarks
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — yes

This feature enables use of the zfs bookmark command.

This feature is active while any bookmarks exist in the pool. All bookmarks in the pool can be listed by running zfs list -t bookmark -r poolname. ✨

---

🎀 bookmark_v2

• GUID — com.datto:bookmark_v2
• DEPENDENCIES — bookmark, extensible_dataset
• READ-ONLY COMPATIBLE — no

This feature enables the creation and management of larger bookmarks which are needed for other features in ZFS.

This feature becomes active when a v2 bookmark is created and will be returned to the enabled state when all v2 bookmarks are destroyed.

---

🎀 bookmark_written

• GUID — com.delphix:bookmark_written
• DEPENDENCIES — bookmark, extensible_dataset, bookmark_v2
• READ-ONLY COMPATIBLE — no

This feature enables additional bookmark accounting fields, enabling the written#bookmark property (space written since a bookmark) and estimates of send stream sizes for incrementals from bookmarks.

This feature becomes active when a bookmark is created and will be returned to the enabled state when all bookmarks with these fields are destroyed.

---

🛠️ device_rebuild

• GUID — org.openzfs:device_rebuild
• READ-ONLY COMPATIBLE — yes

This feature enables the ability for the zpool attach and zpool replace commands to perform sequential reconstruction (instead of healing reconstruction) when resilvering.

Sequential reconstruction resilvers a device in LBA order without immediately verifying the checksums. Once complete, a scrub is started, which then verifies the checksums. This approach allows full redundancy to be restored to the pool in the minimum amount of time. This two-phase approach will take longer than a healing resilver when the time to verify the checksums is included. However, unless there is additional pool damage, no checksum errors should be reported by the scrub. This feature is incompatible with raidz configurations. This feature becomes active while a sequential resilver is in progress, and returns to enabled when the resilver completes.

---

🛠️ device_removal

• GUID — com.delphix:device_removal
• READ-ONLY COMPATIBLE — no

This feature enables the zpool remove command to remove top-level vdevs, evacuating them to reduce the total size of the pool.

This feature becomes active when the zpool remove command is used on a top-level vdev, and will never return to being enabled. 🔥 (one-way trip, bestie)

---

👑 draid

• GUID — org.openzfs:draid
• READ-ONLY COMPATIBLE — no

This feature enables use of the draid vdev type. dRAID is a variant of RAID-Z which provides integrated distributed hot spares that allow faster resilvering while retaining the benefits of RAID-Z. Data, parity, and spare space are organized in redundancy groups and distributed evenly over all of the devices.

This feature becomes active when creating a pool which uses the draid vdev type, or when adding a new draid vdev to an existing pool.

---

🌸 dynamic_gang_header

• GUID — com.klarasystems:dynamic_gang_header
• READ-ONLY COMPATIBLE — no

This feature enables larger gang headers based on the sector size of the pool. When enabled, gang headers will use the entire space allocated for them, instead of always restricting themselves to 512 bytes. This can reduce the need for nested gang trees in extreme fragmentation scenarios.

This feature becomes active when a gang header is written that is larger than 512 bytes. This feature is not enabled by zpool-upgrade(8). Instead, it must be manually enabled, or be part of a compatibility file. (yes, you gotta do it yourself, no autopilot 💅)

---

🧚 edonr

• GUID — org.illumos:edonr
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — no

This feature enables the use of the Edon-R hash algorithm for checksum, including for nopwrite (if compression is also enabled, an overwrite of a block whose checksum matches the data being written will be ignored). In an abundance of caution, Edon-R requires verification when used with dedup: zfs set dedup=edonr,verify (see zfs-set(8)).

Edon-R is a very high-performance hash algorithm that was part of the NIST SHA-3 competition. It provides extremely high hash performance (over 350% faster than SHA-256), but was not selected because of its unsuitability as a general purpose secure hash algorithm. This implementation utilizes the new salted checksumming functionality in ZFS, which means that the checksum is pre-seeded with a secret 256-bit random key (stored on the pool) before being fed the data block to be checksummed. Thus the produced checksums are unique to a given pool, preventing hash collision attacks on systems with dedup. 🔐

When the edonr feature is set to enabled, the administrator can turn on the edonr checksum on any dataset using zfs set checksum=edonr dset (see zfs-set(8)). This feature becomes active once a checksum property has been set to edonr, and will return to being enabled once all filesystems that have ever had their checksum set to edonr are destroyed.

---

🍓 embedded_data

• GUID — com.delphix:embedded_data
• READ-ONLY COMPATIBLE — no

This feature improves the performance and compression ratio of highly-compressible blocks. Blocks whose contents can compress to 112 bytes or smaller can take advantage of this feature.

When this feature is enabled, the contents of highly-compressible blocks are stored in the block “pointer” itself (a misnomer in this case, as it contains the compressed data, rather than a pointer to its location on disk). Thus the space of the block (one sector, typically 512 B or 4 KiB) is saved, and no additional I/O is needed to read and write the data block. This feature becomes active as soon as it is enabled and will never return to being enabled.

---

🫶 empty_bpobj

• GUID — com.delphix:empty_bpobj
• READ-ONLY COMPATIBLE — yes

This feature increases the performance of creating and using a large number of snapshots of a single filesystem or volume, and also reduces the disk space required.

When there are many snapshots, each snapshot uses many Block Pointer Objects (bpobjs) to track blocks associated with that snapshot. However, in common use cases, most of these bpobjs are empty. This feature allows us to create each bpobj on-demand, thus eliminating the empty bpobjs. (no more ghost bpobjs haunting the pool 👻)

This feature is active while there are any filesystems, volumes, or snapshots which were created after enabling this feature.

---

⭐ enabled_txg

• GUID — com.delphix:enabled_txg
• READ-ONLY COMPATIBLE — yes

Once this feature is enabled, ZFS records the transaction group number in which new features are enabled. This has no user-visible impact, but other features may depend on this feature.

This feature becomes active as soon as it is enabled and will never return to being enabled.

---

💜 encryption

• GUID — com.datto:encryption
• DEPENDENCIES — bookmark_v2, extensible_dataset
• READ-ONLY COMPATIBLE — no

This feature enables the creation and management of natively encrypted datasets.

This feature becomes active when an encrypted dataset is created and will be returned to the enabled state when all datasets that use this feature are destroyed.

---

⚡ fast_dedup

• GUID — com.klarasystems:fast_dedup
• READ-ONLY COMPATIBLE — yes

This feature allows more advanced deduplication features to be enabled on new dedup tables.

This feature will be active when the first deduplicated block is written after a new dedup table is created (i.e. after a new pool creation, or new checksum used on a dataset with dedup enabled). It will be returned to the enabled state when all deduplicated blocks using it are freed.

---

🦋 extensible_dataset

• GUID — com.delphix:extensible_dataset
• READ-ONLY COMPATIBLE — no

This feature allows more flexible use of internal ZFS data structures, and exists for other features to depend on. (she's the supportive bestie every other feature leans on 🫶)

So like — this feature goes active the second the first dependent feature actually uses it, and it gets returned to the enabled state once every single dataset that uses it has been destroyed. 💫

---

🎀 filesystem_limits

• GUID — com.joyent:filesystem_limits
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — yes

Okay so this one turns on filesystem and snapshot limits — like actual caps, bestie. You use these to control how many filesystems and/or snapshots can be created at the exact point in the tree where you set the limits. 🌳

This feature goes active the moment either of the limit properties gets set on a dataset, and it will never go back to being enabled. Periodt.

✨ head_errlog

• GUID — com.delphix:head_errlog
• READ-ONLY COMPATIBLE — no

This one unlocks the upgraded version of errlog, which lowkey needed an on-disk error log format change. Now the error log of every head dataset is stored separately in the zap object, keyed by the head id. With this enabled, every dataset affected by an error block shows up in the output of zpool status. 👀

Heads up though: for encrypted filesystems with unloaded keys, we literally can't check their snapshots or clones for errors, so those won't be reported at all. Instead you get an "access denied" error. Not me being dramatic, that's just what happens. 😭

This feature becomes active as soon as it's enabled and will never return to being enabled.

💀 hole_birth

• GUID — com.delphix:hole_birth
• DEPENDENCIES — enabled_txg
• READ-ONLY COMPATIBLE — no

Okay so this feature has/had bugs, and the result is genuinely unhinged: if you do a zfs send -i (or -R, since it uses -i) from an affected dataset, the receiving party will not see any checksum or other errors, but the resulting destination snapshot will not match the source. 💀 Its use by zfs send -i has been disabled by default (see send_holes_without_birth_time in zfs(4)).

So what's it supposed to do? It improves performance of incremental sends (zfs send -i) and receives for objects with many holes. The most common case of hole-filled objects is zvols.

An incremental send stream from snapshot A to snapshot B contains information about every block that changed between A and B. Blocks which did not change between those snapshots can be identified and omitted from the stream using a piece of metadata called the "block birth time", but birth times are not recorded for holes (blocks filled only with zeroes). Since holes created after A cannot be distinguished from holes created before A, information about every hole in the entire filesystem or zvol is included in the send stream.

For workloads where holes are rare this is not a problem. However, when incrementally replicating filesystems or zvols with many holes (for example a zvol formatted with another filesystem) a lot of time will be spent sending and receiving unnecessary information about holes that already exist on the receiving side. 🐌

Once the hole_birth feature has been enabled the block birth times of all new holes will be recorded. Incremental sends between snapshots created after this feature is enabled will use this new metadata to avoid sending information about holes that already exist on the receiving side.

This feature becomes active as soon as it's enabled and will never return to being enabled.

🌸 large_blocks

• GUID — org.open-zfs:large_blocks
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — no

This lets the record size on a dataset be set larger than 128 KiB. Big blocks, no cap. 🔥

It becomes active once a dataset contains a file with a block size larger than 128 KiB, and it returns to being enabled once all filesystems that have ever had their recordsize larger than 128 KiB are destroyed.

🦋 large_dnode

• GUID — org.zfsonlinux:large_dnode
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — no

This one lets the size of dnodes in a dataset be set larger than 512 B. It becomes active once a dataset contains an object with a dnode larger than 512 B — which happens as a result of setting the dnodesize dataset property to a value other than legacy. The feature returns to being enabled once all filesystems that have ever contained a dnode larger than 512 B are destroyed. 🫶

And the tea? Large dnodes let more data be stored in the bonus buffer, which can potentially improve performance by avoiding the use of spill blocks. Slay.

🍓 large_microzap

• GUID — com.klarasystems:large_microzap
• DEPENDENCIES — extensible_dataset, large_blocks
• READ-ONLY COMPATIBLE — yes

This lets "micro" ZAPs grow larger than 128 KiB without being upgraded to "fat" ZAPs. Glow-up, but make it stay micro. ✨

It becomes active the first time a micro ZAP grows larger than 128KiB. It will only be returned to the enabled state when all datasets that ever had a large micro ZAP are destroyed.

Ngl though — even when this feature is enabled, micro ZAPs cannot grow larger than 128 KiB without also changing the zap_micro_max_size module parameter. See zfs(4). So don't get it twisted. 🙈

🌈 livelist

• GUID — com.delphix:livelist
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — yes

This lets clones be deleted faster than the traditional method when a large number of random/sparse writes have been made to the clone. All blocks allocated and freed after a clone is created are tracked by the clone's livelist, which is referenced during the deletion of the clone. The feature is activated when a clone is created and remains active until all clones have been destroyed. 🧹

💜 log_spacemap

• GUID — com.delphix:log_spacemap
• DEPENDENCIES — com.delphix:spacemap_v2
• READ-ONLY COMPATIBLE — yes

This one improves performance for heavily-fragmented pools, especially when workloads are heavy in random-writes. How? By logging all the metaslab changes on a single spacemap every TXG instead of scattering multiple writes to all the metaslab spacemaps. Efficiency is the moment. 💅

This feature becomes active as soon as it's enabled and will never return to being enabled.

⭐ longname

• GUID — org.zfsonlinux:longname
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — no

This lets you create files and directories with names up to 1023 bytes in length. Iconic, honestly. A new dataset property longname is also introduced to toggle longname support for each dataset individually. This property can be disabled even if it contains longname files. In such case, new file cannot be created with longname but existing longname files can still be looked up. 👑

It becomes active when a file name greater than 255 is created in a dataset, and returns to being enabled when all such datasets are destroyed.

🔥 lz4_compress

• GUID — org.illumos:lz4_compress
• READ-ONLY COMPATIBLE — no

lz4 is a high-performance real-time compression algorithm that features significantly faster compression and decompression as well as a higher compression ratio than the older lzjb compression. Typically, lz4 compression is approximately 50% faster on compressible data and 200% faster on incompressible data than lzjb. It is also approximately 80% faster on decompression, while giving approximately a 10% better compression ratio. Numbers are numbers and these numbers ate. 😌

When the lz4_compress feature is set to enabled, the administrator can turn on lz4 compression on any dataset on the pool using the zfs-set(8) command. All newly written metadata will be compressed with the lz4 algorithm.

This feature becomes active as soon as it's enabled and will never return to being enabled.

🎀 multi_vdev_crash_dump

• GUID — com.joyent:multi_vdev_crash_dump
• READ-ONLY COMPATIBLE — no

This lets a dump device be configured with a pool comprised of multiple vdevs. Those vdevs may be arranged in any mirrored or raidz configuration. 🛟

When the multi_vdev_crash_dump feature is set to enabled, the administrator can use dumpadm(8) to configure a dump device on a pool comprised of multiple vdevs.

Under FreeBSD and Linux this feature is unused, but registered for compatibility. New pools created on these systems will have the feature enabled but will never transition to active, as this functionality is not required for crash dump support. Existing pools where this feature is active can be imported. Not useless, just vibing in the background. 💫

🌸 obsolete_counts

• GUID — com.delphix:obsolete_counts
• DEPENDENCIES — device_removal
• READ-ONLY COMPATIBLE — yes

This is an enhancement of device_removal, which will over time reduce the memory used to track removed devices. When indirect blocks are freed or remapped, we note that their part of the indirect mapping is "obsolete" — no longer needed. Marie Kondo-ing your metadata, basically. ✨

This feature becomes active when the zpool remove command is used on a top-level vdev, and will never return to being enabled.

💖 physical_rewrite

• GUID — com.truenas:physical_rewrite
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — yes

This enables physical block rewriting that preserves logical birth times, avoiding unnecessary inclusion of rewritten blocks in incremental zfs send streams. When enabled, the zfs rewrite -P command can be used. Rewrite but make it not show up twice. 💅

This feature becomes active the first time zfs rewrite -P is used on any dataset, and will return to being enabled once all datasets that have ever used physical rewrite are destroyed.

project_quota 🍓

• GUID — org.zfsonlinux:project_quota
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — yes

okay so this one lets admins keep track of how much space and how many objects are being used, but sorted by project ID instead of by user or group. bestie that's the whole vibe 💅

The project ID is an object-based attribute. When you're upgrading an existing filesystem, any objects that don't already have a project ID get assigned a project ID of zero. Once this feature is enabled, brand-new objects inherit their parent directories' project ID — but only if the parent's inherit flag is set (that's via chattr [+-]P or zfs project -s|-C). If it's not set? New object's project ID is zero, periodt. An object's project ID can be changed whenever, by the owner (or a privileged user), using chattr -p prjid or zfs project -p prjid.

This feature becomes active the second it's enabled and never goes back to being disabled. Every filesystem gets upgraded automatically when it's remounted, or when a new file is created under it. You can also trigger the upgrade manually on filesystems with zfs set version=current fs. Heads up: the upgrade runs in the background and can take a <em>while</em> on filesystems with tons of files 😭

---

raidz_expansion 🌈

• GUID — org.openzfs:raidz_expansion
• DEPENDENCIES — none
• READ-ONLY COMPATIBLE — no

This one turns on the ability to use the zpool attach subcommand to attach a new device to a RAID-Z group — which expands the total usable space in the pool. Slay. See zpool-attach(8) for the deets.

---

redaction_bookmarks 🎀

• GUID — com.delphix:redaction_bookmarks
• DEPENDENCIES — bookmarks, extensible_dataset
• READ-ONLY COMPATIBLE — no

Enables redacted zfs sends, which create redaction bookmarks that store the list of blocks redacted by the send that made them. Want the whole story on redacted sends? zfs-send(8) has you 🫶

---

redacted_datasets 🧚

• GUID — com.delphix:redacted_datasets
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — no

This is what lets you receive redacted zfs send streams, which create redacted datasets when they land. ⚠️ Important though: these datasets are missing some of their blocks, so they cannot be safely mounted, and their contents cannot be safely read. Not a vibe to ignore, fr fr. More info on redacted receives in zfs-send(8).

---

redaction_list_spill ✨

• GUID — com.delphix:redaction_list_spill
• DEPENDENCIES — redaction_bookmarks
• READ-ONLY COMPATIBLE — no

Lets the redaction list created by zfs redact store way more entries. It becomes active when a redaction list is created with more than 36 entries, and it returns to being enabled when no long redaction lists are left in the pool. Again, redacted sends lore lives in zfs-send(8) 💖

---

resilver_defer 🦋

• GUID — com.datto:resilver_defer
• READ-ONLY COMPATIBLE — yes

This feature lets ZFS postpone new resilvers when one's already running. Without it? Every new resilver makes the currently running one immediately restart from the very beginning. 💀 Yeah.

It becomes active once a resilver has been deferred, and goes back to being enabled when the deferred resilver starts.

---

sha512 👑

• GUID — org.illumos:sha512
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — no

Enables the SHA-512/256 truncated hash algorithm (FIPS 180-4) for checksum and dedup. The native 64-bit arithmetic of SHA-512 gives roughly a 50% performance boost over SHA-256 on 64-bit hardware, which makes it a solid minimum-change replacement candidate for systems where hash performance matters but — for whatever reason — those systems can't use the faster skein and edonr algorithms.

When the sha512 feature is set to enabled, the administrator can turn on the sha512 checksum on any dataset with zfs set checksum=sha512 dset (see zfs-set(8)). The feature becomes active once a checksum property has been set to sha512, and returns to being enabled once all filesystems that have ever had their checksum set to sha512 are destroyed.

---

skein 💜

• GUID — org.illumos:skein
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — no

Turns on the Skein hash algorithm for checksum and dedup. Skein is a high-performance secure hash algorithm that was a finalist in the NIST SHA-3 competition. It gives you a very high security margin plus high performance on 64-bit hardware (80% faster than SHA-256). This implementation also uses ZFS's new salted checksumming functionality — meaning the checksum is pre-seeded with a secret 256-bit random key (stored on the pool) before the data block gets fed in to be checksummed. So the resulting checksums are unique to a given pool, which prevents hash collision attacks on systems running dedup. Iconic behaviour, ngl.

When the skein feature is set to enabled, the administrator can turn on the skein checksum on any dataset with zfs set checksum=skein dset (see zfs-set(8)). The feature becomes active once a checksum property has been set to skein, and returns to being enabled once all filesystems that have ever had their checksum set to skein are destroyed.

---

spacemap_histogram 🌸

• GUID — com.delphix:spacemap_histogram
• READ-ONLY COMPATIBLE — yes

This feature lets ZFS keep more info about how free space is organized inside the pool. If it's enabled, it gets activated when a new space map object is created, or when an existing space map is upgraded to the new format — and it never goes back to being enabled.

---

spacemap_v2 ⭐

• GUID — com.delphix:spacemap_v2
• READ-ONLY COMPATIBLE — yes

Enables the new space map encoding, which uses two words instead of one whenever that's advantageous. The new encoding lets space maps represent large regions of space more efficiently on-disk, while also bumping up their maximum addressable offset. Two birds, one slay ✨

This feature becomes active once it's enabled, and never returns back to being enabled.

---

userobj_accounting 🍓

• GUID — org.zfsonlinux:userobj_accounting
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — yes

Lets admins account object usage information by user and group.

This feature becomes active as soon as it's enabled and will never return to being enabled. Each filesystem gets upgraded automatically when remounted, or when a new file is created under that filesystem. You can also trigger the upgrade on filesystems with zfs set version=current fs. The upgrade runs in the background and may take a while on filesystems with lots of files 😭

---

vdev_zaps_v2 🔥

• GUID — com.klarasystems:vdev_zaps_v2
• READ-ONLY COMPATIBLE — no

Creates a ZAP object for the root vdev.

Becomes active after the next zpool import or zpool reguid. Properties can be retrieved or set on the root vdev using zpool get and zpool set, with root as the vdev name — which is an alias for root-0. iykyk 💅

---

zilsaxattr 🧚

• GUID — org.openzfs:zilsaxattr
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — yes

Enables xattr=sa extended attribute logging in the ZIL. If it's enabled, extended attribute changes (both xattrdir=dir and xattr=sa) are guaranteed to be durable if either the dataset had sync=always set at the time the changes were made, or sync(2) is called on the dataset after the changes were made.

This feature becomes active when a ZIL is created for at least one dataset, and will be returned to the enabled state when it's destroyed for all datasets that use this feature.

---

zpool_checkpoint 🎀

• GUID — com.delphix:zpool_checkpoint
• READ-ONLY COMPATIBLE — yes

Enables the zpool checkpoint command, which can checkpoint the state of the pool at the moment it was issued — and later either rewind back to it or discard it. Time travel but make it storage 💅

It becomes active when the zpool checkpoint command is used to checkpoint the pool. It'll only return back to being enabled when the pool is rewound or the checkpoint has been discarded.

---

zstd_compress 🌈

• GUID — org.freebsd:zstd_compress
• DEPENDENCIES — extensible_dataset
• READ-ONLY COMPATIBLE — no

zstd is a high-performance compression algorithm that combines high compression ratios with high speed. Compared to gzip, zstd offers slightly better compression at much higher speeds. Compared to lz4, zstd offers much better compression while being only modestly slower. Typically, zstd compression speed ranges from 250 to 500 MB/s per thread, and decompression speed is over 1 GB/s per thread. It's giving main character energy, fr fr.

When the zstd feature is set to enabled, the administrator can turn on zstd compression of any dataset using zfs set compress=zstd dset (see zfs-set(8)). The feature becomes active once a compress property has been set to zstd, and returns to being enabled once all filesystems that have ever had their compress property set to zstd are destroyed.

---

✨ SEE ALSO ✨

• zfs(8)
• zpool(8)

---

okay bestie that's the whole entire page, you made it, I'm so proud of you 🥹💖 go forth and zpool upgrade responsibly (after reading everything, obviously, no cap). this was the OpenZFS girlies' edition of ZPOOL-FEATURES(7), dated July 23, 2025 — mwah, drink water, back up your pools, love u 🫶✨💅