Subject: Re: [nfsv4] Using a NFSv4 attribute for xattrs

From: "Matt W. Benjamin" <[email-masked]>
Date: Wed, 6 Nov 2013 12:33:10 -0500 (EST)

Hi Chuck,

I agree that operations on single xattrs are likely required, and think that
your suggestion of interface is probably close to what several of us are thinking.

I think there are some rather obvious problems with Linux's fgetxattr interface
specifically (like inducing multiple calls or buffer size guessing), but I can't
see those showing up in the NFS versions of these.

I would concur with Nico (downthread) that traditional file delegation as you
propose should be sufficient.  (And would help with the use cases Marc and Benny
were I think speaking of.)

Also, I would like to propose that we define a single namespace for named attributes and
xattrs, should a server implementation choose to support both.

Matt

----- "Chuck Lever" <[email-masked]> wrote:

> On Nov 5, 2013, at 3:34 PM, Benny Halevy <[email-masked]>
> wrote:
> 
> > 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.
> 
> 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.
> 
> > 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;
> >   };
> 
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com

-- 
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: Wed, 6 Nov 2013 09:59:48 -0800

I agree that the interface should allow for individual attributes to be 
manipulated separately, but it is also useful to have operations on all 
attributes as a blab. There should be a maximum size that is supported for 
all xattr per file that the client can query and than just read it all in 
one read operation and than look for the specific attribute in the buffer 
instead of dealing with reading a list of attributes. We should make it 
usable with the existing xattr interface in Linux but we can have other 
optional options that can help with performance and atomicity. 
Marc.

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

Hi Chuck,

I agree that operations on single xattrs are likely required, and think 
that
your suggestion of interface is probably close to what several of us are 
thinking.

I think there are some rather obvious problems with Linux's fgetxattr 
interface
specifically (like inducing multiple calls or buffer size guessing), but I 
can't
see those showing up in the NFS versions of these.

I would concur with Nico (downthread) that traditional file delegation as 
you
propose should be sufficient.  (And would help with the use cases Marc and 
Benny
were I think speaking of.)

Also, I would like to propose that we define a single namespace for named 
attributes and
xattrs, should a server implementation choose to support both.

Matt

http://linuxbox.com

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

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 6 Nov 2013 13:25:01 -0500

I suggest that first you guys get together an I-D that addresses your critical protocol requirement.  Once you have that, you can consider possible improvements/optimizations.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Eshel
Sent: Wednesday, November 06, 2013 1:00 PM
To: Matt W. Benjamin
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Using a NFSv4 attribute for xattrs

I agree that the interface should allow for individual attributes to be manipulated separately, but it is also useful to have operations on all attributes as a blab. There should be a maximum size that is supported for all xattr per file that the client can query and than just read it all in one read operation and than look for the specific attribute in the buffer instead of dealing with reading a list of attributes. We should make it usable with the existing xattr interface in Linux but we can have other optional options that can help with performance and atomicity. 
Marc.

Hi Chuck,

I agree that operations on single xattrs are likely required, and think that your suggestion of interface is probably close to what several of us are thinking.

I think there are some rather obvious problems with Linux's fgetxattr interface specifically (like inducing multiple calls or buffer size guessing), but I can't see those showing up in the NFS versions of these.

I would concur with Nico (downthread) that traditional file delegation as you propose should be sufficient.  (And would help with the use cases Marc and Benny were I think speaking of.)

Also, I would like to propose that we define a single namespace for named attributes and xattrs, should a server implementation choose to support both.

Matt

http://linuxbox.com

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

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4