Darren J Moffat wrote: > I'm looking for some guidance on when it is appropriate to increase the > SPA and ZFS version numbers. > > Currently for ZFS Crypto I've only increased the SPA version number and > I'm using spa_version() in a few places - probably a few more are needed > though. > > What are the guidelines for when the SPA and ZFS version numbers should > be increased ? Are there cases when a single feature might need to > version both (could ZFS crypto be such a feature) ?
This can be confusing since we used to have just the ZFS version and it's now the been renamed to the SPA_VERSION_*. And we have some new properties that are still using the ZFS_VERSION naming convention which should be fixed (see CR# 6582755). New code should either update the SPA_VERSION whenever you change the on-disk format and/or the new ZPL_VERSION whenever you change the Posix layer. There maybe cases where you have to update both. > > Also is there anything special about how the ZFS_PROP_VERSION property > of a dataset is written out ? This is related to my previous question > about the ARC flush on zfs umount. I've discovered that while a pool is > imported I can mount and umount and even scrub and crypto datasets work > just fine. However after I export and reimport I have trouble reading > the ZFS_PROP_VERSION for encrypted datasets - but no problem with other > properties it seems. The result of this is that 'zpool status' shows an > error 'tank/home/darrenm:<0x0>' (where darrenm has > encryption=aes-256-cbc). Using DTrace I discovered that dbuf_read() to > get ZFS_PROP_VERSION is failing with EIO. I'm not sure what you mean by special. This is just an entry in the ZAP object stored int the master node. You can dump this out using 'zdb -ddddd <dataset> 1'. Thanks, George > > -- > Darren J Moffat > _______________________________________________ > zfs-code mailing list > zfs-code at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-code
