I'll defer to anyone who knows more, but this is my experience and understanding.
Many feature flags don't actually change things much. They enable features. If the feature flags aren't upgraded on a pool, then that pool remains guaranteed not to be using those features, and also guaranteed to remain usable (R/W) by older and forked versions of ZFS as used in previous releases or other *nix platforms. If you enable a feature, the pool ceases to be importable by other versions of ZFS that don't support the feature, whether it's actually being used or not.
You don't ever have to upgrade the feature flags for ZFS to work. All that'll happen if you don't, is that the pool will have those features disabled on it, when ZFS is doing things.
So enabling spacemap_v2 will tell ZFS it can use a more modern efficient type of spacemap to manage free space, which allows long objects to be included, but leaving it disabled just means ZFS won't use those, and will stick with short free space records, which other older versions of ZFS or other less featured platforms can also read.
That means you don't ever *
have* to upgrade features. Indeed you can choose which to upgrade and which not, if you don't like some, or need to be able to transfer your pool to a system running FreeNAS 8.x or whatever.
But on the whole, the main reason for leaving features not upgraded is compatibility, not trust/reliability/"will it be okay". If you aren't ever going to go back to some older version of FreeNAS or some other platform running older ZFS anyway, then there isn't a need to keep the features disabled which that version of ZFS wouldn't recognise. It's that simple.
You don't really need to be "paranoid" of new feature flags as such. Really the issue is, which versions of ZFS/FreeNAS/*nix do you want to ensure you remain compatible with, because it's still conceivable you might move/revert your pool to them in future. Paranoia is not really merited beyond that. The feature flags are (or seem to be) very robust, and several of them may make *huge* differences to your pool's speed and efficiency.
Even if you won't use them, there's almost never harm in enabling anyway. Feature flags divide into 2 groups. Some, ZFS will automatically use because they are more efficient or faster (eg log_spacemap). Others, will only be actually used, if you yourself choose to use that feature (checkpoints, special vdevs etc). So you don't really have to cherrypick and wonder which to go for. Enable all, use the features you choose as you need them.
Last, be aware some features will only shine after existing data is rewritten, because existing already-written data won't be moved round and recoded on disk to reflect your flags if you do upgrade the feature flags. For example you could enable the "special vdevs" feature, but it'll only speed up new data created after that point, because your existing metadata and spacemap data won't be automatically moved to the new fast vdevs. For that, you need to rewrite the old data (usually with send/recv/replication).
I've added a list of current 12-beta flags below and some comments what they do, for reference. Meantime have some "personal story" about upgrading flags to 12-beta. It may help.
My own experience:
A personal case study might be one-off but might give an idea. I needed wanted to use a particular feature badly because dedup was grinding, and needed it badly enough to consider early moving to 12 even at beta.
This is usually a Very Bad Idea Indeed, but I
asked the devs what they felt about safety and was told they thought it was pretty solid against data loss with no reports of pool loss, and so I've found it: 12-BETA1/2 have annoyances rather than blockers for me, but have basically been rock solid for data safety, even as betas).
I imported my "live" pool onto 12.0-BETA1 and left its feature flags unchanged so I could revert to 11.3 if there were issues. I then added enough disks to make a duplicate of it, with all the 12.0 flags enabled, to ensure that when replicated it would have all data stored optimally using the new features - a lot of flags only affect newly written data, they don't change how existing data is stored. (For that you need to remake the pool). By BETA2 I was confident enough to upgrade my old pool to the new flags as well, and rebuild that back from the copied pool, because I wasn't realistically ever going back to 11.3 based on my experience of 12 even at beta stage.
To give some ideas what motivated that decision, in moving from 11.3 to 12.0-BETA2 with a deduped pool, I've used special vdevs, and the new sequential resilver/scrub handling. And this is what I got:
- Pool replication (40 TB data deduped down to 14 TB): 8 days down to < 24 hours
- Scrub/resilver: 1.5-2 days down to < 12 hours
- Large scale "snapshot destroy -r" (~ 15k snaps as a script of thousands of destroy -r NAME), several a second rather than ~ 5-30 sec each
- Deleting large directories from Windows via SMB, 600~1000 files/second deleted (!!!) vs stalling ("calculating...") behaviour on 11.3.
- Local and SMB file moves/copies 300-400 MB/sec rather than slow with stalls and breaking pipes - that's because dedup makes *massive* demands on 4k IO and under 12-beta I can put that data on SSD and leave everything else on HDD. My SSDs on 12-beta are pulling 1/4 million IO's per second when busy, which is why 11.3 was stalling, with dedup data on HDD it just couldn't keep up. 12-beta can.
I think you can see why I felt I *had* to move early. I should emphasise that if I wasn't using dedup, those wouldn't be as compelling, because dedup adds huge demands that 11.3 struggled with. So you may not see my specific gains.
But you wanted reasons to calm "paranoia" and that's the best I can give. Under huge load it's just... gorgeous... for me, with the new features that 12-beta has enabled. Not an issue whatsoever, no need for my pool to have a backup compatible with 11.3 and not doing so frees it from real issues 11.3 couldn't handle.
Full list of feature flags for 12-BETA2:
You can check what features are available on your system and which of them are not yet enabled ("disabled"), enabled or in use ("active") on your pools with this command: "
zpool get all POOL_NAME | grep feature | sort
". This is a full list, so many of these also existed on some older versions.
- allocation_classes (ability to move metadata, and optionally dedup data and small files, off the pools HDDs onto dedicated high speed SSD vdevs reserved just for that purpose)
- async_destroy (allows background processing of destroy)
- bookmarks, bookmark_v2, redaction_bookmarks, redacted_datasets, bookmark_written (bookmarks and also redaction: ability to remove sensitive data when replicating with send/recv, eg for others to use a copy of it)
- device_rebuild
- device_removal (ability to remove top level vdev subject to certain conditions)
- embedded_data
- empty_bpobj
- encryption (native encryption)
- extensible_dataset
- filesystem_limits
- hole_birth
- large_blocks
- large_dnode
- livelist
- lz4_compress (and ZSTD on 12-RC1 when released) (compression algorithms - I'm adding zstd because that'll be in 12.0 rc1 but it's not yet in 12-beta2. ZSTD is said to be much more efficient and fast compared to the current "best choice" compression algorithm, as it's designed specifically to do a good job on the kinds of data seen and compressed at block level in a filing system not just general purpose compression uses.)
- multi_vdev_crash_dump
- obsolete_counts
- project_quota
- resilver_defer (ability to allow/prevent multiple resilvers running in parallel)
- sha512, skein (hashing algorithms)
- spacemap_histogram, spacemap_v2, log_spacemap (speed/efficiency improvements to free space processing)
- userobj_accounting
- zpool_checkpoint (ability to take an entire pool "snapshot" to revert changes to pool structure that wouldn't be preserved or roll-back-able, using ordinary zfs snapshot)
- _txg