From: Tom Haynes Subject: Re: [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol Date: Mon, 12 Oct 2009 12:26:04 -0700 Message-ID: References: <4ACB5FC0.7060307@redhat.com> <4AD36C82.8080904@redhat.com> Mime-Version: 1.0 (iPhone Mail 7D11) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Cc: James Morris , Trond Myklebust , "J. Bruce Fields" , "linux-nfs@vger.kernel.org" , Christoph Hellwig , Casey Schaufler , "linux-fsdevel@vger.kernel.org" To: Peter Staubach Return-path: In-Reply-To: <4AD36C82.8080904@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Sent from my iPhone On Oct 12, 2009, at 10:50 AM, Peter Staubach wrote: > 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? > Amazing to find my name in the middle of a thread. I've just got what is in this email... So, is this a new side band protocol or an extension to NFSv3? Is there some document describing the problem being solved? >>>> - 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html