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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 27 Nov 2007 18:15:07 -0500

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.

-----Original Message-----
From: Noveck, Dave 
Sent: Saturday, November 24, 2007 9:24 AM
To: Noveck, Dave; [email-masked]; [email-masked]
Subject: RE: [nfsv4] File types in v4.1 spec

Interestingly enough, as I've thought about documenting the file
types, this has caused some other issues to arise.  You can have
your own opinion abut whether that is a good thing or not.

For example, what does "is a directory" mean?  It seems obvious 
but consider that there are two possible meanings:

     1) Is an object of type NF4DIR.

     2) In an object of type NF4DIR or of type NF4ATTRDIR?

Clearly when we are not doing an open by handle, the fh passed
to open must be a directory in sense 2.  I assume that remove is
similar in that you can do REMOVE to get rid of a named attribute.

But what about CREATE?  If you pass an attribute directory, should
that not cause you to return NFS4ERR_WRONG_TYPE?  I'll argue that
it should.  In the past, the general view was that whether you 
supported special files, symlinks, or directories within the 
attribute directory was an implementation choice.

A number of reasons why I think this is a bad idea:

     It is inconsistent with the spec's handling of named attributes
     in general, in that there are distinct object types for 
     regular files and named attributes: NF4REG and NF4NAMEDATTR.
     BTW, neither of these type names appears in draft-17.
     If we were to allow these other object types in a named
     attribute directory, they, unlike the case of regular files,
     would not be distinguishable, in terms of object type, from
     their non-named-attribute cousins.  That's a pretty glaring
     inconsistency.

     It is just asking for interoperability problems.  Often we
     are forced, as with POSIX locking, to accommodate two 
     different implementation philosophies, which sit rather 
     uneasily together, but we do that because that's what the
     history of file system development has given us and we have
     to live with it.  But unless there are clients who currently
     need this, and I haven't heard of them, I think it is better
     to keep things in this area uniform.

     If you do allow this, then the possibilities for variants are
     just about endless.  If you can create directories under 
     the named attribute directory then you face the issues of
     whether you can rename files between them.  Also, could such
     directories have their own named attribute directory?  If
     you descend a chain of sub-directories within a named
     attribute directory, could not see the fsid change?  I know
     that's nuts, but right now I don't think the spec prohibits 
     it.

So I think we should have a simple model in which the directory
passed to CREATE must be NF4DIR, you cannot do an OPENATTR
on an object of type NF4ATTRDIR of NF4NAMEDATTR, and the 
fsid for objects of types NF4ATTRDIR or NF4NAMEDATTR must
match the parent.  I think v4.1 should be tightened up in this
regard.

So that leaves LINK and RENAME.  For LINK, my preference would
be to disallow objects of type NF4ATTRDIR as the directory 
and objects of type NF4NAMEDATTR as the object linked.  Are 
there people who need this?  If this is allowed, I think we 
should prohibit any linking between distinct named attribute 
directories, and absolutely under no circumstances should we 
allow the same object to be linked in an NF4DIR directory 
and an NF4ATTRDIR directory.  This  leaves the issue of 
what to return if these are attempted. If you try one of 
the prohibited operations, I would say a somewhat expanded 
definition of NFS4ERR_XDEV makes sense and if you try 
something that is allowed in the protocol but the server
doesn't support it, the return should be NFS4ERR_NOTSUPP.

For RENAME, I assume that it is allowable to rename a named
attribute without moving it to a different directory.  Does
anybody have trouble implementing that?  Again, I would 
prohibit renaming between different named attribute 
directories and think we absolutely must prohibit renaming
between the two types of directories.

-----Original Message-----
From: Noveck, Dave 
Sent: Friday, November 23, 2007 2:28 PM
To: [email-masked]; [email-masked]
Subject: RE: [nfsv4] File types in v4.1 spec

I'm not saying that the RFC should have every line of the .x file.

In particular, the numeric values of the NF* constants aren't really
needed.  I do think that having the set of possible values that the type
can have is important.  Where we introduce the concept of the file type,
I think it makes sense to say what file types there can be. 

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]]
Sent: Friday, November 23, 2007 1:47 PM
To: Noveck, Dave; [email-masked]
Subject: Re: [nfsv4] File types in v4.1 spec

--- "Noveck, Dave" <[email-masked]> wrote:

> Currently the values of the file type attribute (NF4*) do not appear 
> in the spec, but are referred to all over the place.  While you can 
> argue that the actual values are more appropriate to the dotx, having 
> all the valid values in one place would definitely help understanding.

> Note that "NF4REG" does not appear at all in draft-17.  I guess the 
> right place to put this is the section on the type attribute,

I don't object, but wonder if the RFC should have every line of the .x
file (which is now in a separate i-d, intended to be a separate RFC) in
it. There are arguments either way, but if the consensus is that the
spec i-d should have all of .x file's content, time is running out to do
that.

_______________________________________________
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: Spencer Shepler <[email-masked]>
Date: Tue, 27 Nov 2007 23:29:34 -0600

> 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

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 28 Nov 2007 08:33:03 -0500

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 :-).
>
> saved fh is the associated attribute dir, it may return 
> NFS4ERR_NOTSUPP, even if LINK is otherwise supported for the file 
> system.
>

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

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 28 Nov 2007 09:57:27 -0600

> where named attributes are discussed.

Yes, this is what I had in mind.

Spencer