Sent from my iPhone
On Oct 12, 2009, at 10:50 AM, Peter Staubach <staubach@xxxxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
