Richard Elling wrote: > I think this reveals a more interesting challenge. If the on-disk format > changes when we add features, and feature additions are represented > by incrementing the version, then we might create a reason to fork. > Perhaps we should look at having an implemented features list instead? > For example, if CZFS does not implement user quotas, then it could > just ignore them if they do not exist on the medium.
CZFS effectively does that already by returning ENOTSUP from some functions like ACL or quotas. The big issue though is that CZFS compacted some critical on disk structure like the blkptr_t, compare the CZFS blkptr at with the normal ZFS one at: http://src.opensolaris.org/source/xref/osarm/onarm-gate/usr/src/uts/common/fs/czfs/sys/spa.h#47 http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/sys/spa.h#120 That is the incompatible on disk part that is problematic, in particular it means CZFS can't support encryption because the space needed to store the IV has been taken away. It might also not be able to support bp_write since there may be a need to store additional info in the blkptr_t for "moved" blocks. The feature additions as a list could be done still and has been discussed before. -- Darren J Moffat
