ZFS feature flags are one of those engineering ideas that looks polite on a slide and becomes deeply personal at 03:17 when you’re trying to import a pool on the “other” host and it just refuses. They are the DNA markers of your pool: once certain traits are expressed, you can’t pretend they aren’t there. And the pool will not humor your nostalgia for older kernels, older bootloaders, or that one standby box nobody updated because “it’s just a backup.”
This piece is about portability: how to move pools between hosts, how upgrades change what a pool requires, and how to replicate safely across versions. It’s written from the point of view of someone who has watched a confident “just upgrade it” turn into a full-blown incident call, and also watched boring, careful compatibility discipline quietly save a weekend.
What feature flags are (and why they exist)
Old-school ZFS had a “pool version” number. You upgraded a pool from version N to version N+1, and that number advertised what the pool could do and what it required. It worked until it didn’t: different vendors shipped different features under the same version number, and people got pools that “should” import but couldn’t—or worse, did import and behaved strangely.
Feature flags replaced the monolithic version with a more honest model: a pool advertises a set of features, each with its own name (like feature@async_destroy or feature@encryption) and a state. Hosts advertise which features they understand. Compatibility becomes a set intersection problem instead of a single integer lie.
Operationally, feature flags matter because they are sticky. Some features are only “enabled” and harmless until used; others become “active” and change on-disk structures in a way older implementations cannot parse. Once that happens, the pool can’t be imported on a host that lacks the feature—no matter how much you promise to be careful.
Joke #1: ZFS feature flags are like tattoos: easy to get, hard to remove, and your future self may question your decisions.
The compatibility model: enabled vs active vs supported
When people say “feature flags,” they often mean “the list I saw in zpool get all.” That list is the start, not the story. The story is the state machine behind each flag and what that state implies for imports and replication.
Feature state: disabled, enabled, active
In OpenZFS terms, feature flags typically present as:
- disabled: the pool does not have the feature enabled; nothing about it matters.
- enabled: the pool knows about the feature and may use it in the future, but hasn’t necessarily written feature-specific structures yet.
- active: the pool has used the feature; on-disk structures exist that require support to read (and usually to import at all).
Not every feature behaves exactly the same, but the practical rule is: active features are the ones that strand you on older hosts. Enabled-but-not-active features can still create a problem if the target host refuses pools with unknown enabled features, but most compatibility failures happen when a feature becomes active.
Host capability: “supported” is not “enabled”
A host (kernel module + userland tooling) supports a set of features. That does not mean those features are enabled on every pool. It means the host can import pools that have those features active.
The common trap: “We upgraded the OS, so we’re compatible.” You are compatible with pools that require at most what your host supports. If you import a pool on a newer host, you haven’t necessarily changed the pool yet. But if you run zpool upgrade, or you enable certain dataset properties (like native encryption), you might have just made your pool incompatible with older hosts permanently.
Read-only imports and the myth of “I won’t touch it”
People try to save themselves with read-only imports. It can help in narrow cases (for example, to extract data from a pool with minor damage), but it is not a universal compatibility escape hatch. If the host doesn’t understand an active feature, it can’t reliably parse the pool metadata—even read-only. Feature incompatibility is not a write-safety issue; it’s a “can I understand what I’m looking at” issue.
Portability rules: the only three outcomes that matter
When you move pools or replicate between hosts, you want to predict which of these three outcomes you’ll get:
Outcome 1: Clean import (boring, desirable)
The target host supports every active feature on the pool. The pool imports normally. You can mount datasets, scrub, resilver, do all the usual things. This is the only outcome you want for production cutovers.
Outcome 2: Import refused (loud failure, often recoverable)
The target host sees one or more unsupported active features and refuses to import. This is disruptive, but it’s honest: you haven’t silently corrupted data; you’ve been stopped before doing something dangerous.
In practice, this happens when you try to import a pool upgraded on a newer OpenZFS into an older environment (older distro kernel, older appliance firmware, older rescue image). The fix is usually “upgrade the target host” or “don’t upgrade the pool in the first place.” The latter is only possible if you catch it before activating features.
Outcome 3: Imports, but other operations fail (sneaky, operationally expensive)
This is rarer with feature flags than with the old pool version chaos, but it still happens: replication streams, bootloaders, initramfs tooling, or management software may not understand new properties or default behaviors even if the kernel module can import the pool.
Examples include: boot environments that assume legacy mount behavior, recovery images lacking crypto support for encrypted root, or replication targets that accept streams but can’t properly handle large blocks or embedded data settings. The pool imports, but the ecosystem around it becomes the incident.
Joke #2: The only thing more permanent than a ZFS pool upgrade is the calendar invite for the postmortem.
Interesting facts and historical context
These are the bits that make feature flags make sense—and also explain why two boxes running “ZFS” can behave like distant cousins.
- ZFS started at Sun and shipped in Solaris; the original design baked in end-to-end checksums and copy-on-write semantics long before they were fashionable in commodity Linux storage stacks.
- Pool “version numbers” became a mess because multiple downstreams implemented features out of order or under conflicting version increments, making version-based compatibility unreliable across vendors.
- Feature flags were introduced to replace pool versions so a pool could self-describe capabilities precisely instead of via a single integer.
- OpenZFS unified divergent codebases (Illumos, FreeBSD, Linux ports) around a shared feature-flag model, but release timing still differs across platforms.
- Native encryption is a watershed feature: it’s not just a dataset property; it changes key management workflows, send/receive behavior, and disaster recovery assumptions.
- Some features activate implicitly—you don’t always run “enable feature” explicitly. Setting a property (e.g., enabling special vdev allocation classes, large_dnode usage by certain tools) can flip a feature to active.
- Boot pools are special: the kernel might import a pool fine, but the bootloader might not understand newer on-disk features. That’s a different compatibility axis most people learn the hard way.
- Replication streams encode feature requirements. Even if the source pool imports everywhere, a send stream might require target-side feature support depending on flags and properties.
- Feature flags are namespaced (often with a vendor or project prefix historically), which was a pragmatic compromise to avoid collisions while ZFS development was fragmented.
Three corporate-world mini-stories
Mini-story 1: The incident caused by a wrong assumption
They had two datacenters and a simple plan: primary ran on newer Linux, DR ran on a slightly older “stable” build because it “doesn’t do much.” Replication was ZFS send/receive. The DR box was treated like a fire extinguisher: inspected occasionally, mostly ignored.
During a routine maintenance window, an engineer upgraded the primary pool features to get a new capability they wanted for performance and snapshot handling. The change looked harmless: zpool upgrade ran cleanly, nothing exploded, and the application graphs stayed flat. The team high-fived and moved on.
Two months later, they did a DR test and discovered the receive side had been quietly failing for days. The send streams now required features the DR host didn’t support. Monitoring didn’t alert because it only watched the presence of snapshots, not the success of incremental receives. When they finally tried to import the replicated pool on DR, it refused: unsupported features. The replica wasn’t just stale; it wasn’t usable.
The recovery was unglamorous: emergency upgrades in DR, kernel and ZFS module alignment, rebuilding the replication baseline with a full send. It worked, but it cost them a weekend and burned trust. The root cause wasn’t “ZFS is hard.” It was the wrong assumption: that a pool upgrade is a local optimization, not a global compatibility event.
The postmortem action that actually mattered: they implemented a “compatibility contract” between sites—documented minimum supported feature set, pinned OpenZFS versions in both places, and a test that attempted a dry-run receive on DR before any pool upgrade in prod.
Mini-story 2: The optimization that backfired
A different company wanted faster metadata operations for a fleet of build servers. Someone read about special vdevs, metadata allocation classes, and newer block pointer formats. The pitch was compelling: “We’ll make file stats and small file workloads scream.” They rolled in new NVMe, created a special vdev, and enabled a set of features that were “recommended” by the newest OpenZFS build they used.
Performance improved immediately. Then came the backfire: the hardware refresh cycle moved some pools to older spare hosts during maintenance. Those spares ran an older OpenZFS because the vendor kernel lagged. Suddenly, pools with newly active features couldn’t be imported on the spares. Maintenance windows got longer because “just fail over to spare” became “first, upgrade spare, then rebuild initramfs, then reboot, then pray.”
Worse, they discovered the boot environment tooling on that distro didn’t like the newer feature set on the root pool, and a handful of boxes became awkward to recover. Nothing was unrecoverable, but the time-to-repair ballooned. The optimization was real; the operational cost was also real, and nobody priced it into the decision.
What they changed: they separated concerns. They stopped treating “pool feature upgrades” as part of performance tuning. They pinned boot pools to the minimum feature set supported by boot tooling, and they isolated aggressive feature use to data pools that didn’t need to boot on weird rescue environments. The build servers kept their speed; the on-call rotation kept its sleep.
Mini-story 3: The boring but correct practice that saved the day
This team ran mixed hosts: some on FreeBSD for network services, some on Linux for compute, all sharing a ZFS-based backup strategy. The environment wasn’t flashy, but it was disciplined. Every quarter, they did a “pool portability drill”: export a non-critical pool and import it on a standby host running the oldest supported ZFS stack in the fleet.
It felt like busywork until the day it paid for itself. A production host had a motherboard failure, and the fastest way out was to cable the disks into a spare machine. The spare was older and hadn’t been upgraded in months. In many orgs, that would be the start of a bad day.
Instead, the pool imported cleanly, because the team had a rule: no pool upgrades unless every host in the support matrix could import the pool, and no new features activated without a portability test. They also kept a small set of “known good” recovery images with matching ZFS support.
The incident still hurt—hardware always does—but it stayed in the category of “swap parts, import pool, resume service.” No surprise feature flags, no accidental lockout, no frantic OS upgrades under pressure. Their victory was boring, which is the highest compliment you can pay an SRE practice.
Practical tasks: commands you’ll actually run
The goal here is to give you operational muscle memory: how to inspect features, predict imports, and manage upgrades without turning them into roulette. Commands are shown with typical output fragments and how to interpret them. Adjust pool and dataset names as needed.
Task 1: Identify ZFS and zpool versions on a host
cr0x@server:~$ zfs version
zfs-2.2.4-1
zfs-kmod-2.2.4-1Interpretation: This host’s OpenZFS userland and kernel module are aligned. Misalignment (userland newer than module) can cause confusing behavior; for portability planning, you care about the module’s actual feature support.
Task 2: List pools and confirm health before you touch anything
cr0x@server:~$ zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 3.62T 1.88T 1.74T - - 18% 51% 1.00x ONLINE -Interpretation: Do not do feature work on a pool that’s degraded, resilvering, or showing I/O errors unless your goal is recovery. Upgrades don’t usually harm healthy pools, but they narrow your escape routes.
Task 3: See which feature flags exist on the pool and their states
cr0x@server:~$ zpool get all tank | grep '^tank feature@' | head
tank feature@async_destroy enabled local
tank feature@bookmarks enabled local
tank feature@embedded_data active local
tank feature@enabled_txg active local
tank feature@extensible_dataset active localInterpretation: Any active line is a hard requirement: importing this pool requires a host that supports that feature. enabled lines may become requirements later when the feature activates.
Task 4: Show unsupported features on this host (pre-check imports)
cr0x@server:~$ zpool get -H -o value unsupported@features tank
-Interpretation: A dash typically means “none.” If you see a list, you’ve got a mismatch already (for example, you imported the pool on a host that can read it but lacks some capability expected by tooling, or you’re checking on a partially compatible stack).
Task 5: Predict what zpool upgrade would do (do not run it yet)
cr0x@server:~$ zpool upgrade -v
This system supports ZFS pool feature flags.
The following features are supported:
FEAT DESCRIPTION
async_destroy Destroy filesystems asynchronously.
embedded_data Blocks which compress very well are stored embedded in metadata.
encryption Dataset level encryption.Interpretation: This shows what the current host supports, not what your pool needs. The danger move is upgrading a pool on a host that supports more than the rest of your fleet.
Task 6: Check if a pool has pending feature upgrades available
cr0x@server:~$ zpool status
pool: tank
state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not support
the features. See zpool-features(7) for details.
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
sda ONLINE 0 0 0Interpretation: This message is ZFS being helpful and dangerous at the same time. “Some features are unavailable” is not a problem; it’s a trade. The action line is the part that can strand the pool on older hosts.
Task 7: Safely check importability on a target host (without importing)
cr0x@drhost:~$ sudo zpool import
pool: tank
id: 1234567890123456789
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
tank ONLINE
sda ONLINEInterpretation: If the pool appears with a normal “can be imported” message, the target host likely supports the active features. If it complains about unsupported features, stop and fix the target host version mismatch before cutover.
Task 8: Attempt a read-only import for inspection (when you’re cautious)
cr0x@drhost:~$ sudo zpool import -o readonly=on -N tank
cr0x@drhost:~$ zpool status tank
pool: tank
state: ONLINEInterpretation: -N imports without mounting datasets. This is a safe way to inspect feature flags and properties on a target host during a migration rehearsal. It does not solve missing feature support; it only reduces the chance you alter data while inspecting.
Task 9: Confirm feature states after import on the target
cr0x@drhost:~$ zpool get all tank | grep '^tank feature@' | grep -E 'active|enabled' | head
tank feature@async_destroy enabled local
tank feature@embedded_data active local
tank feature@extensible_dataset active localInterpretation: Compare this output across hosts. If a host can import but reports oddities (missing features in tooling), you may have a userland/module mismatch or an older userland that can’t display all states cleanly.
Task 10: Identify encryption usage and key status (compatibility landmine)
cr0x@server:~$ zfs get -r -o name,property,value -s local,received encryption,keylocation,keystatus tank | head -n 12
NAME PROPERTY VALUE SOURCE
tank encryption off default
tank/secure encryption aes-256-gcm local
tank/secure keylocation prompt local
tank/secure keystatus unavailable -Interpretation: Encrypted datasets require target support for the encryption feature and key management workflows. If DR can’t load keys (or doesn’t support encryption), you don’t have DR—just expensive ciphertext.
Task 11: Test a replication receive in a safe sandbox dataset
cr0x@source:~$ sudo zfs snapshot -r tank/app@replica-test
cr0x@source:~$ sudo zfs send -R tank/app@replica-test | ssh drhost sudo zfs receive -uF tank/replica-sandboxInterpretation: This is a practical compatibility test: if the receive fails with feature-related errors, you’ll find out now rather than during an outage. -u avoids auto-mounting; -F forces rollback on the target dataset path if needed (use carefully).
Task 12: Inspect why a receive failed (look for feature requirements)
cr0x@drhost:~$ sudo zfs receive -uF tank/replica-sandbox < /tmp/stream.zfs
cannot receive: stream has unsupported feature(s)Interpretation: The stream is demanding something the target can’t do. This can be a newer feature in the send stream, or a property that requires a feature flag. The fix is usually “upgrade target OpenZFS” or “change replication mode/properties to avoid that requirement,” depending on what the stream contains.
Task 13: Freeze a pool’s portability by refusing feature upgrades (policy, not tech)
cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
pool: tank
state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.Interpretation: The “boring” move is to leave it that way. If you need to support older rescue hosts or cross-platform imports, not upgrading features is a deliberate compatibility choice.
Task 14: Perform a controlled pool feature upgrade (when you’ve earned it)
cr0x@server:~$ sudo zpool upgrade tank
This system supports ZFS pool feature flags.
Successfully upgraded 'tank'.Interpretation: This enables all features supported by this host. It may not activate them immediately, but you’ve changed the pool’s declared capabilities. Treat this as a one-way door for portability to older hosts.
Task 15: Verify boot pool constraints (don’t brick your reboot)
cr0x@server:~$ zpool list -o name,size,health,altroot
NAME SIZE HEALTH ALTROOT
rpool 238G ONLINE -
tank 3.62T ONLINE -Interpretation: If rpool is your boot pool, be conservative. A data pool stranded on older hosts is annoying; a boot pool stranded from your bootloader is catastrophic in a very specific, time-consuming way.
Task 16: Export a pool cleanly before moving disks between hosts
cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ zpool list
no pools availableInterpretation: Clean export reduces import friction and avoids “pool in use” confusion. It doesn’t change feature flags, but it does prevent stale host cache issues and makes the next import cleaner.
Fast diagnosis playbook
This is the “I have ten minutes before the meeting turns into an incident” playbook. The goal is to find whether you’re dealing with feature incompatibility, version skew, or a performance bottleneck that just looks like compatibility trouble.
Step 1: Is it a hard compatibility failure or a general import failure?
cr0x@target:~$ sudo zpool import
pool: tank
id: 1234567890123456789
state: UNAVAIL
status: The pool uses the following feature(s) not supported by this system:
com.datto:encryption
action: The pool cannot be imported. Access the pool on a system that supports
the required feature(s), or restore the pool from backup.Interpretation: If you see explicit “feature(s) not supported,” stop debugging disks and start debugging versions. This is not an I/O issue; it’s a software capability mismatch.
Step 2: Confirm what the target host supports
cr0x@target:~$ zfs version
zfs-2.1.11
zfs-kmod-2.1.11Interpretation: If the source host is on 2.2.x and target is on 2.1.x, you should assume feature mismatches are possible. Align versions intentionally; don’t hope the intersection works out.
Step 3: If import works but performance is awful, check for obvious pool stress
cr0x@target:~$ zpool iostat -v tank 1 5
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 1.88T 1.74T 120 980 8.2M 112M
sda - - 60 490 4.1M 56M
sdb - - 60 490 4.1M 56MInterpretation: If you’re bandwidth-bound or IOPS-bound during import/receive/scrub, you can misattribute “it’s stuck” to compatibility. Feature incompatibility fails fast and loud; performance issues fail slowly and ambiguously.
Step 4: Check whether a resilver or scrub is dominating the box
cr0x@target:~$ zpool status tank | sed -n '1,25p'
pool: tank
state: ONLINE
scan: resilver in progress since Tue Dec 24 22:10:01 2025
312G scanned at 1.20G/s, 58.4G issued at 230M/s, 312G total
58.4G resilvered, 18.72% done, 0 days 00:18:22 to goInterpretation: A resilver can make receives and imports “feel” broken. This is not feature flags; it’s physics. If you need speed, postpone receives or throttle competing workloads.
Step 5: If replication is failing, reproduce with a tiny stream
cr0x@source:~$ sudo zfs create -o mountpoint=none tank/_compat_test
cr0x@source:~$ sudo zfs snapshot tank/_compat_test@x
cr0x@source:~$ sudo zfs send tank/_compat_test@x | ssh target sudo zfs receive -u tank/_compat_rxInterpretation: A minimal stream helps isolate whether the failure is about the dataset’s properties/features or about the pipeline (ssh, buffering, quotas, target space).
Common mistakes, symptoms, and fixes
Mistake 1: Upgrading the pool on one host and assuming the rest will cope
Symptom: DR host refuses import with “unsupported feature(s)” or replication receive errors after a seemingly unrelated maintenance.
Fix: Align OpenZFS versions across all hosts that might import the pool. If that’s not possible, do not run zpool upgrade on that pool. Treat pool upgrades as a fleet-wide change.
Mistake 2: Treating boot pools like data pools
Symptom: System imports pool in rescue environment but won’t boot normally; or boots intermittently after enabling new features.
Fix: Keep boot pools on conservative feature sets. Validate bootloader support before enabling features. Test actual reboots, not just imports.
Mistake 3: Confusing “enabled” features with “active” consequences
Symptom: Pool imported on older host last month, now refuses after a property change or new workload.
Fix: Track which features can become active due to operational changes. When you enable a property that depends on a feature, assume it may activate immediately and change portability.
Mistake 4: Replicating without testing receives on the oldest target
Symptom: Incremental replication starts failing, but monitoring only checks for snapshots or send job exit codes get swallowed.
Fix: Implement explicit receive verification and alert on non-zero exits. Periodically perform a small end-to-end send/receive compatibility test.
Mistake 5: Thinking read-only import solves unsupported feature flags
Symptom: You try -o readonly=on and still can’t import; frustration escalates.
Fix: If the host doesn’t support an active feature, you need a host that does. Read-only only changes write behavior, not metadata comprehension.
Mistake 6: Userland and kernel module mismatch
Symptom: Weird reporting of features, properties missing, or tools behaving differently across hosts with “same version” packages.
Fix: Verify zfs version shows aligned userland and module. On Linux, ensure DKMS/kmod and userland packages match. Rebuild initramfs if needed after upgrades.
Mistake 7: Importing pools on random rescue media
Symptom: Pool won’t import during recovery, but imports fine on production host.
Fix: Maintain a known-good recovery environment that matches your production ZFS feature set. Test it quarterly. Treat recovery tooling as part of the system.
Checklists / step-by-step plan
Checklist A: Before enabling new features or running zpool upgrade
- Inventory every host that might need to import the pool (production, DR, standby, backup, rescue images).
- Record OpenZFS versions on each host with
zfs version. - On the pool, list active features:
zpool get all POOL | grep '^POOL feature@' | grep active. - On each target host, run
zpool import(with disks visible) to confirm it can at least see the pool and doesn’t complain about features. - Run a sandbox send/receive test to the oldest host in the matrix.
- For boot pools, validate reboot path: bootloader, initramfs, key loading (if encrypted), and rollback procedure.
- Only then decide whether the new feature is worth narrowing portability.
Checklist B: Migration between hosts (export/import) without surprises
- On source: confirm pool health (
zpool status), scrub status, and error counters. - On source: capture feature and property snapshot for records:
zpool get all POOL | grep feature@zfs get -r all POOL > /var/tmp/pool-properties.txt(be mindful of sensitive info)
- Cleanly export:
zpool export POOL. - On target: verify versions; ensure kernel module is loaded.
- On target: run
zpool importto check for feature complaints. - Import with
-Nfirst for inspection, then mount intentionally.
Checklist C: Replication compatibility across versions
- Identify the oldest receiver version you must support.
- Test receives with a minimal dataset (Task 5 in the playbook).
- For encrypted datasets, verify key loading workflows on receiver before you call it a “replica.”
- Alert on receive failures explicitly; don’t infer replication health from snapshots alone.
- When upgrading pool features, re-run replication tests immediately afterward.
FAQ
1) If I upgrade OpenZFS on a host, does that upgrade my pools?
No. Upgrading the software increases what the host can support. Your pools keep their existing feature states until you explicitly enable features (via zpool upgrade) or activate features indirectly (via properties/workloads that depend on them).
2) Is zpool upgrade reversible?
Practically, no. You can sometimes “avoid activating” certain features by not using them, but once a feature is active and the pool has written structures requiring it, you can’t downgrade the pool to be importable on older hosts.
3) What’s the difference between “enabled” and “active” in terms of portability?
Active means the pool is using the feature and older hosts that don’t support it will refuse import. Enabled means the pool may use it later. Enabled features can still matter, but active features are the usual hard wall.
4) Can I import a pool on an older host if I promise not to mount it or write to it?
If the host lacks support for an active feature, it typically cannot import the pool at all—read-only or not—because it can’t interpret required metadata safely.
5) Why did replication start failing after months of working?
Either the source pool activated a feature (possibly via a property change), or the send stream now includes requirements the receiver can’t satisfy. Another common cause is the receiver was upgraded/downgraded inadvertently and lost support or tooling alignment.
6) Does cross-platform ZFS (Linux ↔ FreeBSD) change the rules?
The core feature-flag logic is the same, but release timing differs. A feature that’s common on one platform might lag on another. Treat “platform differences” as “version differences,” and test imports and receives on the exact builds you run.
7) Should I always run zpool upgrade to get rid of the status warning?
No. That warning is informational, not a reliability alarm. Leaving a pool un-upgraded is a valid strategy when portability matters—especially for removable pools, DR imports, or environments with heterogeneous hosts.
8) How do I design a safe compatibility policy for a fleet?
Pick a minimum OpenZFS version that every relevant host must run. Only enable pool features that are supported by that minimum. When you need a new feature, treat it like a schema migration: upgrade hosts first, then upgrade pools last, and test DR/replication at each step.
9) What about encrypted datasets—are they compatible with send/receive everywhere?
Encryption introduces additional requirements: the receiver must support the encryption feature and your replication mode must align with your key management goals. Even when the pool imports, operational readiness depends on whether keys can be loaded and how you handle keylocation and keystatus in DR.
10) What’s the single safest habit with feature flags?
Assume that any pool feature upgrade is a portability downgrade. If you’re okay with that trade, proceed deliberately; if you’re not, don’t let a status message shame you into pressing the button.
Conclusion
ZFS feature flags are not trivia; they are your pool’s contract with every machine that might need to read it under pressure. They make compatibility more explicit than the old pool version system, but they also make upgrades more consequential: you can’t accidentally stay portable once you’ve crossed the feature threshold.
If you remember only one thing, make it this: upgrade hosts first, validate imports and receives on the oldest environment, and upgrade pools last. The teams that do this look boring in change review. They also look brilliant on the day the spare box becomes the production box.