Based on some of the questions we've gotten and the discussions we've
had, the project team has realized that there is some confusion that we
need to clear up. Our apologies for not realizing this sooner and for
not explaining this well enough in the original spec.
There are three distinct types of file attributes:
- Standard file attributes are the file attributes that are returned
with the stat(2) system call.
- Extended attributes as described by PSARC 1999/209 Extended File
Attributes
- Extensible system attributes as described by this case.
There are two specific, intentional areas where the interfaces that
deal with extensible system attributes overlap with the other two
types:
* Standard file attributes and the extensible system attributes are
retrieved and set using VOP_GETATTR() and VOP_SETATTR()
respectively. It's the xvattr_t which allows extensible system
attributes to be retrieved and set through the VOP_GETATTR() and
VOP_SETATTR() interfaces.
Section 4.3 of the spec describes these interfaces.
* Extensible system attributes can be viewed through two special
extended attribute files: SUNWattr_ro and SUNWattr_rw.
Section 4.1.1 of the spec has a list of which attributes are
viewable via SUNWattr_rw vs. SUNWattr_ro.
Any additions to the extensible system attributes (whether from Sun
project teams or Opensolaris project teams) will be retrieved and
manipulated by the same interfaces being proposed here. Specifically:
- Extensible system attributes can be retrieved via fgetattr() and
getattrat().
- Extensible system attributes can be modified via fsetattr() and
setattrat().
- Extensible system attributes are retrieved and set using
VOP_GETATTR() and VOP_SETATTR() respectively.
- Extensible system attributes can be viewed through two special
extended attribute files: SUNWattr_ro and SUNWattr_rw.
The project team that proposes any new extensible system attributes
must take full responsibility for the following:
- Updates to fgetattr()/getattrat()/fsetattr()/setattrat() library
functions and the appropriate header files.
- Updates to the xvattr_t/xoptattr_t structures and the appropriate
header files
- Updates to the xattr facility to support these new attributes in
SUNWattr_rw and SUNWattr_ro.
- Working with the utilities team to decide which (if any) commands
need to change and what those changes are.
Since the extensible system attributes are available through the
SUNWattr_rw/SUNWattr_ro views, then the changes to archiver tools
should be minimal (depending on the semantics of the new attributes).
One note on potential future work: It's possible that future projects
might propose other views as different needs arise. This project team
sees the SUNWattr_rw and SUNWattr_ro extended attribute files to be
sufficient for the current needs.
Reponses to Don's questions are inline below...
Don Cragun wrote:
> Mark,
> Parts of the following comments were answered during our discussion
> this afternoon. Others came up when I went back and looked at the
> proposal again after our discussion. I think it may help to have
> responses on file in the case directory...
>
>> On Fri, 08 Jun 2007 11:38:35 -0600, Mark Shellenbaum wrote:
>>> Don Cragun wrote:
> ... ... ...
>> This case is specific to system attributes.
>
> I'm confused.
>
> If this case is specific to system attributes, why does it start by
> saying ``The Solaris CIFS project requires file system support for a
> number of "system" and opaque file attributes.'' Aren't the opaque
> file attributes in this case CIFS project-related non-"system"
> attributes?
>
Unfortunately, the comment about opaque file attributes was left over
from a previous document which likely led to unnecessary confusion.
The CIFS server will use the extended attribute facility or "opaque"
attributes for named streams.
Two special extended attribute files can be used as a view into the
extensible system attributes: SUNWattr_rw and SUNWattr_ro. Aside
from that specific overlap, extended attribute and extensible system
attributes are two different types of attributes.
> The way I read the case, opaque attributes are not necessarily "system"
> attributes. Furthermore, the commentary on this case has stated that
> "the system attributes will be present on all file system objects" on a
> ZFS file system, but strongly implies that opaque attributes will not
> be present on every file system object.
>
Yes, except that if a file has extensible system attributes then the
SUNWattr_rw and SUNWattr_ro extended attribute files will be available
since they will be the views into the extensible system attributes.
>> Except for exposing the two extended attribute files (SUNWattr_rw and
>> SUNWattr_ro) which are really views into the optional system attributes,
>> the project team does not desire to change any of the policy from PSARC
>> 1999/209 (Extended File Attributes).
>>
>>>> Also, please see section 4.4 Managing Change in the Attribute Space.
>>>>
>>>> As for displaying the attributes via 'ls', there is a separate
>>>> effort by the Utilities Group to tackle this problem. There are
>>>> two things that this project team can suggest:
>
> I know. I'm working with that team and I'm not sure they have enough
> information to successfully complete the changes needed to support the
> "extensible" part of this project.
>
Good. For the record, the members of this team have also been working
closely with the utilities team.
>>>> - Project teams that propose new system attributes are responsible
>>>> for all aspects of those attributes. Including the decisions on
>>>> whether or not they are set by a user-level API and whether or not
>>>> they are displayed by ls(1) or any other utility.
>>>>
>>>> This project team cannot predict what future attributes will be
>>>> proposed.
>>>>
>>>> - The Utilities Team may choose to take advantage of the nvpair
>>>> format returned by fgetattr(). This will allow them to format
>>>> and display (name and value) all available system attributes.
>
> Not unless this case is setting a precedent requiring that all future
> "system" attributes be implemented using nvpairs and that the headers
> describing all new system attributes must be available to utilities
> built in the ON consolidation. It also requires that updated versions
> of these utilities be available everywhere on a network when new
> system attributes are added to any filesystem on the network... ;-{
>
All future system attributes will be available as nvlists of nvpairs
through the views provided by the SUNWattr_rw or SUNWattr_ro view
extended attribute files, as appropriate.
Should the utilities team choose to take this direction (separate, but
related case) then clearly the utilities would be able to read and
display all of the extensible system attributes on a file. They would
not necessarily be able to SET those attributes since there may be
semantics associated with the new attributes for which the utilities
may need to be aware of. The team feels this is the best that can be
expected of the project.
>>> This case should be providing the basic infrastructure to enable
>>> extensible attributes to be used correctly. It seems to me that this
>>> project is incomplete for two reasons:
>>> 1. it doesn't provide a mechanism for extensible attributes to
>>> identify themselves, and
>> See the fgetattr.3c man page in the materials directory. Specifically
>> "Example 1".
>>
>> fgetattr() returns an nvlist_t which is composed of nvpair_t's of all
>> the system attributes supported by this file system. The application
>> can then iterate through each nvpair in the nvlist and use the
>> interfaces in the nvpair library to determine the name, type, and value
>> of the attribute(s).
>
> Maybe. It does for now, but I see nothing in this case that requires
> that future system attributes be stored as nvpairs, reside in one of
> the two new attribute files created by this project, nor that they be
> retrievable and settable by f[gs]etattr() and [gs]etattrat(). 1999/209
> created extended attributes; this case creates more extended
> attributes. I don't see any guarantees that the next set of extended
> attributes is required to, nor will be able to, use the same mechanism
> presented here.
>
The clarifications in the first part of this response should clear this
confusion up.
One other point to make clear: The extensible system attributes are
not stored in an extended attribute. They are stored in the file
system and can be *viewed* as an nvlist of nvpairs through
SUNWattr_rw/SUNWattr_ro.
> ... ... ...
>
> You also seem to have tripped over one of my pet peeves from 1999/209
> again. This case adds system attributes that clearly are intended to
> modify the behavior of operations on directories, but you repeatedly
> state that these extensible system attributes are only associated with
> "regular file"s. Since a directory is a file of type directory, it is
> not a regular file. (Symlinks, sockets, doors, block-special, and
> character-special files aren't regular files either.)
>
Point taken. We'll update the spec to be more precise.
To be clear, there are two file types to which the extensible system
attributes apply: regular and directory files.
> The new SUNWattr_ro and SUNWattr_rw attribute files are regular files.
> You explicitly state that "recursive system attributes (sysattrs on
> sysattrs) are not allowed", but there is no way for the utilities to
> know which attribute files found in the alternate address space are
> describe sysattrs and which describe other extended attributes other
> than by being patched every time a new system attribute is created. I
> would have thought that an "extensible" set of new attributes would
> include a way for applications to determine at run time (without being
> rebuilt) which attribute files describe sysattrs, what the names of the
> attributes are (without reading a header), and how to process sysattrs
> so that archive creators and restorers could work without modification
> when new attrs are added later. Clearly, I was hoping for too much. 8-{
>
>
Regardless of how many new system attributes are added, the only two
extended attribute files needed to view them are SUNWattr_rw and
SUNWattr_ro.
As mentioned previously other projects may propose alternate views in
the future, but this project team sees the SUNWattr_rw and SUNWattr_ro
extended attribute files to be sufficient for the current needs.
-Mark
