Re: [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol

[Peter Staubach <staubach-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

James Morris wrote:
> On Tue, 6 Oct 2009, Peter Staubach wrote:
> 
>>> Three operations are implemented by the new XATTR protocol and map to 
>>> syscalls:
>>>
>>>  - GETXATTR     getxattr(2)
>>>  - LISTXTTR     listxattr(2)
>>>  - SETXATTR     setxattr(2) and removexattr(2)
>>>
>>> This code passes basic testing of the above syscalls, although there are 
>>> some areas which still need work:
>>>
>> Is there a set of tests which are used to test this functionality?
> 
> No, I just manually run a set of commands to verify basic behavior.
> 
> I gather LTP would be the best place to add tests for this?
> 
>>>  - Interoperability with other OSs (we probably should at least
>>>    discuss with BSD folk)
>>>
>> It would be good to include the BSD folks, but I think that more
>> valuable targets would be those with volume servers that might be
>> encountered at customer sites.  I think that we need NetApp, EMC,
>> perhaps Sun, providing some feedback on the protocol and semantics.
> 
> Given that IETF activity is closed for v3, I wonder what the best forum 
> would be to reach all these folk?
> 

With some sort of protocol description, it should be possible to
publish some sort of document.  Off hand, I don't know what it
might be called, but we can find out.

Otherwise, we might be able to get by with a .x description of
the over the wire protocol and some short words describing the
expected semantics of anything that non-Linux implementators
might need to be aware of.

I know that (at least) a few non-Linux folks lurk here.  Might
any of them have any opinions regarding the viability of
implementing this support on their own implementations?  TomH?
MichaelE?

>>>  - Caching of xattrs at the client
>>>
>> This will need a closer specification for the semantics associated
>> with these xattrs.  The need will be how to determine when to
>> invalidate cached xattrs.
> 
> I suspect user namespace xattrs should be treated like file data wrt 
> caching (i.e. they're fully under the control of the user).
> 

Umm, I think that some more detail might be required.  For
example, when the file contents are modified, the mtime on
the file is supposed to change.  I am wondering what in the
metadata for the file itself changes when an extended attribute
is added, modified, or deleted.  It is this information that we
can use to then do correct cache validation and invalidation.

I am assuming that the ctime changes, but we need to explicitly
ensure that this is true or discover what else is.

I believe that without caching, the performance of any resulting
implementations will not be acceptable.

>> On more bullet that I might suggest is ensuring that the protocol
>> is compliant with the RPC and XDR standards.
> 

I believe that http://tools.ietf.org/html/rfc5531#appendix-B
describes the portion of this that pertains to obtaining a
registered RPC program number.  Otherwise, ensuring that all
of the data structures are encoded according to the XDR
specifications and that all byte orders are encoded according
to the same specification should suffice.

	Thanx...

		ps
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html