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. -- richard
Darren J Moffat wrote: > I notice from the release notes that ZFS has been changed in an > incompatible way. This concerns me deeply and I hope that the ARM > porting team can be convinced to reverse this change to ensure that > the ZFS in the ARM port is fully on disk compatible with the SPARC, > Intel, etc ports of ZFS on OpenSolaris and other operating systems. > > I can fully understand the need to reduce the in RAM impact of ZFS I > can even understand why being able to compile out certain features is > desirable but what I don't understand is why the on disk format was > changed. What is actually being gained by this and why is it so > important for ARM ? > > I see from looking at the code changes a completely new filesystem > 'czfs' type was created does this mean that the ARM port supports CZFS > and ZFS ? > > My concern here is that the changes could make it difficult for adding > encryption to the ARM port if it can't use the normal ZFS - in > particular the encryption support needs to take the 3rd DVA to store > the IV and the upper two 64bit words of the checksum for the crypto > MAC. However aside from encryption also I'm very concerned about being > able to remove drives (encrypted or not) from a system running the ARM > port and read them on SPARC or Intel running default OpenSolaris. > > Is there a document somewhere I can read about the design choices for > CFS, particularly the on disk changes ? >
