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: Thu, 16 Dec 2004 19:31:08 -0800
Message-ID: <HIEGIBOPEMBFAKKGEELDOELDJAAA.gww@traakan.com>

> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org]On Behalf Of
> Theodore Ts'o
> Sent: Thursday, December 16, 2004 6:57 PM
> To: Gordon Waidhofer
> Cc: J. Bruce Fields; Sam.Falkner@Sun.COM; Halevy, Benny; nfsv4@ietf.org;
> Lisa.Week@Sun.COM
> Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
> 
> 
> On Thu, Dec 16, 2004 at 11:42:26AM -0800, Gordon Waidhofer wrote:
> > 
> > Ultimately, everybody should steer toward Solaris
> > style named subfiles. Solaris should rename the
> > mechanism. So should NFSv4.
> 
> I disagree.  I can very easily forsee a future where filesystems have
> both "extended attributes" (i.e., an atomic set/get facility for small
> metadata items) and "sub-files".

I can't. But we can agree to disagree.

> Of course, as soon as sub-files
> start having permissions and access controls associated with them,
> then files with subfiles start looking an awful lot like a directory
> with a default file if the directory is opened as a file instead of a
> directory.

That is a fair description of the Solaris mechanism (extended
attributes that should be called subfiles).

> NTFSv5 has both facilities, for example.

Can you cite a reference? URL? This is important
and I've not tripped across anything truly helpful
about where NTFS may be going.

> 
> The two provide different semantics, and can have very different
> performance implications.  If it weren't too late, I'd argue that
> NFSv4 NAMED_ATTRIBUTES should be renamed to something less confusing,

Subfiles?

> and that adding an EXTENDED_ATTRIBUTES extension which has an atomic
> set/get facility would be a good thing.

Ya. That's where we disagree. Attributes require rigorous
definition, XDR encoding, NFSv4 attribute number assignment,
tar/pax name, canonical text definitions, etc, etc, etc.
You can't throw an "attribute" over the wire opaquely.
The problems start with byte order, and then it gets complicated.

An "attribute" is meaningful to the file system, operating
system, and application levels. Data is opaque and meaningful
to only the application level.

There is no such thing as an opaque attribute.

> 						- Ted

Indeed, hashing out the star-to-steer-by file model is
a prerequisite to defining things like NFSV4_READ_NAMED_ATTRIBUTE
permission bits, and the like.

There is no star-to-steer-by file model at this time.

Regards,
	-gww

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