From: Peter Staubach <staubach@redhat.com>
To: James Morris <jmorris@namei.org>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
"J. Bruce Fields" <bfields@fieldses.org>,
linux-nfs@vger.kernel.org, Christoph Hellwig <hch@infradead.org>,
Casey Schaufler <casey@schaufler-ca.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol
Date: Tue, 06 Oct 2009 11:18:24 -0400 [thread overview]
Message-ID: <4ACB5FC0.7060307@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.00.0909200020360.31818-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
James Morris wrote:
> This patchset is the initial posting of an implementation of extended
> attribute support for the Linux NFSv3 code, and intended as an RFC.
>
> This code is based initially on the GPL'd NFSv3 xattr code from IRIX
> (thanks, Casey!), as well as the existing Linux NFSv3 ACL code. It is
> implemented as a side-protocol and should not affect any existing protocol
> operation. These patches are against the devel branch of the linux-nfs
> tree.
>
> Currently, the code is implemented only to support Linux namespace.name
> xattrs in the "user" namespace. It could be extended to support other
> similar name/value pair xattr implementations (and not far from IRIX wire
> compat), although that's not an aim of this version. There may also be
> some scope for limited support of system xattrs (e.g. 'dumb' security
> label transport), although I've not looked beyond user.* so far.
>
> 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?
> - Dynamic allocation of RPC buffers/pages (currently, the max size of
> e.g. the getxattr(2) value buffer is allocated at the RPC layer for
> each call -- suggestions on the best approach for this welcome)
>
> - Determine appropriate NFS error codes for each operation
>
> - Formal documentation of the XATTR protocol
>
These two would be a good thing. It would be good to at least have
a .x description, although having some of the semantics described
as well would be a good thing.
> - 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.
> - Handle size probing for getxattr(2) and listxattr(2) in the client
> (currently faked). I think we should handle this at the client and not
> support it over the wire, as probes are almost always followed
> immediately by full calls, and the protocol can be kept simpler by
> expecting the client to perform a full call over the wire in response
> to a userland probe and caching the result.
>
> - 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.
On more bullet that I might suggest is ensuring that the protocol
is compliant with the RPC and XDR standards.
Thanx...
ps
> Please review and comment!
>
> Note that I'll be giving a talk on this at LinuxCon on Thursday:
> http://linuxcon.linuxfoundation.org/meetings/1589 So, in addition to
> discussion here, please come along to the talk if you're at the conf, and
> we may also be able to discuss it at Plumbers in one of the BoFs.
>
> Full diffstat:
>
> fs/nfs/Kconfig | 36 ++++
> fs/nfs/Makefile | 2
> fs/nfs/client.c | 51 ++++++
> fs/nfs/dir.c | 8 -
> fs/nfs/file.c | 8 -
> fs/nfs/internal.h | 19 ++
> fs/nfs/nfs3acl.c | 155 +++++++++++--------
> fs/nfs/nfs3xattr.c | 264 +++++++++++++++++++++++++++++++++
> fs/nfs/nfs3xattr_user.c | 52 ++++++
> fs/nfs/nfs3xdr.c | 187 +++++++++++++++++++++++
> fs/nfs/super.c | 3
> fs/nfsd/Kconfig | 8 +
> fs/nfsd/Makefile | 1
> fs/nfsd/nfs3xattr.c | 352 +++++++++++++++++++++++++++++++++++++++++++++
> fs/nfsd/nfsctl.c | 3
> fs/nfsd/nfssvc.c | 60 +++++++
> fs/nfsd/vfs.c | 5
> include/linux/nfs_fs.h | 16 --
> include/linux/nfs_fs_sb.h | 3
> include/linux/nfs_mount.h | 3
> include/linux/nfs_xattr.h | 21 ++
> include/linux/nfs_xdr.h | 45 +++++
> include/linux/nfsd/nfsd.h | 13 +
> include/linux/nfsd/xdr3.h | 46 +++++
> include/linux/sunrpc/svc.h | 2
> 25 files changed, 1265 insertions(+), 98 deletions(-)
>
>
> - James
WARNING: multiple messages have this Message-ID (diff)
From: Peter Staubach <staubach-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
Cc: Trond Myklebust
<trond.myklebust-41N18TsMXrtuMpJDpNschA@public.gmane.org>,
"J. Bruce Fields"
<bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Casey Schaufler <casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol
Date: Tue, 06 Oct 2009 11:18:24 -0400 [thread overview]
Message-ID: <4ACB5FC0.7060307@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.00.0909200020360.31818-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
James Morris wrote:
> This patchset is the initial posting of an implementation of extended
> attribute support for the Linux NFSv3 code, and intended as an RFC.
>
> This code is based initially on the GPL'd NFSv3 xattr code from IRIX
> (thanks, Casey!), as well as the existing Linux NFSv3 ACL code. It is
> implemented as a side-protocol and should not affect any existing protocol
> operation. These patches are against the devel branch of the linux-nfs
> tree.
>
> Currently, the code is implemented only to support Linux namespace.name
> xattrs in the "user" namespace. It could be extended to support other
> similar name/value pair xattr implementations (and not far from IRIX wire
> compat), although that's not an aim of this version. There may also be
> some scope for limited support of system xattrs (e.g. 'dumb' security
> label transport), although I've not looked beyond user.* so far.
>
> 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?
> - Dynamic allocation of RPC buffers/pages (currently, the max size of
> e.g. the getxattr(2) value buffer is allocated at the RPC layer for
> each call -- suggestions on the best approach for this welcome)
>
> - Determine appropriate NFS error codes for each operation
>
> - Formal documentation of the XATTR protocol
>
These two would be a good thing. It would be good to at least have
a .x description, although having some of the semantics described
as well would be a good thing.
> - 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.
> - Handle size probing for getxattr(2) and listxattr(2) in the client
> (currently faked). I think we should handle this at the client and not
> support it over the wire, as probes are almost always followed
> immediately by full calls, and the protocol can be kept simpler by
> expecting the client to perform a full call over the wire in response
> to a userland probe and caching the result.
>
> - 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.
On more bullet that I might suggest is ensuring that the protocol
is compliant with the RPC and XDR standards.
Thanx...
ps
> Please review and comment!
>
> Note that I'll be giving a talk on this at LinuxCon on Thursday:
> http://linuxcon.linuxfoundation.org/meetings/1589 So, in addition to
> discussion here, please come along to the talk if you're at the conf, and
> we may also be able to discuss it at Plumbers in one of the BoFs.
>
> Full diffstat:
>
> fs/nfs/Kconfig | 36 ++++
> fs/nfs/Makefile | 2
> fs/nfs/client.c | 51 ++++++
> fs/nfs/dir.c | 8 -
> fs/nfs/file.c | 8 -
> fs/nfs/internal.h | 19 ++
> fs/nfs/nfs3acl.c | 155 +++++++++++--------
> fs/nfs/nfs3xattr.c | 264 +++++++++++++++++++++++++++++++++
> fs/nfs/nfs3xattr_user.c | 52 ++++++
> fs/nfs/nfs3xdr.c | 187 +++++++++++++++++++++++
> fs/nfs/super.c | 3
> fs/nfsd/Kconfig | 8 +
> fs/nfsd/Makefile | 1
> fs/nfsd/nfs3xattr.c | 352 +++++++++++++++++++++++++++++++++++++++++++++
> fs/nfsd/nfsctl.c | 3
> fs/nfsd/nfssvc.c | 60 +++++++
> fs/nfsd/vfs.c | 5
> include/linux/nfs_fs.h | 16 --
> include/linux/nfs_fs_sb.h | 3
> include/linux/nfs_mount.h | 3
> include/linux/nfs_xattr.h | 21 ++
> include/linux/nfs_xdr.h | 45 +++++
> include/linux/nfsd/nfsd.h | 13 +
> include/linux/nfsd/xdr3.h | 46 +++++
> include/linux/sunrpc/svc.h | 2
> 25 files changed, 1265 insertions(+), 98 deletions(-)
>
>
> - James
--
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
next prev parent reply other threads:[~2009-10-06 15:19 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-19 15:09 [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol James Morris
2009-09-19 15:11 ` [PATCH 1/4] NFSv3: convert client to generic xattr API James Morris
2009-09-19 15:12 ` [PATCH 2/4] NFSv3: add xattr API config option for client James Morris
2009-09-19 15:13 ` [PATCH 3/4] NFSv3: add client implementation of XATTR protocol James Morris
2009-09-19 15:14 ` [PATCH 4/4] NFSv3: add server " James Morris
[not found] ` <alpine.LRH.2.00.0909200020360.31818-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-09-19 17:30 ` [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol Casey Schaufler
2009-09-19 17:30 ` Casey Schaufler
2009-09-20 5:13 ` James Morris
2009-09-20 5:13 ` James Morris
2009-09-22 12:47 ` Christoph Hellwig
2009-09-22 13:03 ` James Morris
[not found] ` <alpine.LRH.2.00.0909222253470.21052-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-09-22 13:07 ` Christoph Hellwig
2009-09-22 13:07 ` Christoph Hellwig
2009-10-06 15:18 ` Peter Staubach [this message]
2009-10-06 15:18 ` Peter Staubach
2009-10-09 0:39 ` James Morris
2009-10-09 0:39 ` James Morris
[not found] ` <alpine.LRH.2.00.0910091132130.32154-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-10-09 23:14 ` Christoph Hellwig
2009-10-09 23:14 ` Christoph Hellwig
2009-10-12 17:50 ` Peter Staubach
2009-10-12 17:50 ` Peter Staubach
2009-10-12 19:26 ` Tom Haynes
[not found] ` <CA06CB5C-6084-45AA-B185-FBDA7E3B9754-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
2009-10-12 19:34 ` Peter Staubach
2009-10-12 19:34 ` Peter Staubach
2009-10-12 22:55 ` Trond Myklebust
[not found] ` <1255388158.3711.57.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-10-12 23:08 ` J. Bruce Fields
2009-10-12 23:08 ` J. Bruce Fields
2009-10-13 7:02 ` James Morris
[not found] ` <alpine.LRH.2.00.0910131733070.28896-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-10-13 18:27 ` Trond Myklebust
2009-10-13 18:27 ` Trond Myklebust
[not found] ` <1255458444.3711.113.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-10-14 0:48 ` James Morris
2009-10-14 0:48 ` James Morris
[not found] ` <alpine.LRH.2.00.0910141134410.4671-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-10-14 2:05 ` Casey Schaufler
2009-10-14 2:05 ` Casey Schaufler
2009-10-14 4:30 ` James Morris
[not found] ` <alpine.LRH.2.00.0910141526530.5279-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-10-14 4:50 ` Casey Schaufler
2009-10-14 4:50 ` Casey Schaufler
2009-10-14 12:46 ` Peter Staubach
2009-10-14 12:46 ` Peter Staubach
2009-10-14 4:56 ` Dustin Kirkland
2009-10-14 4:56 ` Dustin Kirkland
2009-10-14 6:02 ` James Morris
2009-10-14 6:02 ` James Morris
2009-10-14 15:05 ` Tyler Hicks
[not found] ` <bf63d7240910080919nf1bf6d0rd94f671d0645f674@mail.gmail.com>
2009-10-08 17:21 ` J. Bruce Fields
2009-10-09 0:31 ` James Morris
2009-10-08 17:22 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ACB5FC0.7060307@redhat.com \
--to=staubach@redhat.com \
--cc=bfields@fieldses.org \
--cc=casey@schaufler-ca.com \
--cc=hch@infradead.org \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.