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

gww@traakan.com

From: "Gordon Waidhofer" <gww@traakan.com>
Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Date: Fri, 17 Dec 2004 10:11:39 -0800
Message-ID: <HIEGIBOPEMBFAKKGEELDEENAJAAA.gww@traakan.com>

> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org]On Behalf Of
> David Robinson
> Sent: Friday, December 17, 2004 8:53 AM
> To: nfsv4@ietf.org
> Cc: Sam.Falkner@Sun.COM; Lisa.Week@Sun.COM
> Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
> 
> 
> Gordon Waidhofer wrote:
> 
> 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:

The Solaris mechanism (why is it called extended attribute?)
isn't just implemented as subfiles, it *IS* subfiles.
The NFSv4 Named Attributes are used to access them, as
will be NT streams (subfiles).

Sure, it's possible to do back flips and wraps
Linux/BSD style Extended Attributes so they can
be accessed by NFSv4 Named Attributes. It is
possible. I'm saying it isn't a good idea.

Indeed, I think it is a remarkably bad idea.

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

Now, do it one byte at a time.
> 
> and a setxattr is the obvious use of WRITE. A smart server
> could easily optimize this to whatever underlying
> interfaces they have.

Now, do it one byte at a time. As I said, can't chown(2)
using 8 unordered one byte writes. Can't change a POSIX
ACL doing 1000+ unordered one byte writes.

OK. It is possible. Who's going to do it first? :)

Now, that will seem a weak argument if you think
of Named Attributes as opaque data.

There is no such thing as an opaque attribute.

> 
> 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.

Convention: don't do it.

> 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]

That's exactly why there is no such thing as an
opaque attribute. Wow. I couldn't possible have
come up with anything scarier. That idea, I hope,
goes a long way to supporting my point as a devil's
advocate position.

Y'all, the term "attribute" is getting diluted
because some want to hold onto the idea of "opaque
attributes". It is becoming necessary to decorate
the noun "attribute" with terms to help us know
what we are talking about: "opaque", "interpretted",
"system", "user". Pretty soon, the word attribute
won't mean anything. This course leads to "opaque
uninterpretted unsystem attributes". That wouldn't
be helpful. If it's opaque, it's an unattribute. :)

Opaque stuff goes in files and subfiles.

"Attributes" are meaningful to all levels and require
rigorous definition (tar/pax, XDR, etc, etc).

Attribute or DATA. Period. This, too me, is helpful
to our collective endeavor.

Much preferable to DATA and $Adjective ATTRIBUTE.

I may be saying all this in my own way.
But I'm not the first to say that the Extended
Attribute mechanisms (OS/2, Linux, FreeBSD, etc, etc)
are for true attributes and never intended as
poor man's subfiles (i.e. opaque, application data).

> 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.

The RFC is the NFSv4 spec. The semantics are
defined by adding XDRs and attribute numbers.
It's what makes NFSv4 extensible.

> 
> 	-David

Regards,
	-gww

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

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