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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
