On Sep 17, 2007 14:43 -0600, Mark Shellenbaum wrote: > >Andreas Dilger wrote: > >>0.b The ext2/3/4 format has a very clever IMHO versioning mechanism that > >> is superior to just incrementing a version number and forcing all > >> implementations to support every previous version's features. See > >> http://www.mjmwired.net/kernel/Documentation/filesystems/ext2.txt#224 > >> for a detailed description of how the features work. The gist is > >> > >>It's hard for me to comment on this without more information. I just > >>suggested the ext3 mechanism because what I see so far (many features > >>being tied to ZFS_VERSION_3, and checking for version >= ZFS_VERSION_3) > >>mean that it is really hard to do parallel development of features and > >>ensure that the code is actually safe to access the filesystem. > >> > > > >ZFS actually has 3 different version numbers. Anything with ZFS_ is > >actually the spa version. The ZPL also has a version associated with it > >and will have ZPL_ as its prefix. Within each file is a unique ACL > >version. Most of the version changing has happened at the spa level, > >but soon the ZPL version will be changing to support some additional > >attributes and other things for SMB. > > > >Sure, take a look at: > > > >http://www.opensolaris.org/os/community/arc/caselog/2007/315/ > >http://www.opensolaris.org/os/community/arc/caselog/2007/444/ > > > > Forgot to list the feature registration one. > > http://www.opensolaris.org/os/community/arc/caselog/2007/227/mail
So, after finally having had a chance to read these threads, I don't think they relate at all to what I was initially proposing. The feature registration APIs are more related to the users of the filesystem in terms of what functionality the fs provides. What I was proposing was a mechanism for ZFS internally to be more flexible in terms of forward and backward compatibility between the ZFS code and the on-disk format. The system attributes discussion may be somewhat related to the fast XATTR proposal. The document doesn't actually specify how these system attributes will be stored internally to ZFS. If they are stored in the znode, that is the best performance wise. If the system attributes are stored in an XATTR object hung off the znode->zp_xattr then this will probably be a noticable performance hit for each access. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.