NFSv4 Working Group                                              M. Naik
Internet Draft                                                  M. Eshel
Intended Status: Standards Track                             IBM Almaden
Expires: February 1, 19, 2016                                  July 31,                               August 18, 2015

          Support for

                File System Extended Attributes in NFSv4
                       draft-ietf-nfsv4-xattrs-00
                       draft-ietf-nfsv4-xattrs-01

Abstract

   This document proposes extensions to existing the NFSv4 operations to protocol which allow
   file extended attributes (here forth (hereinafter also referred to as xattrs) to
   be manipulated in the protocol. using NFSv4.  An xattr is a file system feature that
   allows opaque metadata, not interpreted by the file system, to be
   associated with files and directories and are supported
   by directories.  Such support is present in
   many modern local file systems.  New file attributes are proposed to
   allow clients to query the server for xattr support, and new
   operations to get and set xattrs on file system objects. objects are provided.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2
   2.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3
   3.  File System Support  . . . . . . . . . . . . . . . . . . . . . .  5
   4
   4.  Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5
   5.  Differences with from Named Attributes  . . . . . . . . . . . . . . .  6  6  Protocol Enhancements
   6.  XDR Description  . . . . . . . . . . . . . . . . . . . . .  7
     6.1  New Attributes . .  7
     6.1.  Code Components Licensing Notice . . . . . . . . . . . . .  7
   7.  Protocol Extensions  . . . . . . .  7
       6.1.1  Attribute 82: xattr_support . . . . . . . . . . . . . .  7
     6.2  9
     7.1.  New Operations definition . . . . . . . . . . . . . . . . . . . . . .  7
       6.2.1  9
       7.1.1.  xattr4 . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.2.  New definitions Attribute  . . . . . . . . . . . . . . . . . . . .  8
       6.2.2  Caching . . 10
       7.2.1.  xattr_support  . . . . . . . . . . . . . . . . . . . . 10
     7.3.  New Operations . . . . . .  9
       6.2.3 . . . . . . . . . . . . . . . . 10
       7.3.1.  GETXATTR - Get an extended attribute of a file . . . .  9
       6.2.4 11
       7.3.2.  SETXATTR - Set an extended attribute of a file . . . . 10
       6.2.5 12
       7.3.3.  LISTXATTR - List extended attributes of a file . . . . 12
       6.2.6 14
       7.3.4.  REMOVEXATTR - Remove an extended attribute of a file . 13
       6.2.7 16
       7.3.5.  Valid Errors . . . . . . . . . . . . . . . . . . . . . 14
     6.3  Extensions 17
     7.4.  Modifications to ACE Access Mask Attributes Existing Operations . . . . . . . . . 16
     6.4  pNFS Considerations . . 18
     7.5.  Numeric Values Assigned to Protocol Extensions . . . . . . 20
     7.6.  Caching  . . . . . . . . . . . . 16
   7  Security Considerations . . . . . . . . . . . . . 21
     7.7.  Xattrs and File Locking  . . . . . . . . 16
   8  IANA . . . . . . . . . 22
     7.8.  pNFS Considerations  . . . . . . . . . . . . . . . . . . . 23
   8.  Security Considerations  . . . . 16
   9  References . . . . . . . . . . . . . . . 23
   9.  IANA Considerations  . . . . . . . . . . . 17
     9.1  Normative . . . . . . . . . . 23
   10.  References  . . . . . . . . . . . . . . . . . . . 17
     9.2  Informative . . . . . . 24
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 17
   10  Acknowledgements 24
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 24
   Appendix A.  Acknowledgements  . . . . . . 17 . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

1 26

1.  Introduction

   Extended attributes, also called xattrs, are a means to associate
   opaque metadata with file system objects, typically organized in
   key/value pairs.  They are especially useful when they add
   information that is not, or cannot be, present in the associated
   object itself.  User-space applications can arbitrarily create, read from,
   interrogate, and write modify to the key/value pairs.

   Extended attributes are file system-agnostic; applications use an
   interface not specific to any file system to manipulate them.
   Applications do not need to be concerned about how the key/value
   pairs are stored internally on within the underlying file system.  All
   major operating systems provide various flavors of extended
   attributes.  Many user space tools allow xattrs to be included in
   attributes that need to be preserved when objects are updated, moved
   or copied.

   Extended attributes have long previously been considered unsuitable for
   portability
   portable use because they some aspects of their handling are inadequately not precisely
   defined and they are not formally documented by any standard (such as
   POSIX). However, evidence
   suggests  Nevertheless, it appears that xattrs are widely deployed and
   their support in modern disk-based file systems is fairly nearly universal.

   There are is no clear indications on specification of how xattrs can could be mapped to any
   existing recommended or optional file attributes defined in RFC 5661
   [2]; thereby the NFSv4 protocol ([RFC7530],
   [RFC5661], [NFSv42]).  As a result, most NFS NFSv4 client implementations
   ignore application-
   specified application-specified xattrs.  This state of affairs results
   in data loss if one copies, over the NFS protocol, a file with xattrs
   from one file system to another that also supports xattrs.

   There is thus a relatively strong interest in the community in need to provide a means by which such data loss can
   be avoided.  This will involve exposing xattrs over NFS within the NFSv4
   protocol, despite the shortcomings. lack of completely compatible file system
   implementations.

   This document discusses why (in Section 5) the current reasons that NFSv4 named
   attributes as currently standardized in [2], [RFC7530], are unsuitable for
   representing
   xattrs, and xattrs.  Instead, it proposes alternate language, adjustment and a separate protocol
   mechanisms
   mechanism to support them.

1.1 xattrs.  As a consequence, xattrs and named
   attributes will both be optional features with servers free to
   support either, both, or neither.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1]. [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

2

2.  Use Cases

   Applications can store tracking information in extended attributes.
   Examples include storing metadata identifying the application that
   created the file, a tag to indicate when the file was last verified
   by a data integrity scrubber, or a tag to hold a checksum/crypto hash
   of the file contents along with the date of that signature.  Xattrs
   can also be used for decorations or annotations.  For example, a file
   downloaded from a web server can be tagged with the URL, which can be
   convenient if its source has to be determined in the future.
   Likewise, an email attachment, when saved, can be tagged with the
   message-id of the email, making it possible to trace the original
   message.

   Applications may need to behave differently when handling files of
   varying types.  For example, file managers, such as GNOME's, offer
   unique icons, different click behavior, and special lists of
   operations to perform depending on the file format.  This can be
   achieved by looking at the file extension (Windows), or interpret the
   type by inspecting it (Unix MIME type).  Some file managers generate
   this information on the fly; others generate the information once and
   then cache it.  Those that cache the information tend to put it in a
   custom database.  The file manager must work to keep this database in
   sync with the files, which can change without the file manager's
   knowledge.  A better approach is to jettison dispense with the custom database
   and store such metadata in extended attributes: these are attributes.  This is easier to
   maintain, provides faster to access, and is readily accessible by any application
   [5].
   applications [Love].

   Swift, the OpenStack distributed object store, uses xattrs to store
   an object's metadata along with all the data together in one file.
   Swift-on-File [9] [Swift] transfers the responsibility of maintaining
   object durability and availability to the underlying file system.
   Today, this requires a native file system client to mount the
   volumes.  Xattr support in NFS would open up the possibility of
   storing and consuming data from other storage systems, and facilitate
   the migration of data between different backend storage systems.

   Baloo, the file indexing and search framework for KDE, has moved to
   storing metadata such as tags, ratings and comments, in file system
   xattrs instead of a custom database for simplicity.  Starting with
   KDE Plasma 5.1, NFS is no longer supported due to its lack of xattr
   support [10].

3 [KDE].

3.  File System Support

   Extended attributes are supported by most modern file systems.

   In Linux, ext3, ext4, JFS, XFS, Btrfs, among other file systems systems,
   support extended attributes.  The getfattr and setfattr utilities can
   be used to retrieve and set xattrs.  The names of the extended
   attributes must be prefixed by the name of the category and a dot;
   hence these categories are generally qualified as name spaces.
   Currently, four namespaces exist: user, trusted, security and system
   [5].
   [Love].  Recommendations on how they should be used have been
   published
   [4]. [freedesktop].

   FreeBSD supports extended attributes in two universal namespaces -
   user and system, although individual file systems are allowed to
   implement additional namespaces [6]. [FreeBSD].

   Solaris 9 and later allows files to have extended attributes, but
   implements them as "forks", logically represented as files within a
   hidden directory that is associated with the target file [7]. [fsattr].

   In the NTFS file system, extended attributes are one of several
   supported "file streams" [8]. [NTFS].

   Xattrs can be retrieved and set through system calls or shell
   commands and generally supported by user-space tools that preserve
   other file attributes.  For example, the "rsync" remote copy program
   will correctly preserve user extended attributes between Linux/ext4
   and OSX/hfs by stripping off the Linux-specific "user." prefix.

4

4.  Namespaces

   Operating systems may define multiple "namespaces" in which xattrs
   can be set.  Namespaces are more than organizational classes; the
   operating system may enforce different access policies and allow
   different capabilities depending on the namespace.  Linux, for
   example, defines "security", "system", "trusted" and "user"
   namespaces, the first three being specific to Linux [4]. [freedesktop].

   Implementations generally agree on the semantics of a "user"
   namespace, that allows applications to store arbitrary user attribute
   data with file system objects.  Access to this namespace is
   controlled via the normal file system attributes.  As such, getting
   and setting xattrs from the user namespace can be considered
   interoperable across platforms and vendor implementations.
   Attributes from other namespaces are typically platform-specific, but some of them may be
   generalized into well-defined set of names that promote interoperable
   implementations. Similarly, attaching the namespace to the attribute
   key can avoid conflicting use of attributes. platform-specific.

   This document restricts the allowed provides for namespaces to supporting user-managed
   metadata only, in order thus avoiding the need to prevent specify the semantics
   applicable to particular system-interpreted xattrs.  The values of
   xattrs are considered application data just as the development contents of non-
   interoperable implementations. It requires that named
   attributes, files, and symbolic links are.  Servers have a
   responsibility to store whatever value the attribute
   key/value client specifies and to
   return it on demand. xattr keys and values MUST not NOT be interpreted by
   the NFS clients and servers.

5 servers, as such behavior would lead to non-
   interoperable implementations.  If there is a need to specify
   attributes that servers need to be act upon, the appropriate
   semantics need to be specified by adding a new attribute for the
   purpose as provided by [RFC7530] and [NFSv4-vers].

5.  Differences with from Named Attributes

   RFC5661

   [RFC7530] defines named attributes as opaque byte streams that are
   associated with a directory or file and referred to by a string name
   [2]. name.
    Named attributes are intended to be used by client applications as a
   method to associate application-specific data with a regular file or
   directory.  In that sense, xattrs are similar in concept and use to
   named attributes, but there are subtle differences.

   File systems typically define individual xattrs "get" and "set" operations to get and set individual
   xatrrs as being atomic, although  collectively they may be
   independent.  Xattrs generally have size limits ranging from a few
   bytes to several kilobytes; the maximum supported size is not
   universally defined and is usually restricted by the file system.
   Similar to ACLs, the amount of xattr data exchanged between the
   client and server for get/set operations can be considered to fit in
   a single COMPOUND request, bounded by the channel's negotiated
   maximum size for requests.  Named attributes, on the other hand, are
   unbounded data streams and do not impose atomicity requirements.

   Individual named attributes are analogous to files, and caching of
   the data for these needs to be handled just as data caching is for
   ordinary files following close-to-open semantics.  Xattrs, on the
   other hand, impose caching requirements like other file attributes.

   Named attributes and xattrs have different semantics and belong to
   disjoint namespaces.  As a result, mapping one to another is, at
   best, a compromise.

   While it should be possible to write guidance about how a client can
   use the named attribute mechanism to act like xattrs, such as carving
   out some namespace and specifying locking primitives to enforce
   atomicity constraints on individual get/set operations, this is
   problematic.  A client application trying to use xattrs through named
   attributes with a server that supported xattrs directly would get a
   lower level of service, and could fail to cooperate on a local
   application running on the server unless the server file system
   defined its own interoperability constraints.  File systems that
   already implement xattrs and named attributes natively would need
   additional guidance such as reserving named attribute namespace
   specifically for implementation purposes.

6  Protocol Enhancements

6.  XDR Description

   This section proposes extensions to document contains the NFSv4 protocol operations to
   allow xattrs to be queried and modified by clients. A new attribute
   is added to bitmap4 external data type to allow xattr support to be queried.
   This follows representation (XDR)
   [RFC4506] description of the guidelines specified extended attributes.  The XDR
   description is embedded in [2] with respect to minor
   versioning. In addition, new operations, namely GETXATTR, SETXATTR,
   LISTXATTR and REMOVEXATTR are defined this document in a way that makes it
   simple for the reader to allow xattr key/value to be
   queried and set.

6.1  New Attributes extract into a ready-to-compile form.  The following RECOMMENDED attribute is proposed for use with GETATTR.
   A client
   reader can query feed this document into the server following shell script to determine
   produce the machine readable XDR description of extended attributes:

   <CODE BEGINS>

   #! /bin/sh
   grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'

   <CODE ENDS>

   That is, if xattrs are supported by
   setting the xattr_support bit above script is stored in the GETATTR request.

   +------------------+----+-------------------+-----+----------------+
   |Name              | Id | Data Type         | Acc | Defined a file called "extract.sh",
   and this document is in     |
   +------------------+----+-------------------+-----+----------------+
   | xattr_support    | 82 | bool              | R   | Section 6.1.1  |
   +------------------+----+-------------------+-----+----------------+

6.1.1  Attribute 82: xattr_support

   True, if a file called "spec.txt", then the object's reader can
   do:

   sh extract.sh < spec.txt > xattr_prot.x

   The effect of the script is to remove leading white space from each
   line, plus a sentinel sequence of "///".

   The embedded XDR file system supports extended attributes. header follows.  Subsequent XDR descriptions,
   with the sentinel sequence are embedded throughout the document.

   Note that the protocol does not enforce any limits XDR code contained in this document depends on types
   from the number of
   keys, proposed NFSv4.2 nfs4_prot.x file [NFSv42-dot-x].  This
   includes both nfs types that end with a 4, such as verifier4, count4,
   etc., as well as more generic types such as opaque and bool.

6.1.  Code Components Licensing Notice

   Both the length XDR description and the scripts used for extracting the XDR
   description are Code Components as described in Section 4 of a key or "Legal
   Provisions Relating to IETF Documents" [LEGAL].  These Code
   Components are licensed according to the size terms of a value, or that document.

   <CODE BEGINS>

   /// /*
   ///  * Copyright (c) 2012 IETF Trust and the total size persons identified
   ///  * as authors of xattrs the code.  All rights reserved.
   ///  *
   ///  * Redistribution and use in source and binary forms, with
   ///  * or without modification, are permitted provided that the
   ///  * following conditions are allowed for a file. The server file system MAY
   impose additional limits. In addition, a single xattr key or value
   exchanged between met:
   ///  *
   ///  * o Redistributions of source code must retain the client above
   ///  *   copyright notice, this list of conditions and server for get/set operations is
   limited by the channel's negotiated maximum size for requests
   ///  *   following disclaimer.
   ///  *
   ///  * o Redistributions in binary form must reproduce the above
   ///  *   copyright notice, this list of conditions and
   responses.

6.2  New Operations

   Unlike the
   ///  *   following disclaimer in the documentation and/or other file system attributes, xattrs can represent disparate
   metadata most file systems allow disparate metadata to be associated
   ///  *   materials provided with an object through one the distribution.
   ///  *
   ///  * o Neither the name of Internet Society, IETF or more xattrs, and combining them into a
   single attribute is unwieldy. As such, adding new attributes IETF
   ///  *   Trust, nor the names of specific contributors, may be
   ///  *   used to
   bitmap4 endorse or promote products derived from this
   ///  *   software without specific prior written permission.
   ///  *
   ///  *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
   ///  *   AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
   ///  *   WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
   ///  *   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
   ///  *   FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
   ///  *   EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
   ///  *   LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
   ///  *   EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
   ///  *   NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
   ///  *   SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
   ///  *   INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
   ///  *   LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   ///  *   OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
   ///  *   IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
   ///  *   ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
   ///  *
   ///  * This code was derived from RFCTBD10.
   ///  * Please reproduce this note if possible.
   ///  */

   /// /*
   ///  * xattr_prot.x
   ///  */
   /// /*
   ///  * The following include statements are for use in GETATTR example only.
   ///  * The actual XDR definition files are generated separately
   ///  * and SETATTR is inappropriate independently and are likely to support
   xattr operations. For example, obtaining the value of a single xattr
   using the bitmap would require have a client implementation different name.
   ///  * %#include <nfsv42.x>
   ///  * %#include <rpc_prot.x>
   ///  */

   <CODE ENDS>

7.  Protocol Extensions

   This section documents extensions to read all
   the xattrs of the file and find a match for the one requested.
   Similarly, replacing or deleting a single xattr while keeping the
   others intact would require a client NFSv4 protocol operations to read the
   allow xattrs first,
   replacing the existing list with a modified list that excludes the
   one to be deleted, queried and writing out modified by clients.  A new attribute
   is added to allow clients to check if the remaining server supports xattrs. Moreover,
   distinguishing between creating new
   New operations are defined to allow xattr keys and replacing existing xattrs on
   an object is not possible with values to be
   queried and set.  In addition, new bitmask constants are added to the existing bitmap.

   Applications need
   ACE access mask field to perform validate permissions to query and modify
   xattrs.

   These changes follow applicable guidelines for valid NFSv4 protocol
   extension, whether the following operations on extensions occur in a given
   file's extended attributes [5]:

   o  Given a file, return a list of all of the file's assigned extended
      attribute keys.

   o  Given a file and a key, return the corresponding value.

   o  Given a file, a key, and a value, assign that value to the key.

   o  Given a file and a key, remove that extended attribute from the
      file.

   This section introduces four new operations, GETXATTR, SETXATTR,
   LISTXATTR and REMOVEXATTR, to query, set, list and remove xattrs
   respectively. GETXATTR allows obtaining the value of an xattr key,
   SETXATTR allows creating minor version (as
   specified in [RFC5661]) or replacing as an xattr key with a value,
   LISTXATTR enumerates all the xattrs names, and REMOVEXATTR allows
   deleting a single xattr.

6.2.1 extension to an existing minor
   version (as specified in [NFSv4-vers]).

7.1.  New definitions definition

7.1.1.  xattr4

   The NFS xattr NFSv4 xattr4 structure is defined as follows:

   <CODE BEGINS>

   /// typedef utf8str_cis component4     xattrname4;
   /// typedef opaque         xattrvalue4<>;

   /// struct xattr4 {
   ///         xattrname4     xa_name;
   ///         xattrvalue4    xa_value;
   /// };

   <CODE ENDS>

   Each xattr, defined by xattr4, is a key/value pair.  An xattr4
   consists of an xattrname4 which is a
   UTF-8 string denoting the xattr key
   name, xattrvalue4 and an attrvalue4 which is a variable
   length variable-length string that
   identifies the values value of a specified the xattr.  The
   size handling of the xattr xattrname4 with
   regard to internationalization-related issues is a combination of the size of its name
   represented by xattrname4, same as that for
   NFSv4 file names and its value represented by xattrvalue4. named attribute names, as described in
   [RFC7530].  Any regular file or directory may have an array set of xattr4, extended
   attributes, each consisting of a key and associated value.  The NFS
   client or server MUST NOT interpret the contents of xattr4. Similar to ACLs, the

7.2.  New Attribute

   The following RECOMMENDED per-fs read-only attribute is proposed for
   use.  A client can use query the OPEN or ACCESS operations to check access without
   modifying or reading data or metadata.

6.2.2  Caching

   The caching behavior for extended attributes is similar server to other determine if xattrs are
   supported by setting the xattr_support bit in the GETATTR request.

7.2.1.  xattr_support

   True, if the object's file
   attributes such as ACLs and system supports extended attributes.

   Since xattr_support is affected by whether OPEN delegation
   has been granted to not a client or not.

   When a delegation is in effect, an operation by REQUIRED attribute, server need not
   support it.  However, a second client to may reasonably assume that a
   delegated file will cause the server to recall
   (or file system) that does not support the delegation through
   a callback. For individual operations, we will describe, under
   IMPLEMENTATION, when such operations are required to effect a recall.

   When xattr_support attribute
   does not provide xattr support and act on that basis.

   Note that the client protocol does not hold a delegation enforce any limits on the file, xattrs
   obtained from number of
   keys, the server may be cached and clients can use them to
   avoid subsequent GETXATTR requests. Such caching is write through in
   that modification to xattrs is always done by means length of requests to a key or the server and should not be only done locally. Due to size of a value, or the relative
   infrequency total size
   of xattr updates, it is suggested xattrs that all changes be
   propagated synchronously. The client MUST NOT maintain are allowed for a cache of
   modified xattrs. file.  The result of local caching is that the xattrs maintained on
   individual clients may not be coherent. Changes made in one order on
   the server may be seen in file system MAY
   impose additional limits.  In addition, a different order on one single xattr key or value
   exchanged between the client and in server for get/set operations is
   limited by the channel's negotiated maximum size for requests and
   responses.

7.3.  New Operations

   Individual xattrs generally represent separate items of metadata.
   For various reasons, combining them into a
   third order on another client. single attribute results
   in clumsy implementations with significant functional deficits.  In order
   consequence, adding a new attribute to manage represent the incoherency
   caused by separate operations to obtain set of xattrs and other file
   attributes,
   for an object is not an appropriate way to provide support for
   xattrs.

   For example, obtaining the value of a single xattr using the bitmap
   would require a client should treat xattrs just like other file
   attributes with respect implementation to caching as detailed in section 10.6 read all the xattrs of RFC
   5661 [2]. A the
   file and find a match for the one requested.  Similarly, replacing or
   deleting a single xattr while keeping the others intact would require
   a client may validate its cached version of to read the xattrs for first, replacing the existing list with a
   file by fetching both
   modified list that excludes the change and time_access attributes one to be deleted, and
   assuming that if writing out
   the change attribute has remaining xattrs.  Such a read-modify-write cycle is subject to
   updates being lost in the case of simultaneous updates by multiple
   clients.  In addition, two clients might simultaneously add the same value as
   xattr key to the same file with each concluding that it did the
   initial creation for the common xattr key, when the attributes were cached, then xattrs semantic model
   implies that only one could have not changed.

6.2.3  GETXATTR - Get an done so.

   Applications need to perform the following operations on a given
   file's extended attribute of attributes [Love]:

   o  Given a file

6.2.3.1 	ARGUMENTS

        struct GETXATTR4args {
                /* CURRENT_FH: file */
                xattrname4    ga_name;
        };

6.2.3.2	RESULTS

        union GETXATTR4res switch (nfsstat4 gr_status) {
         case NFS4_OK:
                xattrvalue4   gr_value;
         default:
                void;
        };

6.2.3.3	DESCRIPTION

   The GETXATTR operation will obtain the value for file, return a list of all of the given file's assigned extended
      attribute key for the keys.

   o  Given a file system object specified by the current
   filehandle.

   The server MUST and a key, return the xattr value for the key that the corresponding value.

   o  Given a file, a key, and a value, assign that value to the key.

   o  Given a file and a key, remove that extended attribute from the
      file.

   This section introduces four new RECOMMENDED operations, GETXATTR,
   SETXATTR, LISTXATTR and REMOVEXATTR, to query, set, list and remove
   xattrs respectively.  GETXATTR allows obtaining the value of an xattr
   key, SETXATTR allows creating or replacing an xattr key with a value,
   LISTXATTR enumerates all the xattrs names, and REMOVEXATTR allows
   deleting a single xattr.

7.3.1.  GETXATTR - Get an extended attribute of a file

7.3.1.1.  ARGUMENTS

   <CODE BEGINS>

   /// struct GETXATTR4args {
   ///         /* CURRENT_FH: file */
   ///         xattrname4    ga_name;
   /// };

   <CODE ENDS>

7.3.1.2.  RESULTS

   <CODE BEGINS>

   /// union GETXATTR4res switch (nfsstat4 gr_status) {
   ///  case NFS4_OK:
   ///         xattrvalue4   gr_value;
   ///  default:
   ///         void;
   /// };

   <CODE ENDS>

7.3.1.3.  DESCRIPTION

   The GETXATTR operation will obtain the value for the given extended
   attribute key for the file system object specified by the current
   filehandle.

   The server will fetch the xattr value for the key that the client
   requests if xattrs are supported by the server for the target file
   system.  If the server does not support xattrs on the target file
   system, then it MUST NOT return a value and MUST return an error.
   The server also MUST return an error if it supports xattrs on the
   target but cannot obtain the requested data.  In that case, no value
   will be returned.  If the xattr value contained in the server
   response will
   exceed is such as to cause the channel's negotiated maximum
   response size, size to be exceeded, then the server MUST return
   NFS4ERR_REP_TOO_BIG in gr_status.

6.2.3.4

7.3.1.4.  IMPLEMENTATION

   If there is

   Clients that have cached an OPEN_DELEGATE_WRITE delegation held xattr may avoid the need to do a GETXATTR
   by another determining if the change attribute is the same as it was when the
   xattr was fetched.  If the client does not hold a delegation for the
   file in question, it can do so with a GETATTR request to obtain the
   change attribute and size and/or comparing its value to the change are among attribute
   value fetched when the set of xattr value was obtained.  This handling is
   similar to how a client would revalidate other file attributes being interrogated in such
   as ACLs.

   When responding to such a GETATTR, the server can will, if there is an
   OPEN_DELEGATE_WRITE delegation held by another client for the file in
   question, either obtain the actual current value of these attributes
   from the client holding the delegation by using the CB_GETATTR
   callback, or revoke the delegation.  See Section 18.7.4 of RFC 5661 [RFC5661]
   for details [2].
   Consequently, if a client needs to verify the list of extended
   attributes with the server, it must also query the change attribute
   of the file with GETATTR. This handling is similar to how a client
   would revalidate other file attributes such as ACLs.

6.2.4 details.

7.3.2.  SETXATTR - Set an extended attribute of a file

6.2.4.1

7.3.2.1.  ARGUMENTS

   <CODE BEGINS>

   /// enum setxattr_type4 {
   ///         SETXATTR4_CREATE      = 0,
   ///         SETXATTR4_REPLACE     = 1,
   /// };
   /// struct SETXATTR4args {
   ///         /* CURRENT_FH: file */
   ///         setxattr_type4 sa_type;
   ///         xattr4         sa_xattr;
   /// };

6.2.4.2

   <CODE ENDS>

7.3.2.2.  RESULTS

        union

   <CODE BEGINS>

   /// struct SETXATTR4res switch (nfsstat4 sr_status) {
   ///  case NFS4_OK:
                void;
   ///         change_info4      sr_info;
   ///  default:
   ///         void;
   /// };

6.2.4.3

   <CODE ENDS>

7.3.2.3.  DESCRIPTION

   The SETXATTR operation changes one extended attribute of a file
   system object.  The change desired is specified by sa_type.
   SETXATTR4_CREATE is used to associate the given value with the given
   extended attribute key for the file system object specified by the
   current filehandle.  The server MUST return an error if the attribute
   key already exists.  SETXATTR4_REPLACE is also used to set an xattr,
   but the server MUST return an error if the attribute key does not
   exist.

   If the xattr key and/or and value contained in the client request exceeds are such
   that the request would exceed the channel's negotiated maximum
   request size, then the server MUST return NFS4ERR_REQ_TOO_BIG in
   sr_status.  If the server file system imposes additional limits on
   the size of key name or value, it MAY return NFS4ERR_ENOSPC. NFS4ERR_NAMETOOLONG.

   A successful SETXATTR SHOULD MUST change the file time_modify and change
   attributes.
   attributes if the xattr is created or the value assigned to xattr
   changes.  However, these attributes SHOULD NOT be changed unless if this
   causes no actual change in the xattr value.

   On success, the server returns the change_info4 information in
   sr_info.  With the atomic field of the change_info4 data type, the
   server will indicate if the before and after change attributes were
   obtained atomically with respect to the SETXATTR operation.  This
   allows the client to determine if its cached xattrs are changed.

6.2.4.4 still valid
   after the operation.  See Section 7.6 for a discussion on xattr
   caching.

7.3.2.4.  IMPLEMENTATION

   If the object whose xattr is being changed has a file delegation that
   is held by a client other than the one doing the SETXATTR, the
   delegation(s) must be recalled, and the operation cannot proceed to
   actually change the xattr until each such delegation is returned or
   revoked.  In all cases in which delegations are recalled, the server
   is likely to return one or more NFS4ERR_DELAY errors while the
   delegation(s) remains outstanding, although it might not do that if
   the delegations are returned quickly.

6.2.5

7.3.3.  LISTXATTR - List extended attributes of a file

6.2.5.1

7.3.3.1.  ARGUMENTS

   <CODE BEGINS>

   /// struct LISTXATTR4args {
   ///         /* CURRENT_FH: file */
   ///         nfs_cookie4    la_cookie;
   ///         verifier4      la_cookieverf;
   ///         count4         la_maxcount;
   /// };

5.2.5.2

   <CODE ENDS>

7.3.3.2.  RESULTS

   <CODE BEGINS>

   /// struct LISTXATTR4resok (
   ///         nfs_cookie4    lr_cookie;
   ///         verifier4      lr_cookieverf;
   ///         bool           lr_eof;
   ///         xattrname4     lr_names<>;
   /// };

   /// union LISTXATTR4res switch (nfsstat4 lr_status) {
   ///  case NFS4_OK:
   ///         LISTXATTR4resok  lr_value;
   ///  default:
   ///         void;
   /// };

6.2.5.3

   <CODE ENDS>

7.3.3.3.  DESCRIPTION

   The LISTXATTR operation retrieves a variable number of extended
   attribute keys from the file system object specified by the current
   filehandle, along with information to allow the client to request
   additional attribute keys in a subsequent LISTXATTR.

   The arguments contain a cookie value that represents where the
   LISTXATTR should start within the list of xattrs.  A value of 0
   (zero) for la_cookie is used to start reading at the beginning of the
   list.  For subsequent LISTXATTR requests, the client specifies a
   cookie value that is provided by the server on a previous LISTXATTR
   request.

   The la_cookieverf value should be set to 0 (zero) when the la_cookie
   value is 0 (zero) (first xattr read).  On subsequent requests, it
   should be lr_cookieverf as returned by the server.  The la_cookieverf
   must match that returned by the LISTXATTR in which the cookie was
   acquired.  If the server determines that the la_cookieverf is no
   longer valid for the directory, the error NFS4ERR_NOT_SAME must be
   returned.

   The la_maxcount value of the argument is the maximum number of bytes
   for the result.  This maximum size represents all of the data being
   returned within the LISTXATTR4resok structure and includes the XDR
   overhead.  The server may return less data.  If the server is unable
   to return a single xattr name within the maxcount limit, the error
   NFS4ERR_TOOSMALL will be returned to the client.

   On successful return, the server's response will provide a list of
   extended attribute keys.  The "lr_eof" flag has a value of TRUE if
   there are no more keys for the object.

   The cookie value is only meaningful to the server and is used as a
   "bookmark" for the xattr key.  As mentioned, this cookie is used by
   the client for subsequent LISTXATTR operations so that it may
   continue listing keys.  The cookie is similar in concept to a READDIR
   cookie or the READ offset but should not be interpreted as such by
   the client.  Ideally, the cookie value should not change if the
   object xattr values is modified since the client may be caching these
   values.

   On success, the current filehandle retains its value.

6.2.5.4

7.3.3.4.  IMPLEMENTATION

   The handling of ls_cookie and ls_cookieverf is similar to that of the
   READDIR operation.  The cookieverf may be used by the server to help
   manage cookie values that may become stale.  It should be a rare
   occurrence that a server is unable to continue properly listing
   xattrs with the provided cookie/cookieverf pair.  The server should
   make every effort to avoid this condition since the application at
   the client may not be able to properly handle this type of failure.

    The use of the ls_cookieverf will also protect the client from using
   LISTXATTR cookie values that may be stale.  For example, if the file
   system has been migrated, the server may or may not be able to use
   the same cookie values to service LISTXATTR as the previous server
   used.  With the client providing the ls_cookieverf, the server is
   able to provide the appropriate response to the client.  This
   prevents the case where the server may accept a cookie value but the
   underlying object xattrs have changed and the response is invalid
   from the client's context of its previous LISTXATTR.

6.2.6

7.3.4.  REMOVEXATTR - Remove an extended attribute of a file

6.2.6.1

7.3.4.1.  ARGUMENTS

   <CODE BEGINS>

   /// struct REMOVEXATTR4args {
   ///         /* CURRENT_FH: file */
   ///         xattrname4     ra_name;
   /// };

6.2.6.2

   <CODE ENDS>

7.3.4.2.  RESULTS

        union

   <CODE BEGINS>

   /// struct REMOVEXATTR4res switch (nfsstat4 rr_status) {
   ///  case NFS4_OK:
                void;
   ///         change_info4      rr_info;
   ///  default:
   ///         void;
   /// };

6.2.6.3

   <CODE ENDS>

7.3.4.3.  DESCRIPTION

   The REMOVEXATTR operation deletes one extended attribute of a file
   system object specified by ra_name.  The server MUST return an error
   if the attribute key does not exist.  If the xattr key contained in
   the client request exceeds the channel's negotiated maximum request
   size, then the server MUST return NFS4ERR_REQ_TOO_BIG in rr_status.

   A successful REMOVEXATTR SHOULD change the file time_modify and
   change attributes.  However, these attributes SHOULD NOT be changed
   unless the xattr is not removed.

6.2.6.4

   Similar to SETXATTR, the server communicates the value of the change
   attribute immediately prior to, and immediately following, a
   successful REMOVEXATTR operation in rr_info.  This allows the client
   to determine if its cached xattrs are still valid after the
   operation.  See Section 7.6 for a discussion on xattr caching.

7.3.4.4.  IMPLEMENTATION

   If the object whose xattr is being removed has a file delegation that
   is held by a client other than the one doing the REMOVEXATTR, the
   delegation(s) must be recalled, and the operation cannot proceed to
   delete the xattr until each such delegation is returned or revoked.
   In all cases in which delegations are recalled, the server is likely
   to return one or more NFS4ERR_DELAY errors while the delegation(s)
   remains outstanding, although it might not do that if the delegations
   are returned quickly.

6.2.7

7.3.5.  Valid Errors

   This section contains a table that gives the valid error returns for
   each new protocol operation.  The error code NFS4_OK (indicating no
   error) is not listed but should be understood to be returnable by all
   new operations.  The error values for all other operations are
   defined in Section 15.2 13.2 of RFC 5661 [2]. [RFC7530].

          Valid Error Returns for Each New Protocol Operation

   +----------------------+--------------------------------------------+
   | Operation            | Errors                                     |
   +----------------------+--------------------------------------------+
   | GETXATTR             | NFS4ERR_ACCESS, NFS4ERR_BADXDR,            |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,        |
   |                      | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE,          |
   |                      | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR,          |
   |                      | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG,                 |
   |                      | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP,     | |
   | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_NOTDIR,                      | NFS4ERR_NOTSUPP, NFS4ERR_OP_NOT_IN_SESSION,|
   |                      | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG,         |
   |                      | NFS4ERR_REP_TOO_BIG_TO_CACHE,              |
   |                      | NFS4ERR_REQ_TOO_BIG,                       |
   |                      | NFS4ERR_RETRY_UNCACHED_REP,                |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE   |
   | SETXATTR             | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |
   |                      | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR,           |
   |                      | NFS4ERR_BADOWNER, NFS4ERR_BAD_RANGE,       |
   |                      | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,       |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,       |
   |                      | NFS4ERR_DELEG_REVOKED, NFS4ERR_DELAY, NFS4ERR_DQUOT,              |
   |                      | NFS4ERR_EXIST, NFS4ERR_EXPIRED,            |
   |                      | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED,          |
   |                      | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO,  |
   |                      | NFS4ERR_LOCKED, NFS4ERR_MOVED,  |
   |                      | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, |
   |                      | NFS4ERR_NOSPC, NFS4ERR_NOTDIR,             |
   |                      | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,     |
   |                      | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM,  |
   |                      | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG,         |
   |                      | NFS4ERR_REP_TOO_BIG_TO_CACHE,              |
   |                      | NFS4ERR_REQ_TOO_BIG,                       |
   |                      | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS,  |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOO_MANY_OPS,                      |
   |                      | NFS4ERR_UNKNOWN_LAYOUTTYPE,                |
   |                      | NFS4ERR_WRONG_TYPE   |
   | LISTXATTR            | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,        |
   |                      | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE,       |
   |                      | NFS4ERR_DELAY, NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR,  |
   |                      | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG,        |
   |                      | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP,     |
   |                      | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_NOTDIR,                 |
   |                      | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG,         |
   |                      | NFS4ERR_REP_TOO_BIG_TO_CACHE,              |
   |                      | NFS4ERR_REQ_TOO_BIG,                       |
   |                      | NFS4ERR_RETRY_UNCACHED_REP,                |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE   |
   | REMOVEXATTR          | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |
   |                      | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR,           |
   |                      | NFS4ERR_BADOWNER, NFS4ERR_BAD_RANGE,       |
   |                      | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,       |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,       |
   |                      | NFS4ERR_DELEG_REVOKED, NFS4ERR_DELAY, NFS4ERR_DQUOT,              |
   |                      | NFS4ERR_EXIST, NFS4ERR_EXPIRED,            |
   |                      | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED,           |
   |                      | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_INVAL, NFS4ERR_IO,  |
   |                      | NFS4ERR_LOCKED, NFS4ERR_MOVED,             |
   |                      | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, |
   |                      | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, NFS4ERR_OLD_STATEID,        |
   |                      | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,                          |
   |                      | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM,   |
   |                      | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS,  |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOO_MANY_OPS,                      |
   |                      | NFS4ERR_UNKNOWN_LAYOUTTYPE,                |
   |                      | NFS4ERR_WRONG_TYPE   |
   +----------------------+--------------------------------------------+

6.3  Extensions

7.4.  Modifications to ACE Access Mask Attributes Existing Operations

   In order to provide fine-grained access control to query or modify
   extended attributes, additions are proposed to the set of access
   rights that can be checked to determine if the client is permitted to
   perform the xattr operation.

   Note that in general, as explained in Section 18.1.4 of [RFC5661], a
   client cannot reliably perform an access check with only current file
   attributes and must verify access with the server.

   This section extends the semantics of the ACCESS operation documented
   in Section 18.1 of [RFC5661].  Two new access permissions can be
   requested:

   ACCESS4_XAREAD     Query a file or directory for its xattr key and/or
                      value.

   ACCESS4_XAWRITE    Modify xattr keys and/or values of a file or
                      directory.

   As with the existing access permissions, the results of ACCESS are
   advisory in nature, with no implication that such access will be
   allowed or denied in the future.

   In addition, two new bitmask constants used for the access mask field
   are proposed added:

   ACE4_READ_XATTRS   Permission to interrogate the extended attributes
                      of a file with GETXATTR or LISTXATTR.

   ACE4_WRITE_XATTRS  Permission to change the extended attributes of a
                      file with SETXATTR or REMOVEXATTR.

   The rules for the client and server follow:

   o  If the client is sending ACCESS in order to determine if the user
      can read an xattr of the file with GETXATTR or list the xattr keys
      of the file with LISTXATTR, the client SHOULD set ACCESS4_XAREAD
      in the request's access field.

   o  If the client is sending ACCESS in order to determine if the user
      can modify an xattr of the file with SETXATTR or REMOVEXATTR, the
      client SHOULD set ACCESS4_XAWRITE in the request's access field.

   o  If the server supports ACE4_READ_XATTRS permission bit, it MUST
      only check for it in the mode, acl, and dacl attributes when it
      receives an ACCESS request with ACCESS4_XAREAD set in the access
      field.

   o  If the server supports ACE4_WRITE_XATTRS permission bit, it MUST
      only check for it in the mode, acl, and dacl attributes when it
      receives an ACCESS request with ACCESS4_XAWRITE set in the access
      field.

   Server implementations need not provide the granularity of control
   that is implied by this list of masks.  For example, POSIX-based
   systems might not distinguish ACE4_XAREAD from ACE4_READ_ATTRIBUTES
   (or ACE4_READ_DATA); both masks would be tied to a single "stat" (or
   "read") permission.  When such a server returns attributes to the
   client, it would show both ACE4_READ_ATTRIBUTES (or ACE4_READ_DATA)
   and ACE4_XAREAD if and only if the stat (or read) permission is
   enabled.

   If a server receives a SETXATTR request that it cannot accurately
   implement, it should err in the direction of more restricted access.
   For example, suppose a server cannot distinguish modifying attributes
   from updating xattr.  If a client submits an ALLOW ACE where
   ACE4_WRITE_ATTRIBUTES is set but ACE4_WRITE_XATTR is not (or vice
   versa), the server should either turn off ACE4_WRITE_ATTRIBUTES or
   reject the request with NFS4ERR_ATTRNOTSUPP.

7.5.  Numeric Values Assigned to Protocol Extensions

   This section lists the numeric values assigned new attributes and
   operations to implement the xattr feature.  To avoid inconsistent
   assignments, these have been checked against the most recent protocol
   version [RFC5661], the current minor version [NFSv42], and all
   extensions currently approved as working group documents.
   Development of interoperable prototypes should be possible using
   these values, although it is possible that these values may be
   modified before eventual publication as a standard-track document.

   <CODE BEGINS>

   /// /*
   ///  * ACCESS - Check Access Rights
   ///  */
   /// const ACCESS4_XAREAD    = 0x00000040;
   /// const ACCESS4_XAWRITE   = 0x00000080;

   /// /*
   ///  * ACE flag values
   ///  */
   /// const ACE4_READ_XATTRS        = 0x00200000;
   /// const ACE4_WRITE_XATTRS       = 0x00400000;

   /// /*
   ///  * New NFSv4 attribute
   ///  */
   /// typedef bool            fattr4_xattr_support;

   /// /*
   ///  * New RECOMMENDED Attribute
   ///  */
   /// const FATTR4_XATTR_SUPPORT = 81;
   /// /*
   ///  * New NFSv4 operations
   /// */
   /// /* Following lines are to be added to enum nfs_opnum4 */
   /// /*
   /// OP_GETXATTR                = 72,
   /// OP_SETXATTR                = 73,
   /// OP_LISTXATTR               = 74,
   /// OP_REMOVEXATTR             = 75,
   /// */

   <CODE ENDS>

7.6.  Caching

   The caching behavior for extended attributes is similar to other file
   attributes such as ACLs and is affected by whether OPEN delegation
   has been granted to a client or not.

   Xattrs obtained from, or sent to, the server may be cached and
   clients can use them to avoid subsequent GETXATTR requests, provided
   that the client can ensure that the cached value has not been
   subsequently modified by another client.  Such assurance can depend
   on the client holding a delegation for the file in question or the
   client interrogating the change attribute to make sure that any
   cached value is still valid.  Such caching may be read-only or write-
   through.

   When a delegation is in effect, some operations by a second client to
   a delegated file will cause the server to recall the delegation
   through a callback.  For individual operations, we describe, under
   IMPLEMENTATION, when such operations are required to effect a recall.

   The result of local caching is that the individual xattrs maintained
   on clients may not be up-to-date.  Changes made in one order on the
   server may be seen in a different order on one client and in a third
   order on another client.  In order to limit problems that may arise
   due to separate operations to obtain individual xattrs and other file
   attributes, a client should treat xattrs just like other file
   attributes with respect to caching as detailed in section 10.6 of
   [RFC7530].  A client may validate its cached version of an xattr for
   a file by fetching the change attribute and assuming that if the
   change attribute has the same value as it did when the attributes
   were cached, then xattrs have not changed.  If the client holds a
   delegation that ensures that the change attribute cannot be modified
   by another client, that it can dispense with actual interrogation of
   the change attribute.

   When a client is changing xattrs of a file, it needs to determine
   whether there have been changes made to the file by other clients.
   It does this by using the change attribute as reported before and
   after the change operation (SETXATTR or REMOVEXATTR) in the
   associated change_info4 value returned for the operation.  The server
   is able to communicate to the client whether the change_info4 data is
   provided atomically with respect to the change operation.  If the
   change values are provided atomically, the client has a basis for
   determining, given proper care, whether other clients are modifying
   the file in question.

   The simplest way to enable the client to make this determination is
   for the client to serialize all xattr changes made to a specific
   file.  When this is done, and the server provides before and after
   values of the change attribute atomically, the client can simply
   compare the after value of the change attribute from one operation
   with the before value on the subsequent change operation modifying
   the file.  When these are equal, the client is assured that no other
   client is modifying the file in question.

   If the comparison indicates that the file was updated by another
   client, the xattr cache associated with the modified file is purged
   from the client.  If the comparison indicates no modification, the
   xattr cache can be updated on the client to reflect the file
   operation and the associated timeout can be extended.  The post-
   operation change value needs to be saved as the basis for future
   change_info4 comparisons.

   Xattr caching requires that the client revalidate xattr cache data by
   inspecting the change attribute of a file at the point when an xattr
   was cached.  This requires that the server update the change
   attribute when xattrs are modified.  For a client to use the
   change_info4 information appropriately and correctly, the server must
   report the pre- and post-operation change attribute values
   atomically.  When the server is unable to report the before and after
   values atomically with respect to the xattr update operation, the
   server must indicate that fact in the change_info4 return value.
   When the information is not atomically reported, the client should
   not assume that other clients have not changed the xattrs.

   The protocol does not provide support for write-back caching of
   xattrs.  As such, all modifications to xattrs should be done by
   requests to the server.  The server should perform such updates
   synchronously.

7.7.  Xattrs and File Locking

   Xattr operations, for the most part, function independent of
   operations related to file locking state.  For example, xattrs can be
   interrogated and modified without a corresponding OPEN operation.
   The server does not need to check for locks that conflict with xattr
   access or modify operations.  For example, another OPEN specified
   with OPEN4_SHARE_DENY_READ or OPEN4_SHARE_DENY_BOTH does not prevent
   access to or modification of xattrs.  Note that the server MUST still
   verify that the client is allowed to perform the xattr operation on
   the basis of ACE access mask field:

         const ACE4_GET_XATTRS          = 0x00200000;
         const ACE4_SET_XATTRS          = 0x00400000;

   Permission to get/list and set/remove permissions.

   However, the extended attributes presence of a
   file. The affected delegations may dictate how xattr operations are GETXATTR/LISTXATTR and
   SETXATTR/REMOVEXATTR respectively. No additional granularity of
   control
   interact with the state-related logic.  Xattrs cannot be modified
   when a delegation for the corresponding file is implied held by these constants for server implementations.

6.4 another
   client.  On the other hand, xattrs can be interrogated despite the
   holding of a write delegation by another client since updates are
   write-through to the server.

7.8.  pNFS Considerations

   All xattr operations are sent to the metadata server, which is
   responsible for coordinating the fetching data from and effecting necessary changes onto the storage devices.

7 to
   persistent storage.

8.  Security Considerations

   The

   Since xattrs are application data, security issues are exactly the
   same as those relating to the storing of file data and named
   attributes.  These are all various sorts of application data and the
   fact that the means of reference is slightly different in each case
   should not be considered security-relevant.  As such, the additions
   to the NFS protocol for supporting extended attributes do not alter
   the security considerations of the NFSv4.1 NFSv4.2 protocol [2].

8 [NFSv42].

9.  IANA Considerations

   All IANA considerations

   The addition of xattr support to the NFSv4 protocol does not require
   any actions by IANA.  This document limits xattr names to the user
   namespace, where application developers are covered in [2].

9 allowed to define and use
   attributes as needed.  Unlike named attributes, there is no namespace
   identifier associated with xattrs that may require registration.

10.  References

9.1

10.1.  Normative References

   [1]

   [LEGAL]    IETF Trust, "Legal Provisions Relating to IETF Documents",
              November 2008, <http://trustee.ietf.org/docs/IETF-Trust-
              License-Policy.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI
              10.17487/RFC2119, March 1997.

   [2] 1997, <http://www.rfc-
              editor.org/info/rfc2119>.

   [RFC4506]  Eisler, M., Ed., "XDR: External Data Representation
              Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
              2006, <http://www.rfc-editor.org/info/rfc4506>.

   [RFC5661]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
              "Network File System (NFS) Version 4 Minor Version 1
              Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010.

   [3] 2010,
              <http://www.rfc-editor.org/info/rfc5661>.

   [RFC5662]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
              "Network File System (NFS) Version 4 Minor Version 1
              External Data Representation Standard (XDR) Description",
              RFC 5662, DOI 10.17487/RFC5662, January
        2010.

9.2 2010,
              <http://www.rfc-editor.org/info/rfc5662>.

   [RFC7530]  Haynes, T. and D. Noveck, "Network File System (NFS)
              Version 4 Protocol", RFC 7530, March 2015.

10.2.  Informative References

   [4]  http://www.freedesktop.org/wiki/CommonExtendedAttributes,

   [NFSv42]   Haynes, T., Ed., "NFS Version 4 Minor Version 2", April
              2015, <http://www.ietf.org/id/draft-ietf-nfsv4-
              minorversion2-38.txt>.

              Work in progress.

   [NFSv42-dot-x]
              Haynes, T., Ed., "NFS Version 4 Minor Version 2 Protocol
              External Data Representation Standard (XDR) Description",
              April 2015, <http://www.ietf.org/id/draft-ietf-nfsv4-
              minorversion2-dot-x-38.txt>.

              Work in progress.

   [NFSv4-vers]
              Haynes, T. and D. Noveck, "NFSv4 Version Management", July
              2015, <http://www.ietf.org/id/draft-ietf-nfsv4-versioning-
              01.txt>.

              Work in progress.

   [freedesktop]
              "Guidelines for extended attributes".

   [5] attributes",
              <http://www.freedesktop.org/wiki/CommonExtendedAttributes>.

   [Love]     Love, R., "Linux System Programming: Talking Directly to
              the Kernel and C Library", O'Reilly Media, Inc., 2007.

   [6]  http://www.freebsd.org/cgi/man.cgi?query=extattr&sektion=9,

   [FreeBSD]  "FreeBSD Man Pages - extattr"

   [7]  http://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02, extattr",
              <http://www.freebsd.org/cgi/man.cgi?query=extattr&sektion=9>.

   [fsattr]   "Oracle Man Pages - fsattr"

   [8]  http://msdn.microsoft.com/en-
        us/library/windows/desktop/aa364404(v=vs.85).aspx, fsattr",
              <http://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02>.

   [NTFS]     "File
        Streams"

   [9]  Swift-on-File: https://github.com/stackforge/swiftonfile

   [10] KDE Planet: http://vhanda.in/blog/2014/08/extended-attributes-
        updates/

10 Streams", <http://msdn.microsoft.com/en-
              us/library/windows/desktop/aa364404(v=vs.85).aspx>.

   [Swift]    "Swift-on-File",
              <https://github.com/stackforge/swiftonfile>.

   [KDE]      Handa, V., "KDE Planet",
              <http://vhanda.in/blog/2014/08/extended-attributes-
              updates/>.

Appendix A.  Acknowledgements

   This draft has attempted to capture the discussion on adding xattrs
   to the NFSv4 protocol from many participants on the IETF NFSv4
   mailing list. Valuable  Those who provided valuable input and advice was received comments on
   earlier revisions of this draft from several people on the NFSv4
        mailing list, including include: Tom Haynes, Christoph
   Hellwig and Nico Williams. Dave Noveck provided a comprehensive
   review of the previous revision of this draft.

Authors' Addresses

   Manoj Naik
   IBM Almaden
   650 Harry Rd
   San Jose, CA 95120

   Phone: +1 408-927-1707
   Email: mnaik@us.ibm.com

   Marc Eshel
   IBM Almaden
   650 Harry Rd
   San Jose, CA 95120

   Phone: +1 408-927-1894
   Email: eshel@us.ibm.com