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?
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.
>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.
>>>
>>> - 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... ;-{
>>
>> 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.
... ... ...
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.)
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-{
>
> -Mark
