Guess the mechanics of the jive interface still don't quite work, so forwarding this comment from Richard L Hamilton:
-------- Original Message -------- Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack Date: Fri, 01 Jun 2007 04:35:38 -0700 (PDT) From: Richard L. Hamilton <[email protected]> To: opensolaris-arc at opensolaris.org > > > > 2.0 OVERVIEW > > > > The Solaris CIFS project requires file system > support for a > > number of > > "system" and opaque file attributes. For file > systems that fully > > support CIFS, the system attributes will be > present on all file > > system objects and the file system will need to > update the > > attribute(s) as a result of various file system > operations such as > > data written to a file. The CIFS server and > application programs > > will also need to be able to query/update the > attributes when > > needed. Additionally, the CIFS server will be > using the Solaris > > extended attribute model for storing a number of > opaque file > > attributes. ZFS will be the primary underlying > file system for the > > CIFS server. > > > > In order to accommodate the existing extended > attribute aware > > utilities in Solaris, the new attributes will be > exposed via the > > existing Solaris extended attribute model. The > new attributes will > > be grouped in a number of SUNWattr* files that > will have multiple > > attributes in a single file composed as a packed > nvlist. Since all > > I assume the attributes will be XDR packed. > > > > 4.3.1 NFSv4 Support for Optional Attributes > (Potential Future Work) > > > > The NFSv4 protocol has an attribute model that > supports extensions. > > In fact, two of the new attributes (ARCHIVE and > HIDDEN) are part of > > the "recommended" list of attributes for a client > and server > > and SYSTEM > > > implementation. The Solaris NFSv4 client and > server could be > > modified to support the new, optional attributes > as specified by > > the protocol. Has the storage overhead of multiple extended attribute "files" associated with every filesystem object been considered? Or the impact of multiplying the total namespace (of file and attribute names) on the directory handling facilities of the OS? Seems to me that everything the CIFS server needs should be packed into at most a single extended attribute "file" per object. On the other side of things, maybe fsattr(5) (at least as of the SXDE version of the page on docs.sun.com) ought to update its references to mention something more current than the NFSv4 draft standard. This message posted from opensolaris.org _______________________________________________ opensolaris-arc mailing list opensolaris-arc at opensolaris.org
