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.


Reply via email to