Subject: RE: [nfsv4] Named attributes and getxattr

From: "Yoder, Alan" <[email-masked]>
Date: Thu, 10 Nov 2005 12:19:32 -0800

> Not sure there is a solution.  For some classes of attributes
> the may be primarily read-only, so trying to copy them will fail.
> I can imagine an attribute that contains which blocks are filled
> versus which blocks are holes. Copying the file will change that
> list based on the server implementation, so trying to
> write the attribute would fail.

As I said before, there needs to be a way to tell utilities
which attrs should be copied and which shouldn't.  There may
be other flags as well as we go deeper into this.  For example,
which attributes of a file constitute some kind of key.

Agree it should wait until 4.2.  We don't know enough.

Alan

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

> -----Original Message-----
> From: David Robinson [mailto:[email-masked]] 
> Sent: Thursday, November 10, 2005 11:24 AM
> To: [email-masked]
> Subject: Re: [nfsv4] Named attributes and getxattr
> 
> On Nov 10, 2005, at 12:35 PM, Brent Callaghan wrote:
> >> There are some odd mismatches between extended attributes and NFSv4
> >> named attributes; I'm not convinced they're such a good fit.
> >
> > Yup, xattrs are short strings, atomically set and read.  
> Subfiles are
> > infinitely long, read and written incrementally.  Representing
> > xattrs as subfiles would be an inefficient hack.  I think they need
> > distinct APIs, namespaces, and protocol support.
> 
> How important is the atomicity? While NFSv4 has almost no atomicity
> guarentees, would placing the contents in a READ/WRITE surrounded
> by a LOCK/LOCKU (see cur_stateid proposal) be good enough?
> 
> A well constructed COMPOUND should allow a get or set with
> one round trip, so I don't see much of an efficiency argument.
> 
> > My preference would be to have NFSv4 support an attribute that's
> > an array of xattrs - much as we do now with ACLs.  That would
> > allow readdir to return them en masse.
> 
> That is an alternative. Is GETATTR/SETATTR atomic enough? Would
> it always return all attributes in the list? Or will GETATTR have
> a new argument beyond the bitmap to specify return just one?
> 
> > BTW: one potential downside of a proliferation of System xattrs is
> > their potential to agglomerate as a file journeys from one system
> > to another.  How do we avoid xattr namespace pollution ?
> 
> This is a general problem beyond system attributes, as the number
> of applications grow that add attributes, and files are copied
> or moved between systems, they will agglomerate too. Just look
> at the average Unix user's .mumble files in their home directory.
> Not sure there is a solution.  For some classes of attributes
> the may be primarily read-only, so trying to copy them will fail.
> I can imagine an attribute that contains which blocks are filled
> versus which blocks are holes. Copying the file will change that
> list based on the server implementation, so trying to
> write the attribute would fail.
> 
> More generally, this is not unlike special device files. Two
> different clients may interpret the same file in different
> ways. System attributes introduce a third case where the server
> may interpret the attribute as well.
> 
> My perspective is that the community needs to say something
> about xattrs, but not ignore them.  Either they fit within
> the existing named attr model, or we create a new
> mechanism to deal with them. But I see the getxattr APIs
> increasing in deployment (new in MacOS 10.4 I see) so
> something needs to be done.
> 
> My opinion is that named attrs are under used, while not a
> perfect match, its good enough, and could be deployed today
> without a new minor version. Can we wait until 4.2?
> 
> 	-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