Re: [PATCH 3/8][RFC v05] NFSv3: add client implementation of XATTR protocol

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/21/2010 07:21 PM, James Morris wrote:
On Mon, 21 Jun 2010, Chuck Lever wrote:
+#define NFS_XATTR_PROGRAM	391063	/* TODO: find another value */

RFC 5531, appendix B proscribes the appropriate method for requesting an RPC
program number assignment.

Even though the NFSACL protocol doesn't have one, I have to agree with Deniel
that we should have the RPCL definition of the on-the-wire protocol first, so
we can review it and ensure our user space and kernel XDR functions remain
consistent and correct over time.

Indeed, this is something I'm hoping to do soon.

  Is there an RFC?

No, there have been several implementations, but never an RFC for xattrs.

I'm using the XFS implementation as a starting point, and following the
ACL model of implementing a side-protocol.

Especially if we expect non-Linux implementations, I would think an
IANA-assigned program number and a proper RPCL definition would be apriori
requirements.

It's possible the FreeBSD folk may want to interop with this, as they have
similar name/value xattrs.

This is why apriori documentation (such as an internet RFC or similar that describes the wire protocol) is important. For an example of a side band protocol description, you can look at RFC 1094 or RFC 1813 and look at the sections that describe the MOUNT and NLM protocols.

Another place to look is at NFSv4. Some of the operations that can be performed on NFSv4 xattrs are probably nearly what you would want for an NFSv3 implementation. I think it is desirable for anything done for NFSv3 to be compatible with NFSv4, as that is already a standard.

(Btw, slides from a presentation I did on this last year at LinuxCon are
at http://namei.org/presentations/linuxcon09_nfsv3xattrs.pdf)

NFSACL was added to our NFSv3 implementation because there was a desire to interoperate with an existing (albeit nonstandard) implementation. Here you are building a new side band protocol from scratch.

Before you go too much farther, you should justify the need to enhance a closed standard like NFSv3 rather than expanding on NFSv4 for your purposes. Since NFSv4 already has a lot of what is needed, it seems like you'd just need a couple of changes in order to support name/value pairs. You would have a shot at actually making this an internet standard.

I think this community would prefer to advance reasons for users to adopt NFSv4, rather than tie users even more to NFSv3.

--
Chuck Lever
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux