Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES

David.Robinson@Sun.COM

Date: Fri, 17 Dec 2004 10:53:27 -0600
From: David Robinson <David.Robinson@Sun.COM>
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-id: <41C30F07.103@Sun.COM>

Gordon Waidhofer wrote:

> The rub is that the names of many things bear
> superficial resemblence even though the underlying
> mechanisms are disperate.
> 
> Solaris "Named Attribute" is a terrific implementation
> of named subfiles, or named streams. Capacity of
> a named subfile is unlimited. Content is opaque.
> Access is through read/write.
> 
> Linux, FreeBSD, et al, have "Extended Attributes".
> The interface, getxattr(), is really like ioctl()
> using a textual name rather than a small integer name.
> Capacity is small and usually (should be) defined
> by the system. Content is non-opaque. Access is
> through get/set style interface.

There are a couple different issues with trying to
map the Solaris "subfile" extended attributes to
NFSv4 and mapping Linux get/setxattr. From the
protocol perspective we can layer a getxattr
on to NFSv4 with a pretty straight forward compound:

{PUTFH ffh, OPENATTR, LOOKUP "foo_attr", READ 0,4096}

and a setxattr is the obvious use of WRITE. A smart server
could easily optimize this to whatever underlying
interfaces they have.

So the syntax we have over the wire are probably good enough.

The interesting part we need to figure out is if we can
effectively map the common attr model semantics reasonable?

The generality of subfiles provides a lot of flexibility
which we generally would not want to restrict. But when
trying to map the simplier getxattr we will need to define
some convention, otherwise we will get multiple similar but
incompatable implementations. Bruce's example of 3 servers
is exactly to the point.

When it comes to interpretation of named attributes,
the early concensus was that the WG didn't know enough
to feel like they could adequately define a proper set.
I think the biggest error we made was to not define
a mechanism to allow interpreted named attributes to
be specified.  An obvious approach would be to reserve
a 5 byte leading prefix such as the stock symbol approach
many interfaces use, with the special prefix "IETF:"
indicating it is standard. As to encoding, a
published definition is a necessity as XDR is not
self-describing and I would not like to open the door
to one of the ASN.1 families of encodings. [Sorry Nico]

So I think we can work within what we have today, but
create an RFC to more rigorously define semantics for the
interesting cases like getxattr.

	-David

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4