Subject: [nfsv4] Question on named attributes

From: Thomas Haynes <[email-masked]>
Date: Tue, 11 Nov 2014 21:48:32 -0800

The Gen-art LC review asked:

> s15.16.4: LOOKUPP is said to return the parent directory of a named attribute directory. Arguably a named attribute directory doesn't have a parent... so does LOOKUPP return the directory in which the object to 'owning'  the named attribute directory resides?  Or does it return the owning object?  Please clarify in the text.

In reading the text, I take it to mean that directory of the owning object.

Any other interpretations?

Anyone implement this? :-)

---

From: David Noveck <[email-masked]>
Date: Wed, 12 Nov 2014 07:37:16 -0500

> Anyone implement this? :-)

I'm pretty sure Solaris and NetApp do, but I don't have any details.

Dell FluidFS's NFSv4 implementation does not support named attributes so
I'm unable to report on implementation behavior.

> In reading the text, I take it to mean that directory of the owning
object.

That seems plausible, but there are filesystems in which it is hard to go
from a (for example) regular file to the encompassing directory (hard links
make this difficult).

You could argue that a  "a named attribute directory doesn't have a
parent".  Since the spec says  "If there is no parent directory an
NFS4ERR_NOENT error must be returned", you might return NFS4ERR_NOENT.

I can't see that returning the ownng object is valid. If so, it would be
the only case in which LOOKUPP would set cfh to be something that wasn't a
directory.

I'm not sure what our time frame is here. If the Solaris and NetApp
implementers respond promptly and say the same thing, we put that in. If
not, we could write:

In the case in which the current file handle is a named attribute
directory, the server MAY return the error NFS4ERR_NOENT and MAY return
NFS4_OK, setting the current file handle to a directory in which the owning
object is located. Because of this uncertainty, clients should not depend
on any particular implementation of LOOKUPP in this case.

This could get the issue off our plate for now and does allow us to do an
errata once all the the implementation information is in. It would be easy
to get the needed info at Connectathon.

On Wed, Nov 12, 2014 at 12:48 AM, Thomas Haynes <
[email-masked]> wrote:

> > s15.16.4: LOOKUPP is said to return the parent directory of a named
> attribute directory. Arguably a named attribute directory doesn't have a
> parent... so does LOOKUPP return the directory in which the object to
> 'owning'  the named attribute directory resides?  Or does it return the
> owning object?  Please clarify in the text.
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Tom Haynes <[email-masked]>
Date: Wed, 12 Nov 2014 13:35:20 -0800

Ahh, 5661 says this on the subject:

   If the current filehandle is a named attribute directory that is
   associated with a file system object via OPENATTR (i.e., not a sub-
   directory of a named attribute directory), LOOKUPP SHOULD return the
   filehandle of the associated file system object.

> On Nov 12, 2014, at 4:37 AM, David Noveck <[email-masked]> wrote:
> 
> Dell FluidFS's NFSv4 implementation does not support named attributes so I'm unable to report on implementation behavior.
> 
> That seems plausible, but there are filesystems in which it is hard to go from a (for example) regular file to the encompassing directory (hard links make this difficult).
> 
> You could argue that a  "a named attribute directory doesn't have a parent".  Since the spec says  "If there is no parent directory an NFS4ERR_NOENT error must be returned", you might return NFS4ERR_NOENT.
> 
> I can't see that returning the ownng object is valid.  If so, it would be the only case in which LOOKUPP would set cfh to be something that wasn't a directory.
> 
> I'm not sure what our time frame is here.  If the Solaris and NetApp implementers respond promptly and say the same  thing, we put that in.  If not, we could write:
> 
> In the case in which the current file handle is a named attribute directory, the server MAY return the error NFS4ERR_NOENT and MAY return NFS4_OK, setting the current file handle to a directory in which the owning object is located.  Because of this uncertainty, clients should not  depend on any particular implementation of LOOKUPP in this case.
> 
> 
> This could get the issue off our plate for now and does allow us to do an errata once all the the implementation information is in.  It would be easy to get the needed info at Connectathon.
> 
> On Wed, Nov 12, 2014 at 12:48 AM, Thomas Haynes <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
>