Are you running OpenZFS 2.3.0 software now?
And just want to upgrade your pool features?
Their have been many changes to OpenZFS since 0.8 release. A few OpenZFS releases introduced corner case bugs, but later releases fixed them. If you are using 2.3.0 of OpenZFS software, you have all the known fixes.
A pool upgrade can be done live, (like most ZFS actions). It may take a few seconds to a minute to upgrade your pool(s).
One suggestion is not to enable all the features on your pools that are available with OpenZFS 2.3.0 because whence you do that, you can’t go back. Figure out which feature(s) would benefit you directly, and which OpenZFS release introduced it. Then decide if you want to update the pool to require that minimum release. You can then enable only that specific feature instead of all of them.
Their is a new feature called block cloning. It is like a hard link file, with copy on write. It can span across ZFS Datasets, but must be in the same pool. A simple local copy can use it, (if the pool feature “block_cloning” is enabled), and this can save space. However, if you are not expecting this behavior then someone can make a mistake in free space management.
Meaning if a large file is block cloned copied, it takes little space, (just for the Metadata). But, if that file is later changed, it may suddenly take up it’s full amount of space. So 2 x 50GByte files that are block cloned, take up 50GBytes. But, if one is changed completely, they then take up 100GBytes of space.
Yes, it’s confusing. Worse, if just a few ZFS records are changed, then the 2 x 50GByte files might take up 51GBytes. So, this is similar to snapshots and clones. But, at the file level and across Datasets.