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) ? 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. -- Darren J Moffat
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
George Wilson wrote:> 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.That is what I thought but as you say it is currently a little confusing. Given that I believe that for ZFS Crypto I should only be changing SPA_VERSION since adding crypto doesn''t change anything to do with ZPL. Thanks. -- Darren J Moffat
Darren J Moffat wrote:> George Wilson wrote: >> 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. > > That is what I thought but as you say it is currently a little confusing. > > Given that I believe that for ZFS Crypto I should only be changing > SPA_VERSION since adding crypto doesn''t change anything to do with ZPL.That''s correct. Generally, you would need to bump the ZPL_VERSION if a system running older bits could not correctly interpret a newer filesystem received by "zfs recv". --matt
Matthew Ahrens wrote:> Darren J Moffat wrote: >> George Wilson wrote: >>> 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. >> >> That is what I thought but as you say it is currently a little confusing. >> >> Given that I believe that for ZFS Crypto I should only be changing >> SPA_VERSION since adding crypto doesn''t change anything to do with ZPL. > > That''s correct. Generally, you would need to bump the ZPL_VERSION if a > system running older bits could not correctly interpret a newer > filesystem received by "zfs recv".That helps as a good "benchmark", particularly since for phase 1 the zfs send stream will be in cleartext not ciphertext. -- Darren J Moffat