public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
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


  parent reply	other threads:[~2009-10-06 15:19 UTC|newest]

Thread overview: 31+ 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-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-10-06 15:18   ` Peter Staubach [this message]
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-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 22:55                 ` Trond Myklebust
     [not found]                   ` <1255388158.3711.57.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
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
     [not found]                         ` <1255458444.3711.113.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
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  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 12:46                                       ` Peter Staubach
2009-10-14  4:56                               ` Dustin Kirkland
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox