Subject: RE: [nfsv4] File types in v4.1 spec

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 2 Dec 2007 16:45:39 -0500

I haven't seen any other responses, so I'm going to assume this is OK
with people and will make the spec changes and check them in. 

-----Original Message-----
From: Noveck, Dave 
Sent: Wednesday, November 28, 2007 8:33 AM
To: Spencer Shepler
Cc: [email-masked]
Subject: RE: [nfsv4] File types in v4.1 spec

I can write that.  I think what will work best is a short mention in
chapter 1 with an xref to a longer explanation of the changes from v4.0
where named attributes are discussed. 

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, November 28, 2007 12:30 AM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] File types in v4.1 spec

On Nov 27, 2007, at 5:15 PM, Noveck, Dave wrote:

> Here's a concrete proposal for people to throw stones at (or salute 
> for its brilliance :-).
>
> OPENATTR on an object of type NF4ATTRDIR or NFS4NAMEDATTR returns 
> NFSERR_WRONG_TYPE.
>
> CREATE where the current fh is of type NF4ATTRDIR returns 
> NFS4ERR_WRONG_TYPE.
>
> If LINK is called when the current fh is of type NF4NAMEDATTR and the 
> saved fh is not the associated attribute dir, it returns NFS4ERR_XDEV.
>
> If LINK is called when the current fh is of type NF4NAMEDATTR and the 
> saved fh is the associated attribute dir, it may return 
> NFS4ERR_NOTSUPP, even if LINK is otherwise supported for the file 
> system.
>
> If RENAME is called and current and saved fh's are different and at 
> least one is of type NF4ATTRDIR, it returns NFS4ERR_XDEV.

These changes are fine with me.  Given the "significant" change from
4.0, I would suggest a description of these changes and impact be added
to the introduction.

Spencer

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 9 Dec 2007 13:50:40 -0500

I've been working on the associated spec changes and have come upon the
following, kind of strange text and I wanted to make sure that my view
of this matches those of others. 

So the text in question is as follows (with my notes and questions
interpolated):

>       may then be examined or changed by normal READ and WRITE and
CREATE

CREATE?  I'm thinking that CREATE should go and the current text
mentions CREATE as the only way to create an object and doesn't
mention OPEN for example.

What's going on??

Note that NF4NAMEDATTR is not allowed in CREATE.  Is there anyone out
there who thinks that this (rather than the text above) is in error?
Are there:

    Clients who use CREATE to create a named attribute?

    Servers who allow CREATE to create an object of type NF4NAMEDATTR.

Or are people doing an OPEN create passing the attribute directory as
the cfh?  That's what I would expect.

>       operations on the filehandles returned from READDIR and LOOKUP.

Note that OPEN is not mentioned.

And if there is support for OPEN create, are any clients trying to read
attributes directly, without an open, using special stateids.  The spec
is indicates that you should do an OPEN to get the filehandle although I
guess someone could argue that the text doesn't explicitly mention named
attributes.

>       Named attributes may have attributes.

How do people interpret "may have" attributes?  Can the server not
provide support for GETATTR, even for mandatory attributes?  What about
recommended ones?  It is hard to understand how people could work with
named attributes without the size attributes being provided, but is the
model that named attributes are like files and have the normal set of
attributes, named attributes excluded?

What about the named attribute directory?  I assumed that it had a
normal set of attributes but the spec doesn't address this explicitly.

Can a server not have modify_time for a named attribute or share it with
the base object?  In the base of "change" the spec talks about a change
in the "attributes" which isn't clear about "named attributes".

It seems as if, named attributes, which look pretty much like files in
special directory, could have, at least in typical implementations, the
same sorts of attributes that typical files and directories have.  BTW,
the spec does say anything about attribute directories having
attributes.

On the other hand, ACLs on named attributes and named attribute
directories start getting into a fairly weird zone.

So here is my proposal to replace the stuff quoted above.  We need to
get a consensus on this.

      These attributes are not supported by direct encoding in the NFSv4

      protocol but are accessed by string names rather than numbers and 
      correspond to an uninterpreted stream of bytes which are stored 
      with the file system object.  The name space for these attributes 
      may be accessed by using the OPENATTR operation.  The OPENATTR 
      operation returns a filehandle for a virtual "named attribute
      directory" and further perusal and modification of the name space
may 
      be done using operations that work on more typical directories.
In
      particular, READDIR may be used to get a list of such named
attributes
      and LOOKUP and OPEN may select a particular attribute.  Creation
of
      a new named attribute may be the result of an OPEN specifying file
      creation.

      Once an OPEN is done, named attributes may be examined and changed

      by normal READ and WRITE operations using the filehandles and
stateids
      returned by OPEN.

      Named attributes and the named attribute directory may have  
      their own (non-named) attributes.  Each of objects the must have
all 
      of the mandatory attributes and may have additional recommended 
      attributes.  However, the set of attributes for named attributes 
      and the named attribute directory need not be as large as, and
      typically will not be as large as that for other objects in that 
      file system.
      
I'll be sending out a separate message on the issue of delegations and
named attributes, which I don't see being addressed in RFC3530.  There
are three sorts of approaches:

     Named attributes are attributes and are covered by delegations of
the object for which they are the attributes.

     Named attributes are separate file system objects  and are covered
by delegations for those objects.

     Some combination of the two.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, November 28, 2007 12:30 AM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] File types in v4.1 spec

Spencer