All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Sriram Ramkrishna <sri@ramkrishna.me>
Cc: James Morris <jmorris@namei.org>,
	Trond Myklebust <trond.myklebust@fys.uio.no>,
	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: Thu, 8 Oct 2009 13:21:24 -0400	[thread overview]
Message-ID: <20091008172123.GA24911@fieldses.org> (raw)
In-Reply-To: <bf63d7240910080919nf1bf6d0rd94f671d0645f674@mail.gmail.com>

On Thu, Oct 08, 2009 at 09:19:13AM -0700, Sriram Ramkrishna wrote:
> On Sat, Sep 19, 2009 at 8:09 AM, James Morris <jmorris@namei.org> wrote:
> 
> >
> > 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.
> >
> >
> James this is great news.  I personally am interested (as a consumer) in
> setting up better ACL list (ala AFS) than the POSIX model we have now and
> trying to implement it using xattr might be the right way.  But my
> frustration of course was that everybody did xattr in different ways and no
> filesystem implementer wanted to go on a limb and implemented such things
> without a RFC.

Yes, we could allow applications on the client to access essentially
arbitrary filesystem-specific functionality.  However, this also would
allow applications to become dependent on particular features of the
exported filesystem.  There's some question whether we'd really want to
do that.

I assume that it was in order to avoid that question that this initial
implementation only exports the user.* namespace, since xattr's in that
name space are by design not given any special interpretation by the
filesystem--they just store and return opaque data.

--b.

> 
> 
> >
> > 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.
> >
> 
> 
> Ah, I was there, and I was asking around wanting to talk about the issue!
> Ah well.
> 
> sri

  parent reply	other threads:[~2009-10-08 17:21 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
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 [this message]
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=20091008172123.GA24911@fieldses.org \
    --to=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=sri@ramkrishna.me \
    --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.