Subject: [nfsv4] Using a NFSv4 attribute for xattrs

From: Benny Halevy <[email-masked]>
Date: Tue, 5 Nov 2013 15:34:23 -0800

After discussing this with Marc it seems to me that using an attribute
to store user extended attributes (following the ACL example) might be
a simple, straight forward method to store and retrieve extended
attributes and answer most application requirements.

1. Define a new attribute as follows:

typedef utf8string xattr_key4;

typedef utf8string xattr_value4<>;

struct xattr_ent4 {
    xattr_key4      key;
    xattr_valiue4  value;
};

typedef xattr_ent4 nfsxattr4<>;

2. Security

normal attribute security semantics to be used for getting and setting
xattrs could be used, e.g.

ACE4_READ_ATTRIBUTES, ACE4_WRITE_ATTRIBUTES

or new ACE mask attributes can be added, similar to the ones
controlling the ACL attribute itself.

3. GETATTR and SETATTR would be used to get and set all xattrs at once.
Again, similar to the ACL model.  It's up to the client to lookup and
update keys and values.

4. An attribute can be provided at create OPEN time so one could
provide extended attributes on creation.

5. An optional operation can be added to query the file system for
list of files, similar to READDIR, that match a query.
This could be useful for storing user defined metadata that extends
the nfsv4 model, like for example, mime types, or whatever tags the
application may want to store on files.

OP_QUERYXATTRS

   struct QUERYXATTRS4args {
           /* CURRENT_FH: directory */
           nfs_cookie4     cookie;
           verifier4       cookieverf;
           count4          dircount;
           count4          maxcount;
           bitmap4       attr_request;
           xattr_key4    xattr_key;
           utf8string      xattr_regexp;
   };

   struct QUERYXATTRS4resok {
           verifier4       cookieverf;
           dirlist4        reply;
   };

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Tue, 5 Nov 2013 19:25:20 -0500 (EST)

Hi Benny,

I'm not clear how a model that involves getting and setting all attributes together
as a blob could be considered a first class mapping to xattrs, presuming we achieve
consensus to design a new interface.

Matt

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309

---

From: Marc Eshel <[email-masked]>
Date: Tue, 5 Nov 2013 20:17:38 -0800

I think it is clear from todays meeting and the discussion on the 
maligning list that we need to extend the NFS protocol to support 
something that looks more like xattr. Benny Idea is good but not 
completely thought through. We should consider all the ideas and come back 
with a more complete draft of what we propose to do.
Marc. 

From:   "Matt W. Benjamin" <[email-masked]>
To:     Benny Halevy <[email-masked]>, 
Cc:     Marc Eshel/Almaden/IBM@IBMUS, [email-masked], 
[email-masked], Chuck Lever <[email-masked]>
Date:   11/05/2013 04:25 PM
Subject:        Re: Using a NFSv4 attribute for xattrs

Hi Benny,

I'm not clear how a model that involves getting and setting all attributes 
together
as a blob could be considered a first class mapping to xattrs, presuming 
we achieve
consensus to design a new interface.

Matt

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309

---

From: Chuck Lever <[email-masked]>
Date: Wed, 6 Nov 2013 09:06:06 -0800

> Again, similar to the ACL model.  It's up to the client to lookup and

Looking at

  http://gentoobrowse.randomdan.homeip.net/use/xattr

I suspect that operations on single extended attributes (like getxattr(2) and setxattr(2)) would be fairly common, especially for POSIX-like clients which typically use a VFS layer abstraction.  If I understand correctly, your proposal imposes a large overhead for retrieving just one extended attribute (ie, all attributes and their contents would be retrieved), and a read-modify-write cycle is required to update one extended attribute.

(The following is only my naive personal thought, not a representation of my employer or the Linux community).

I was thinking along the lines of exposing an interface similar to fgetxattr(2).  One new operation each for retrieving, updating, listing, and removing extended attributes from a file.  The file would have to be open to perform these operations, thus requiring a state ID.  Normal locking or deny modes could serialize access and updates to a file's extended attributes.  Delegation could be used to notify a client that it's xattr cache is invalid.

The idea is that the NFS abstraction would be generic enough that the underlying server implementation could be nearly anything (an LDAP service, for example, or a single named attribute attached to the file, or paper tape).  Server implementers choose an implementation based on the capabilities of their physical file systems, and any requirements for interoperation between network clients and local consumers of extended attributes.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com