Subject: RE: [nfsv4] Named attributes and getxattr

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 9 Nov 2005 18:04:00 -0800

I apologize if there has been discussion
of this and I missed it.  Has any provision 
been made for making cp, tar, cpio and brethren 
named attribute aware?  Without that, you can
put all you want in the protocol, but you don't
really have much, because widely used utilities 
will dump them on the floor.  

And then there's the issue that some named
attributes need to be copied with the file, and
others not.  There needs to be a standard way to 
distinguish them so cp et all can do the right
thing.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================

> -----Original Message-----
> From: David Robinson [mailto:[email-masked]] 
> Sent: Wednesday, November 09, 2005 5:05 PM
> To: [email-masked]
> Subject: Re: [nfsv4] Named attributes and getxattr
> 
> On Nov 9, 2005, at 5:44 PM, J. Bruce Fields wrote:
> 
> > On Wed, Nov 09, 2005 at 05:32:22PM -0600, David Robinson wrote:
> >> This API is clearly a subset of the named attributes
> >> used within NFSv4, one that is mostly flat.  But as a subset
> >> there should be some common mapping.
> >
> > Does there have to be?
> 
> No, but deciding there is no mapping is still a decision.
> In the absence of such a decision we are likely to have
> vendors doing incompatible ad hoc things.
> 
> > Another alternative would be to keep the two namespaces--extended
> > attributes and named attributes--entirely separate.
> 
> That would be a reasonable alternative, but it then begs the
> question of providing a mechanism to get/set/list extended
> attributes over the wire. An new OPENXATTR with the same semantics
> as OPENATTR but an alternative namespace? A simpler
> flat GETXATTR/SETXATTR/LISTXATTR?
> 
> > That suggests to me that the named attributes are meant to 
> be left up 
> > to
> > users and applications, not taken over by the client or 
> server as a way
> > to export OS-specific interfaces.
> 
> That is one interpretation that seems to fit. But in the absence of
> a mechanism that provides a generally extensible extended attribute
> model, there is strong attraction for a vendor to "just use it".
> While it can be argued that BazCo Inc. using the BZCO prefix
> or subdirectory is not fully within the spirit of RFC3530,
> the odds of conflict with a real user is so small that I doubt
> the market would stop it. It is clearly better than picking some
> arbitrary integer.
> 
> If I recall the original discussion, there were some opinions that it
> could be used for system or vendor specific attributes. A major
> detractor from defining a namespace was the lack of a
> real world example namespace or a desire at the time to define one.
> 
> But also note, that RFC3530 section 17.1 also states that portions
> of the namespace can be registered with IANA and published
> through an informational RFC:
> 
>     Even though the name space is not specifically controlled 
> to prevent
>     collisions, an IANA registry has been created for the 
> registration of
>     NFS version 4 named attributes.  Registration will be achieved
>     through the publication of an Informational RFC and will 
> require not
>     only the name of the attribute but the syntax and semantics of the
>     named attribute contents; the intent is to promote 
> interoperability
>     where common interests exist.  While application developers are
>     allowed to define and use attributes as needed, they are 
> encouraged
>     to register the attributes with IANA.
> 
> So an argument could be made that a "Linux" system is an application
> of the protocol, and this is a proposal to reserve the named
> attributes "system", "user", and "trusted" with IANA and published
> in an Informational RFC as a suggested mapping for the 
> getxattr/setxattr
> interfaces. It would not prevent some other application from
> colliding, but it is at least a public declaration of intent.
> 
> I have preferences to used named attrs, but I am not opposed
> to new OPs or other techniques, but I
> do think it would be useful to come to a common consensus on how
> getxattr/setxattr get reflected on to the network. Even if it is
> just an Informational RFC telling vendors to not use named attrs.
> 
> 	-David
> 
> 
> _______________________________________________
> 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: David Robinson <[email-masked]>
Date: Wed, 9 Nov 2005 22:06:19 -0600

> will dump them on the floor.

Don't know about Linux, bit it works on Solaris:

jetsun% df .
/net/wayback/export(wayback:/export   ):70590192 blocks  7952832 files
jetsun% /bin/ls -@a .
total 4
drwxr-xr-x   2 robinson staff        512 Nov  9 21:52 .
drwxrwxrwx  19 robinson staff        512 Nov  9 21:50 ..
jetsun% /bin/ls -@a ../txattr1
total 4
drwxr-xr-x   2 robinson staff        512 Nov  9 21:50 .
drwxrwxrwx  19 robinson staff        512 Nov  9 21:50 ..
-rw-r--r--@  1 robinson staff          0 Nov  9 21:50 foo
jetsun% runat ../txattr1/foo ls -l
total 0
-rw-r--r--   1 robinson staff          0 Nov  9 21:50 bar
jetsun% (cd ../txattr1 ; tar cfv@ - . ) | tar xfv@p -
a ./ 0K
a ./foo 0K
a ./foo attribute . 0K
a ./foo attribute bar 0K
tar: blocksize = 10
x ., 0 bytes, 0 tape blocks
x ./foo, 0 bytes, 0 tape blocks
x ./foo attribute bar, 0 bytes, 0 tape blocks
jetsun% /bin/ls -@a .
total 4
drwxr-xr-x   2 robinson staff        512 Nov  9 21:50 .
drwxrwxrwx  19 robinson staff        512 Nov  9 21:50 ..
-rw-r--r--@  1 robinson staff          0 Nov  9 21:56 foo
jetsun% runat foo ls -l
total 0
-rw-r--r--   1 robinson staff          0 Nov  9 21:50 bar
jetsun% cp -p foo baz
jetsun% /bin/ls -@a .
total 4
drwxr-xr-x   2 robinson staff        512 Nov  9 22:00 .
drwxrwxrwx  19 robinson staff        512 Nov  9 21:50 ..
-rw-r--r--@  1 robinson staff          0 Nov  9 21:56 baz
-rw-r--r--@  1 robinson staff          0 Nov  9 21:56 foo
jetsun% runat baz ls
bar

> distinguish them so cp et all can do the right

 From the Solaris perspective it will try to copy all
attributes if requested. In theory if it is a read-only
attribute then it couldn't be written. While tar doesn't
allow the -X exclude option to exclude a named attribute,
it probably could be added, mostly a matter of syntax.

	-David