Internet Engineering Task Force (IETF) M. Naik
Request for Comments: 8276 Nutanix
Category: Standards Track M. Eshel
ISSN: 2070-1721 IBM Almaden
December 2017
Internet Engineering Task Force (IETF) M. Naik
Request for Comments: 8276 Nutanix
Category: Standards Track M. Eshel
ISSN: 2070-1721 IBM Almaden
December 2017
File System Extended Attributes in NFSv4
NFSv4中的文件系统扩展属性
Abstract
摘要
This document describes an optional feature extending the NFSv4 protocol. This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects.
本文档描述了扩展NFSv4协议的可选功能。此功能允许使用NFSv4客户端查询和操作扩展属性（以下也称为XATTR）。XATTR由文件系统提供，用于将不透明元数据（不由文件系统解释）与文件和目录关联。这种支持存在于许多现代本地文件系统中。提供了新的文件属性，以允许客户端查询服务器对xattr的支持，该支持包括获取和设置文件系统对象上的xattr的新操作。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8276.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8276.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Uses of Extended Attributes . . . . . . . . . . . . . . . . . 5
3. Functional Gaps Due to Lack of NFSv4 Extended Attribute
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. File System Support for Extended Attributes . . . . . . . . . 6
5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Relationship with Named Attributes . . . . . . . . . . . . . 7
7. XDR Description . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Code Components Licensing Notice . . . . . . . . . . . . 9
7.2. XDR for Xattr Extension . . . . . . . . . . . . . . . . . 11
8. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 11
8.1. New Definitions . . . . . . . . . . . . . . . . . . . . . 11
8.2. New Attribute . . . . . . . . . . . . . . . . . . . . . . 12
8.2.1. xattr_support . . . . . . . . . . . . . . . . . . . . 12
8.3. New Error Definitions . . . . . . . . . . . . . . . . . . 12
8.3.1. NFS4ERR_NOXATTR (Error Code 10095) . . . . . . . . . 12
8.3.2. NFS4ERR_XATTR2BIG (Error Code 10096) . . . . . . . . 13
8.4. New Operations . . . . . . . . . . . . . . . . . . . . . 13
8.4.1. GETXATTR - Get an Extended Attribute of a File . . . 14
8.4.2. SETXATTR - Set an Extended Attribute of a File . . . 15
8.4.3. LISTXATTRS - List Extended Attributes of a File . . . 17
8.4.4. REMOVEXATTR - Remove an Extended Attribute of a File 18
8.4.5. Valid Errors . . . . . . . . . . . . . . . . . . . . 19
8.5. Modifications to Existing Operations . . . . . . . . . . 21
8.6. Numeric Values Assigned to Protocol Extensions . . . . . 22
8.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.8. Xattrs and File Locking . . . . . . . . . . . . . . . . . 25
8.9. pNFS Considerations . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Uses of Extended Attributes . . . . . . . . . . . . . . . . . 5
3. Functional Gaps Due to Lack of NFSv4 Extended Attribute
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. File System Support for Extended Attributes . . . . . . . . . 6
5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Relationship with Named Attributes . . . . . . . . . . . . . 7
7. XDR Description . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Code Components Licensing Notice . . . . . . . . . . . . 9
7.2. XDR for Xattr Extension . . . . . . . . . . . . . . . . . 11
8. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 11
8.1. New Definitions . . . . . . . . . . . . . . . . . . . . . 11
8.2. New Attribute . . . . . . . . . . . . . . . . . . . . . . 12
8.2.1. xattr_support . . . . . . . . . . . . . . . . . . . . 12
8.3. New Error Definitions . . . . . . . . . . . . . . . . . . 12
8.3.1. NFS4ERR_NOXATTR (Error Code 10095) . . . . . . . . . 12
8.3.2. NFS4ERR_XATTR2BIG (Error Code 10096) . . . . . . . . 13
8.4. New Operations . . . . . . . . . . . . . . . . . . . . . 13
8.4.1. GETXATTR - Get an Extended Attribute of a File . . . 14
8.4.2. SETXATTR - Set an Extended Attribute of a File . . . 15
8.4.3. LISTXATTRS - List Extended Attributes of a File . . . 17
8.4.4. REMOVEXATTR - Remove an Extended Attribute of a File 18
8.4.5. Valid Errors . . . . . . . . . . . . . . . . . . . . 19
8.5. Modifications to Existing Operations . . . . . . . . . . 21
8.6. Numeric Values Assigned to Protocol Extensions . . . . . 22
8.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.8. Xattrs and File Locking . . . . . . . . . . . . . . . . . 25
8.9. pNFS Considerations . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Extended attributes, also called xattrs, are a means to associate opaque metadata with file system objects, organized as 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, interrogate, and modify the key/value pairs.
扩展属性（也称为xattrs）是一种将不透明元数据与文件系统对象关联的方法，以键/值对的形式组织。当它们添加关联对象本身中不存在或不能存在的信息时，它们特别有用。用户空间应用程序可以任意创建、查询和修改键/值对。
Extended attributes are file system agnostic; applications use an interface not specific to any file system to manipulate them. Applications are not concerned about how the key/value pairs are stored internally within the underlying file system. All major operating systems provide facilities to access and modify extended attributes. Many user-space tools allow xattrs to be included together with regular attributes that need to be preserved when objects are updated, moved, or copied.
扩展属性与文件系统无关；应用程序使用不特定于任何文件系统的接口来操作它们。应用程序不关心键/值对如何在底层文件系统内部存储。所有主要的操作系统都提供了访问和修改扩展属性的工具。许多用户空间工具允许Xattr与更新、移动或复制对象时需要保留的常规属性一起包含。
Extended attributes have not previously been included within the NFSv4 specification. Some issues that need to be addressed in order to be included are that, as with named attributes, some aspects of the handling of xattrs are not precisely defined and xattrs are not formally documented by any standard such as POSIX [POSIX]. Nevertheless, it appears that xattrs are widely deployed, and their support in modern disk-based file systems is nearly universal.
扩展属性以前未包含在NFSv4规范中。与命名属性一样，需要解决的一些问题是，处理XATTR的某些方面没有精确定义，并且没有任何标准（如POSIX[POSIX]）正式记录XATTR。尽管如此，Xattr似乎已被广泛部署，并且在现代基于磁盘的文件系统中几乎得到了普遍支持。
There is no current specification of how xattrs could be mapped to any existing file attributes defined in the NFSv4 protocol [RFC5661] [RFC7530] [RFC7862]. As a result, most NFSv4 client implementations ignore application-specified xattrs. This state of affairs results in data loss if one copies, over the NFSv4 protocol, a file with xattrs from one file system to another that also supports xattrs.
目前没有关于如何将xattrs映射到NFSv4协议[RFC5661][RFC7530][RFC7862]中定义的任何现有文件属性的规范。因此，大多数NFSv4客户端实现都会忽略应用程序指定的XATTR。如果通过NFSv4协议将带有xattrs的文件从一个文件系统复制到另一个也支持xattrs的文件系统，则这种状态会导致数据丢失。
There is thus a need to provide a means by which such data loss can be avoided. This will involve exposing xattrs within the NFSv4 protocol, despite the lack of completely compatible file system implementations.
因此，需要提供一种避免此类数据丢失的方法。这将涉及在NFSv4协议中公开XATTR，尽管缺乏完全兼容的文件系统实现。
This document discusses (in Section 5) the reasons that NFSv4-named attributes, as currently standardized in [RFC5661], are unsuitable for representing xattrs. Instead, it describes a separate protocol mechanism to support xattrs. As a consequence, xattrs and named attributes will both be OPTIONAL features with servers free to support either, both, or neither.
本文件（第5节）讨论了[RFC5661]中当前标准化的NFSv4命名属性不适合表示XATTR的原因。相反，它描述了一个单独的协议机制来支持xattrs。因此，xattrs和命名属性都将是可选功能，服务器可以自由支持其中一个、两个或两个都不支持。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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.
应用程序可以在扩展属性中存储跟踪信息。示例包括存储标识创建文件的应用程序的元数据、用于指示数据完整性清理器上次验证文件的时间的标记，或用于保存文件内容的校验和/加密哈希以及签名日期的标记。Xattrs也可用于装饰或注释。例如，从web服务器下载的文件可以使用URL进行标记，如果将来必须确定其来源，这将非常方便。同样，保存电子邮件附件时，可以用电子邮件的邮件id标记，从而可以跟踪原始邮件。
Applications may need to behave differently when handling files of varying types. For example, file managers, such as GNOMEs, 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 the type can be interpreted 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 dispense with the custom database and store such metadata in extended attributes. This is easier to maintain, provides faster access, and is readily accessible by applications [Love].
处理不同类型的文件时，应用程序可能需要有不同的行为。例如，文件管理器（如GNOMEs）根据文件格式提供独特的图标、不同的单击行为和要执行的操作的特殊列表。这可以通过查看文件扩展名（Windows）来实现，也可以通过检查类型（Unix MIME类型）来解释类型。一些文件管理器会动态生成这些信息；其他人只生成一次信息，然后缓存它。那些缓存信息的人倾向于将其放在自定义数据库中。文件管理器必须使此数据库与文件保持同步，文件可以在文件管理器不知情的情况下更改。一种更好的方法是省去自定义数据库，并将此类元数据存储在扩展属性中。这更易于维护，提供更快的访问，并且易于被应用程序访问[Love]。
In addition to the prospect of data loss (discussed in Section 1) that arises from use of xattrs on local file systems, application use of xattrs poses further difficulties given the current lack of xattr support within NFSv4. As a result, certain applications may not be supported by NFSv4 or may be supported in an unsatisfactory way. Some examples are discussed below.
除了在本地文件系统上使用xattr可能导致数据丢失（在第1节中讨论）之外，由于NFSv4中目前缺乏xattr支持，应用程序使用xattr还带来了进一步的困难。因此，NFSv4可能不支持某些应用程序，或者可能以不令人满意的方式支持某些应用程序。下面讨论一些例子。
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 [Swift] transfers the responsibility of maintaining object durability and availability to the underlying file system. At the time of writing, this requires a native file system client to mount the volumes. Xattr support in NFSv4 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.
Swift，OpenStack分布式对象存储，使用xattrs将对象的元数据和所有数据一起存储在一个文件中。文件上的Swift[Swift]将维护对象持久性和可用性的责任转移到底层文件系统。在编写本文时，这需要本机文件系统客户端来装载卷。NFSv4中的Xattr支持将为存储和使用来自其他存储系统的数据提供可能性，并促进不同后端存储系统之间的数据迁移。
Baloo, the file indexing and search framework for Key Distribution Exchange (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 [KDE].
Baloo是密钥分发交换（KDE）的文件索引和搜索框架，为了简单起见，它已转向在文件系统xattrs中存储元数据，如标记、评级和注释，而不是自定义数据库。从KDE Plasma 5.1开始，由于缺乏xattr支持[KDE]，NFS不再受支持。
Extended attributes are supported by most modern file systems.
大多数现代文件系统都支持扩展属性。
Some of the file systems that support extended attributes in Linux are as follows: ext3, ext4, JFS, XFS, and Btrfs. 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 namespaces. Currently, four namespaces exist: user, trusted, security, and system [Linux]. Recommendations on how they should be used have been published [freedesktop].
Linux中支持扩展属性的一些文件系统如下：ext3、ext4、JFS、XFS和Btrfs。getfattr和setfattr实用程序可用于检索和设置Xattr。扩展属性的名称必须以类别名称和点作为前缀；因此，这些类别通常被限定为名称空间。目前，存在四个名称空间：用户、受信任、安全和系统[Linux]。关于如何使用它们的建议已经发布[freedesktop]。
FreeBSD supports extended attributes in two universal namespaces -- user and system -- although individual file systems are allowed to implement additional namespaces [FreeBSD].
FreeBSD支持两个通用名称空间（用户和系统）中的扩展属性，尽管允许单个文件系统实现额外的名称空间[FreeBSD]。
Some file systems have facilities that are capable of storing both extended attributes and named attributes. For discussion regarding the relationship between these features, see Section 5. Solaris 9 and later provide file "forks", logically represented as files within a hidden directory that is associated with the target file [fsattr]. In the New Technology File System (NTFS), extended attributes may be stored within "file streams" [NTFS].
一些文件系统具有能够存储扩展属性和命名属性的功能。有关这些特性之间关系的讨论，请参见第5节。Solaris 9和更高版本提供文件“forks”，逻辑上表示为与目标文件[fsattr]关联的隐藏目录中的文件。在新技术文件系统（NTFS）中，扩展属性可以存储在“文件流”[NTFS]中。
Xattrs can be retrieved and set through system calls or shell commands and are 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.
Xattr可以通过系统调用或shell命令进行检索和设置，并且通常由保留其他文件属性的用户空间工具支持。例如，“rsync”远程复制程序将通过剥离Linux特定的“user.”前缀，在Linux/ext4和OSX/hfs之间正确保留用户扩展属性。
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 [freedesktop].
操作系统可以定义多个“名称空间”，其中可以设置XATTR。名称空间不仅仅是组织类；操作系统可能强制执行不同的访问策略，并根据命名空间允许不同的功能。例如，Linux定义了“安全”、“系统”、“受信任”和“用户”名称空间，前三个名称空间特定于Linux[freedesktop]。
Implementations generally agree on the semantics of a "user" namespace, which 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.
实现通常同意“用户”名称空间的语义，该名称空间允许应用程序使用文件系统对象存储任意用户属性数据。通过普通文件系统属性控制对此命名空间的访问。因此，从用户名称空间获取和设置XATTR可以被认为是跨平台和供应商实现的互操作性。来自其他名称空间的属性通常是特定于平台的。
This document provides support for namespaces related to user-managed metadata only, thus avoiding the need to specify the semantics applicable to particular system-interpreted xattrs. The values of xattrs are considered application data just as the contents of named attributes, files, and symbolic links are. Servers have a responsibility to store whatever value the client specifies and to return it on demand. Xattr keys and values MUST NOT be interpreted by the NFS clients and servers, as such behavior would lead to non-interoperable implementations. If there were a need to specify one or more attributes that servers need to act upon, the appropriate semantics would be specified by adding a new attribute for the purpose as provided for by [RFC5661] and [RFC8178].
本文档仅支持与用户管理的元数据相关的名称空间，因此无需指定适用于特定系统解释的XATTR的语义。xattrs的值被视为应用程序数据，正如命名属性、文件和符号链接的内容被视为应用程序数据一样。服务器有责任存储客户机指定的任何值，并按需返回。NFS客户端和服务器不能解释Xattr键和值，因为这种行为会导致不可互操作的实现。如果需要指定服务器需要执行操作的一个或多个属性，则可以根据[RFC5661]和[RFC8178]的规定，通过添加新属性来指定适当的语义。
[RFC7530] defines named attributes as opaque byte streams that are associated with a directory or file and referred to by a string 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. Although this makes xattrs similar in concept and use to named attributes, there are important semantic differences.
[RFC7530]将命名属性定义为与目录或文件关联并由字符串名称引用的不透明字节流。命名属性旨在被客户端应用程序用作将特定于应用程序的数据与常规文件或目录关联的方法。虽然这使得XATTR在概念和使用上与命名属性相似，但也存在重要的语义差异。
File systems typically define operations to get and set individual xattrs 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 Access Control Lists (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
文件系统通常定义操作，以获取单个XATTR并将其设置为原子，尽管它们在一起可能是独立的。XATTR的大小限制通常在几个字节到几千字节之间；支持的最大大小不是通用定义的，通常受文件系统的限制。与访问控制列表（ACL）类似，客户机和服务器之间为get/set操作交换的xattr数据量可以被视为适合单个复合请求，由
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 are opened and closed just as files are. 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, have caching requirements similar to other file attributes.
单独的命名属性类似于文件，并且与文件一样打开和关闭。这些文件的数据缓存需要处理，就像遵循接近开放语义的普通文件的数据缓存一样。另一方面，XATTR具有与其他文件属性类似的缓存要求。
Named attributes and xattrs have different semantics and are treated by applications as belonging to disjoint namespaces. As a result, mapping from one to the other would be, at best, a compromise. Despite these differences, the underlying file system structure used to store named attributes is generally capable of storing xattrs. However, the converse is typically not the case because of the size limits applicable to xattrs.
命名属性和XATTR具有不同的语义，应用程序将其视为属于不相交的名称空间。因此，从一个映射到另一个至多是一种折衷。尽管存在这些差异，但用于存储命名属性的底层文件系统结构通常能够存储XATTR。然而，由于适用于XATTR的尺寸限制，情况通常并非如此。
While it might be possible to write guidance about how a client can use the named attribute mechanism to act like xattrs, such as by carving out some namespace and specifying locking primitives to enforce atomicity constraints on individual get/set operations, such an approach is sufficiently problematic; thus, it will not be attempted here. 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 a named attribute namespace specifically for implementation purposes.
虽然可以编写关于客户机如何使用命名属性机制来像xattrs一样工作的指导，例如通过划分一些名称空间和指定锁定原语来对单个get/set操作实施原子性约束，但这种方法存在足够多的问题；因此，这里不尝试这样做。如果客户端应用程序试图通过命名属性与直接支持xattrs的服务器一起使用xattrs，则会获得较低级别的服务，并且可能无法在服务器上运行的本地应用程序上进行协作，除非服务器文件系统定义了自己的互操作性约束。已经以本机方式实现xattrs和命名属性的文件系统需要额外的指导，例如专门为实现目的保留命名属性名称空间。
This document contains the External Data Representation (XDR) [RFC4506] description of the extended attributes. The XDR description is embedded in this document in a way that makes it simple for the reader to extract into a ready-to-compile form. The reader can feed this document into the following shell script to produce the machine-readable XDR description of extended attributes:
本文档包含扩展属性的外部数据表示（XDR）[RFC4506]描述。XDR描述以某种方式嵌入到本文档中，使读者能够轻松地将其提取到准备编译的表单中。读者可以将此文档输入以下shell脚本，以生成扩展属性的机器可读XDR描述：
<CODE BEGINS>
<代码开始>
#! /bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
#! /bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
<CODE ENDS>
<代码结束>
That is, if the above script is stored in a file called "extract.sh", and this document is in a file called "spec.txt", then the reader can do:
也就是说，如果上述脚本存储在一个名为“extract.sh”的文件中，而此文档存储在一个名为“spec.txt”的文件中，那么读者可以执行以下操作：
sh extract.sh < spec.txt > xattr_prot.x
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 initial section of the embedded XDR file header follows. Subsequent XDR descriptions, with the sentinel sequence, are embedded throughout the document.
下面是嵌入式XDR文件头的初始部分。后续的XDR描述（带有sentinel序列）嵌入到整个文档中。
Note that the XDR code contained in this document depends on types from the NFSv4.2 nfs4_prot.x file [RFC7863]. This includes both nfs types that end with a 4, such as nfs_cookie4, count4, etc., as well as more-generic types, such as opaque and bool.
请注意，本文档中包含的XDR代码取决于NFSv4.2 nfs4_prot.x文件[RFC7863]中的类型。这包括以4结尾的nfs类型，如nfs_cookie4、count4等，以及更通用的类型，如不透明和bool。
To produce a compilable XDR file, the following procedure is suggested:
要生成可编译的XDR文件，建议执行以下步骤：
o Extract the file nfs4_prot.x as described in [RFC7863].
o 按照[RFC7863]中的说明提取文件nfs4_prot.x。
o Extract xattr_prot.x from this document as described above.
o 如上所述，从本文档中提取xattr_prot.x。
o Apply any changes required for other extensions to be included together with the xattr extension.
o 应用与xattr扩展一起包含的其他扩展所需的任何更改。
o Perform modifications to nfs4_prot.x as described by comments within xattr_prot.x.
o 按照xattr_prot.x中的注释所述，对nfs4_prot.x进行修改。
o Extend the unions nfs_argop4 and nfs_resop4 to include cases for the new operations defined in this document.
o 扩展联合nfs_argop4和nfs_resop4，以包括本文档中定义的新操作的案例。
o Combine the XDR files for the base NFSv4.2 protocol and all needed extensions by either concatenating the relevant XDR files or using file inclusion.
o 通过连接相关XDR文件或使用文件包含，将基本NFSv4.2协议的XDR文件与所有需要的扩展名组合在一起。
Both the XDR description and the scripts used for extracting the XDR description are Code Components as described in "Legal Provisions Relating to IETF Documents", Section 4 of [LEGAL]. These Code Components are licensed according to the terms of that document.
XDR描述和用于提取XDR描述的脚本都是代码组件，如[法律]第4节“与IETF文件相关的法律规定”所述。这些代码组件根据该文档的条款获得许可。
<CODE BEGINS>
<代码开始>
/// /*
/// * Copyright (c) 2017 IETF Trust and the persons identified
/// * as authors of 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 met:
/// *
/// * o Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * o Redistributions in binary form must reproduce the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer in the documentation and/or other
/// * materials provided with the distribution.
/// *
/// * o Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to 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 RFC 8276.
/// * Please reproduce this note if possible.
/// */
/// /*
/// * Copyright (c) 2017 IETF Trust and the persons identified
/// * as authors of 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 met:
/// *
/// * o Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * o Redistributions in binary form must reproduce the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer in the documentation and/or other
/// * materials provided with the distribution.
/// *
/// * o Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to 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 RFC 8276.
/// * Please reproduce this note if possible.
/// */
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
/// /*
/// * xattr_prot.x
/// */
/// /*
/// * xattr_prot.x
/// */
/// /*
/// * The following includes statements that are for example only.
/// * The actual XDR definition files are generated separately
/// * and independently and are likely to have a different name.
/// * %#include <rpc_prot.x>
/// * %#include <nfsv42.x>
/// */
/// /*
/// * The following includes statements that are for example only.
/// * The actual XDR definition files are generated separately
/// * and independently and are likely to have a different name.
/// * %#include <rpc_prot.x>
/// * %#include <nfsv42.x>
/// */
<CODE ENDS>
<代码结束>
This section documents extensions to the NFSv4 protocol operations to allow xattrs to be queried and modified by clients. A new attribute is added to allow clients to determine if the file system being accessed provides support for xattrs. New operations are defined to allow xattr keys and values to be queried and set. In addition, the ACCESS operation is extended by adding new mask bits to provide access information relating to xattrs.
本节介绍了NFSv4协议操作的扩展，以允许客户端查询和修改XATTR。添加了一个新属性，允许客户端确定正在访问的文件系统是否支持xattrs。新的操作被定义为允许查询和设置xattr键和值。此外，通过添加新的掩码位来扩展访问操作，以提供与xattrs相关的访问信息。
These changes follow applicable guidelines for valid NFSv4 XDR protocol extension, as specified in [RFC8178], and obey the rules for extensions capable of being made without a change in minor version number.
这些更改遵循[RFC8178]中规定的有效NFSv4 XDR协议扩展的适用指南，并遵守能够在不更改次要版本号的情况下进行扩展的规则。
<CODE BEGINS>
<代码开始>
/// typedef component4 xattrkey4;
/// typedef opaque xattrvalue4<>;
/// typedef component4 xattrkey4;
/// typedef opaque xattrvalue4<>;
<CODE ENDS>
<代码结束>
Each xattr is a key/value pair. xattrkey4 is a string denoting the xattr key name and an attrvalue4, which is a variable-length string that identifies the value of the xattr. The handling of xattrkey4 with regard to internationalization-related issues is the same as that for NFSv4 file names and named attribute names, as described in [RFC7530]. Any regular file or directory may have a set of extended
每个xattr都是一个键/值对。xattrkey4是一个表示xattr密钥名称的字符串和一个attrvalue4，attrvalue4是一个长度可变的字符串，用于标识xattr的值。关于国际化相关问题，xattrkey4的处理与NFSv4文件名和命名属性名的处理相同，如[RFC7530]中所述。任何常规文件或目录都可能有一组扩展
attributes, each consisting of a key and associated value. The NFS client or server MUST NOT interpret the contents of xattrkey4 or xattrvalue4.
属性，每个属性由一个键和关联值组成。NFS客户端或服务器不得解释xattrkey4或xattrvalue4的内容。
The per-fs read-only attribute described below may be used to determine if xattrs are supported. Servers need not support this attribute, and some NFSv4.2 servers may be unaware of its existence. Before interrogating this attribute using GETATTR, a client should determine whether it is a supported attribute by interrogating the supported_attrs attribute.
下面描述的per fs只读属性可用于确定是否支持XATTR。服务器不需要支持此属性，一些NFSv4.2服务器可能不知道它的存在。在使用GETATTR查询此属性之前，客户端应该通过查询受支持的属性来确定它是否是受支持的属性。
xattr_support is set to True, if the object's file system supports extended attributes.
如果对象的文件系统支持扩展属性，则xattr_support设置为True。
Since xattr_support is not a REQUIRED attribute, the server need not support it. However, a client may reasonably assume that a server (or file system) that does not support the xattr_support attribute does not provide xattr support, and it acts on that basis.
因为xattr_支持不是必需的属性，所以服务器不需要支持它。但是，客户机可能会合理地假设不支持xattr_support属性的服务器（或文件系统）不提供xattr支持，并以此为基础进行操作。
Note that the protocol does not enforce any limits on the number of keys, the length of a key, the size of a value, or the total size of xattrs that are allowed for a file. The server file system MAY impose additional limits. In addition, a single xattr key or value exchanged between the client and server for get/set operations is limited by the channel's negotiated maximum size for requests and responses.
请注意，协议没有对文件允许的密钥数量、密钥长度、值大小或XATTR的总大小实施任何限制。服务器文件系统可能会施加额外的限制。此外，客户端和服务器之间为get/set操作交换的单个xattr密钥或值受到通道协商的请求和响应最大大小的限制。
<CODE BEGINS>
<代码开始>
/// /* Following lines are to be added to enum nfsstat4 */
/// /*
/// NFS4ERR_NOXATTR = 10095, /* xattr does not exist */
/// NFS4ERR_XATTR2BIG = 10096 /* xattr value is too big */
/// */
/// /* Following lines are to be added to enum nfsstat4 */
/// /*
/// NFS4ERR_NOXATTR = 10095, /* xattr does not exist */
/// NFS4ERR_XATTR2BIG = 10096 /* xattr value is too big */
/// */
<CODE ENDS>
<代码结束>
The specified xattr does not exist or the server is unable to retrieve it.
指定的xattr不存在或服务器无法检索它。
The size of the xattr value specified as part of a SETXATTR operation, or the collective size of all xattrs of the file resulting from the SETXATTR operation, is bigger than that supported by the underlying file system.
作为SETXATTR操作的一部分指定的xattr值的大小，或由SETXATTR操作产生的文件的所有xattr的总大小，大于基础文件系统支持的大小。
Applications need to perform the following operations on a given file's extended attributes [Love]:
应用程序需要对给定文件的扩展属性[Love]执行以下操作：
o Given a file, return a list of all of the file's assigned extended attribute keys.
o 给定一个文件，返回该文件所有已分配的扩展属性键的列表。
o Given a file and a key, return the corresponding value.
o 给定一个文件和一个键，返回相应的值。
o Given a file, a key, and a value, assign that value to the key.
o 给定一个文件、一个键和一个值，将该值指定给该键。
o Given a file and a key, remove that extended attribute from the file.
o 给定文件和密钥，从文件中删除该扩展属性。
In order to meet these requirements, this section introduces four new OPTIONAL operations: GETXATTR, SETXATTR, LISTXATTRS and REMOVEXATTR. These operations are to query, set, list, and remove xattrs, respectively. A server MUST support all four operations when they are directed to a file system that supports the xattr_support attribute and returns TRUE when it is interrogated. For file systems that either do not support the xattr_support attribute or return FALSE when the xattr_support attribute is interrogated, all of the above operations MUST NOT be supported. GETXATTR allows obtaining the value of an xattr key, SETXATTR allows creating or replacing an xattr key with a value, LISTXATTRS enumerates all the xattrs names, and REMOVEXATTR allows deleting a single xattr.
为了满足这些要求，本节介绍了四个新的可选操作：GETXATTR、SETXATTR、LISTXATTRS和REMOVEXATTR。这些操作分别用于查询、设置、列出和删除XATTR。当服务器指向支持xattr_support属性的文件系统时，服务器必须支持所有四个操作，并在查询时返回TRUE。对于不支持xattr_support属性或在查询xattr_support属性时返回FALSE的文件系统，必须不支持上述所有操作。GETXATTR允许获取xattr键的值，SETXATTR允许使用值创建或替换xattr键，LISTXATTRS枚举所有xattr名称，REMOVEXATTR允许删除单个xattr。
Note that some server implementations may not be aware of the existence of these operations, thereby a client cannot always expect that issuing one of them will either succeed or return NFS4ERR_NOTSUPP. In some cases, NFS4ERR_OP_ILLEGAL may be returned or the request may encounter an XDR decode error on the server. As a result, clients should only issue these operations after determining that support is present.
请注意，一些服务器实现可能不知道这些操作的存在，因此客户端不能总是期望发出其中一个操作会成功或返回NFS4ERR_NOTSUPP。在某些情况下，可能会返回NFS4ERR_OP_非法，或者请求可能在服务器上遇到XDR解码错误。因此，客户机只应在确定支持存在后才发出这些操作。
<CODE BEGINS>
<代码开始>
/// struct GETXATTR4args {
/// /* CURRENT_FH: file */
/// xattrkey4 gxa_name;
/// };
/// struct GETXATTR4args {
/// /* CURRENT_FH: file */
/// xattrkey4 gxa_name;
/// };
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
/// union GETXATTR4res switch (nfsstat4 gxr_status) {
/// case NFS4_OK:
/// xattrvalue4 gxr_value;
/// default:
/// void;
/// };
/// union GETXATTR4res switch (nfsstat4 gxr_status) {
/// case NFS4_OK:
/// xattrvalue4 gxr_value;
/// default:
/// void;
/// };
<CODE ENDS>
<代码结束>
The GETXATTR operation will obtain the value for the given extended attribute key for the file system object specified by the current filehandle.
GETXATTR操作将获取当前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 the NFS4ERR_NOTSUPP error or another error indicating the request was not understood. The server also MUST return NFS4ERR_NOXATTR if it supports xattrs on the target but cannot obtain the requested data. If the xattr value contained in the server response is such as to cause the channel's negotiated maximum response size to be exceeded, then the server MUST return NFS4ERR_REP_TOO_BIG in gxr_status.
如果目标文件系统的服务器支持xattr，则服务器将获取客户端请求的密钥的xattr值。如果服务器在目标文件系统上不支持xattrs，则它不能返回值，并且必须返回NFS4ERR_NOTSUPP错误或另一个指示请求未被理解的错误。如果服务器在目标上支持xattrs，但无法获取请求的数据，则服务器还必须返回NFS4ERR_NOXATTR。如果服务器响应中包含的xattr值导致超过通道协商的最大响应大小，则服务器必须在gxr_状态下返回NFS4ERR_REP_TOO_BIG。
Clients that have cached an xattr may avoid the need to do a GETXATTR by 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
缓存了xattr的客户端可以通过确定change属性是否与提取xattr时的属性相同来避免执行GETXATTR。如果客户机没有为
file in question, it can obtain the change attribute with a GETATTR request and compare that change attribute's value to the change attribute value fetched when the xattr value was obtained. This handling is similar to how a client would revalidate other file attributes such as ACLs.
文件，它可以通过GETATTR请求获取change属性，并将该change属性的值与获取xattr值时获取的change属性值进行比较。此处理类似于客户端如何重新验证其他文件属性（如ACL）。
When responding to such a GETATTR, the server 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 [RFC5661] for details.
当响应这样一个GETATTR时，如果另一个客户机为所讨论的文件持有OPEN_DELEGATE_WRITE委托，服务器将使用CB_GETATTR回调从持有委托的客户机获取这些属性的实际当前值，或者撤销委托。详见[RFC5661]第18.7.4节。
<CODE BEGINS>
<代码开始>
/// enum setxattr_option4 {
/// SETXATTR4_EITHER = 0,
/// SETXATTR4_CREATE = 1,
/// SETXATTR4_REPLACE = 2
/// };
/// enum setxattr_option4 {
/// SETXATTR4_EITHER = 0,
/// SETXATTR4_CREATE = 1,
/// SETXATTR4_REPLACE = 2
/// };
/// struct SETXATTR4args {
/// /* CURRENT_FH: file */
/// setxattr_option4 sxa_option;
/// xattrkey4 sxa_key;
/// xattrvalue4 sxa_value;
/// };
/// struct SETXATTR4args {
/// /* CURRENT_FH: file */
/// setxattr_option4 sxa_option;
/// xattrkey4 sxa_key;
/// xattrvalue4 sxa_value;
/// };
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
/// union SETXATTR4res switch (nfsstat4 sxr_status) {
/// case NFS4_OK:
/// change_info4 sxr_info;
/// default:
/// void;
/// };
/// union SETXATTR4res switch (nfsstat4 sxr_status) {
/// case NFS4_OK:
/// change_info4 sxr_info;
/// default:
/// void;
/// };
<CODE ENDS>
<代码结束>
The SETXATTR operation changes one extended attribute of a file system object. The change desired is specified by sxa_option. 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 NFS4ERR_EXIST if the attribute key already exists. SETXATTR4_REPLACE is also used to set an xattr, but the server MUST return NFS4ERR_NOXATTR if the attribute key does not exist. By default (SETXATTR4_EITHER), the extended attribute will be created if need be, or its value will be replaced if the attribute exists.
SETXATTR操作更改文件系统对象的一个扩展属性。所需的更改由sxa_选项指定。SETXATTR4_CREATE用于将给定值与当前文件句柄指定的文件系统对象的给定扩展属性键相关联。如果属性键已经存在，服务器必须返回NFS4ERR_EXIST。SETXATTR4_REPLACE也用于设置xattr，但如果属性键不存在，服务器必须返回NFS4ERR_NOXATTR。默认情况下（SETXATTR4_），如果需要，将创建扩展属性，或者如果属性存在，将替换其值。
If the xattr key and value contained in the client request are such that the request would exceed the channel's negotiated maximum request size, then the server MUST return NFS4ERR_REQ_TOO_BIG in sxr_status. If the server file system imposes additional limits on the size of the key name or value, it MAY return NFS4ERR_XATTR2BIG.
如果客户端请求中包含的xattr密钥和值使得请求将超过通道协商的最大请求大小，则服务器必须在sxr_状态下返回NFS4ERR_REQ_TOO_BIG。如果服务器文件系统对密钥名称或值的大小施加额外限制，则可能返回NFS4ERR_XATTR2BIG。
A successful SETXATTR MUST change the file time_metadata and change attributes if the xattr is created or the value assigned to xattr changes. However, it is not necessary to change these attributes if there has been no actual change in the xattr value. Avoiding attribute change in such situations is desirable as it avoids unnecessary cache invalidation.
如果创建了xattr或分配给xattr的值发生更改，则成功的SETXATTR必须更改文件时间_元数据并更改属性。但是，如果xattr值没有实际更改，则无需更改这些属性。在这种情况下避免属性更改是可取的，因为这样可以避免不必要的缓存失效。
On success, the server returns the change_info4 information in sxr_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 still valid after the operation. See Section 8.7 for a discussion on xattr caching.
成功后，服务器将在sxr\u info中返回change\u info4信息。使用change_info4数据类型的原子字段，服务器将指示更改前和更改后属性是否是针对SETXATTR操作以原子方式获得的。这允许客户端确定其缓存的XATTR在操作后是否仍然有效。有关xattr缓存的讨论，请参见第8.7节。
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.
如果要更改其xattr的对象的文件委派由执行SETXATTR的客户机以外的客户机持有，则必须调用委派，并且在返回或撤销每个此类委派之前，操作无法继续实际更改xattr。在调用委托的所有情况下，服务器都可能返回一个或多个NFS4ERR_延迟错误，而委托仍然未完成，但如果快速返回委托，则可能不会返回。
<CODE BEGINS>
<代码开始>
/// struct LISTXATTRS4args {
/// /* CURRENT_FH: file */
/// nfs_cookie4 lxa_cookie;
/// count4 lxa_maxcount;
/// };
/// struct LISTXATTRS4args {
/// /* CURRENT_FH: file */
/// nfs_cookie4 lxa_cookie;
/// count4 lxa_maxcount;
/// };
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
/// struct LISTXATTRS4resok {
/// nfs_cookie4 lxr_cookie;
/// xattrkey4 lxr_names<>;
/// bool lxr_eof;
/// };
/// struct LISTXATTRS4resok {
/// nfs_cookie4 lxr_cookie;
/// xattrkey4 lxr_names<>;
/// bool lxr_eof;
/// };
/// union LISTXATTRS4res switch (nfsstat4 lxr_status) {
/// case NFS4_OK:
/// LISTXATTRS4resok lxr_value;
/// default:
/// void;
/// };
/// union LISTXATTRS4res switch (nfsstat4 lxr_status) {
/// case NFS4_OK:
/// LISTXATTRS4resok lxr_value;
/// default:
/// void;
/// };
<CODE ENDS>
<代码结束>
The LISTXATTRS 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 LISTXATTRS.
LISTXATTRS操作从当前filehandle指定的文件系统对象中检索数量可变的扩展属性键，以及允许客户端在后续LISTXATTRS中请求其他属性键的信息。
The arguments contain a cookie value that represents where the LISTXATTRS should start within the list of xattrs. A value of 0 (zero) for lxa_cookie is used to start reading at the beginning of the list. For subsequent LISTXATTRS requests, the client specifies a cookie value that is provided by the server on a previous LISTXATTRS request.
这些参数包含一个cookie值，该值表示ListXattr在Xattr列表中的起始位置。lxa_cookie的值0（零）用于从列表开始读取。对于后续的LISTXATTRS请求，客户端指定服务器在先前的LISTXATTRS请求中提供的cookie值。
The lxa_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 LISTXATTRS4resok 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.
参数的lxa_maxcount值是结果的最大字节数。此最大大小表示LISTXATTRS4resok结构中返回的所有数据，并包括XDR开销。服务器可能返回较少的数据。如果服务器无法在maxcount限制内返回单个xattr名称，则会将错误NFS4ERR_Toosall返回给客户端。
On successful return, the server's response will provide a list of extended attribute keys. The "lxr_eof" flag has a value of TRUE if there are no more keys for the object.
成功返回后，服务器的响应将提供扩展属性键的列表。如果对象没有更多的键，“lxr_eof”标志的值为TRUE。
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 LISTXATTRS 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.
cookie值仅对服务器有意义，并用作xattr键的“书签”。如前所述，客户端将此cookie用于后续的LISTXATTRS操作，以便它可以继续列出密钥。cookie在概念上类似于READDIR cookie或读取偏移量，但客户端不应将其解释为这样。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
The handling of a cookie is similar to that of the READDIR operation. It should be a rare occurrence that a server is unable to continue properly listing xattrs with the provided cookie. 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.
cookie的处理类似于READDIR操作。服务器无法继续使用提供的cookie正确列出Xattr，这种情况应该很少发生。服务器应尽一切努力避免这种情况，因为客户端的应用程序可能无法正确处理此类故障。
<CODE BEGINS>
<代码开始>
/// struct REMOVEXATTR4args {
/// /* CURRENT_FH: file */
/// xattrkey4 rxa_name;
/// };
/// struct REMOVEXATTR4args {
/// /* CURRENT_FH: file */
/// xattrkey4 rxa_name;
/// };
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
/// union REMOVEXATTR4res switch (nfsstat4 rxr_status) {
/// case NFS4_OK:
/// change_info4 rxr_info;
/// default:
/// void;
/// };
/// union REMOVEXATTR4res switch (nfsstat4 rxr_status) {
/// case NFS4_OK:
/// change_info4 rxr_info;
/// default:
/// void;
/// };
<CODE ENDS>
<代码结束>
The REMOVEXATTR operation deletes one extended attribute of a file system object specified by rxa_name. The server MUST return NFS4ERR_NOXATTR if the attribute key does not exist.
REMOVEXATTR操作删除rxa_name指定的文件系统对象的一个扩展属性。如果属性键不存在，服务器必须返回NFS4ERR_NOXATTR。
A successful REMOVEXATTR MUST change the file time_metadata and change attributes.
成功的REMOVEXATTR必须更改文件时间元数据并更改属性。
Similar to SETXATTR, the server communicates the value of the change attribute immediately prior to, and immediately following, a successful REMOVEXATTR operation in rxr_info. This allows the client to determine if its cached xattrs are still valid after the operation. See Section 8.7 for a discussion on xattr caching.
与SETXATTR类似，服务器在rxr_info中成功执行REMOVEXATTR操作之前和之后立即传递更改属性的值。这允许客户端确定其缓存的XATTR在操作后是否仍然有效。有关xattr缓存的讨论，请参见第8.7节。
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.
如果要删除其xattr的对象的文件委派由执行REMOVEXATTR的客户机以外的客户机持有，则必须重新调用委派，并且在返回或撤销每个此类委派之前，操作无法继续删除xattr。在调用委托的所有情况下，服务器都可能返回一个或多个NFS4ERR_延迟错误，而委托仍然未完成，但如果快速返回委托，则可能不会返回。
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 13.2 of [RFC7530] and Section 11.2 of [RFC7862].
本节包含一个表，该表给出了每个新协议操作的有效错误返回。错误代码NFS4_OK（表示无错误）未列出，但应理解为可由所有新操作返回。[RFC7530]第13.2节和[RFC7862]第11.2节定义了所有其他操作的误差值。
+-------------+-----------------------------------------------------+
| Operation | Errors |
+-------------+-----------------------------------------------------+
| GETXATTR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_NOXATTR, 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_BADCHAR, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOXATTR, 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_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE, |
| | NFS4ERR_XATTR2BIG |
| LISTXATTRS | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_NOXATTR, |
| | 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 |
| REMOVEXATTR | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOXATTR,, 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_WRONG_TYPE |
+-------------+-----------------------------------------------------+
+-------------+-----------------------------------------------------+
| Operation | Errors |
+-------------+-----------------------------------------------------+
| GETXATTR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_NOXATTR, 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_BADCHAR, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOXATTR, 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_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE, |
| | NFS4ERR_XATTR2BIG |
| LISTXATTRS | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_NOXATTR, |
| | 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 |
| REMOVEXATTR | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, NFS4ERR_BADXDR, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOXATTR,, 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_WRONG_TYPE |
+-------------+-----------------------------------------------------+
Valid Error Returns for Each New Protocol Operation
每个新协议操作返回有效的错误
In order to provide fine-grained access control to query or modify extended attributes, new access rights are defined that can be checked to determine if the client is permitted to perform the xattr operation.
为了提供查询或修改扩展属性的细粒度访问控制，定义了新的访问权限，可以检查这些权限以确定是否允许客户端执行xattr操作。
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.
请注意，一般情况下，如[RFC5661]第18.1.4节所述，客户机无法仅使用当前文件属性可靠地执行访问检查，必须验证服务器的访问权限。
This section extends the semantics of the ACCESS operation documented in Section 18.1 of [RFC5661]. Three new access permissions can be requested:
本节扩展了[RFC5661]第18.1节中记录的访问操作的语义。可以请求三个新的访问权限：
ACCESS4_XAREAD Query a file or directory for its xattr value given a key.
ACCESS4\u XAREAD在给定密钥的情况下查询文件或目录的xattr值。
ACCESS4_XAWRITE Modify xattr keys and/or values of a file or directory.
access4xawrite修改文件或目录的xattr键和/或值。
ACCESS4_XALIST Query a file or directory to list its xattr keys.
ACCESS4\u XALIST查询文件或目录以列出其xattr键。
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.
与现有的访问权限一样，访问结果本质上是建议性的，并不意味着将来会允许或拒绝此类访问。
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, the client should set ACCESS4_XAREAD in the request's access field.
o 如果客户端发送访问权限以确定用户是否可以使用GETXATTR读取文件的xattr，则客户端应在请求的访问字段中设置access4xaread。
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 如果客户端发送访问权限以确定用户是否可以使用SETXATTR或removeexattr修改文件的xattr，则客户端应在请求的访问字段中设置access4xawrite。
o If the client is sending ACCESS in order to determine if the user can list the xattr keys of the file with LISTXATTRS, the client should set ACCESS4_XALIST in the request's access field.
o 如果客户端发送访问权限以确定用户是否可以使用LISTXATTRS列出文件的xattr密钥，则客户端应在请求的访问字段中设置ACCESS4_XALIST。
This section lists the numeric values that are 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] and the current minor version [RFC7862]. Development of interoperable prototypes is possible using these values.
本节列出了为实现xattr功能而分配的新属性和操作的数值。为避免不一致的分配，已根据最新协议版本[RFC5661]和当前次要版本[RFC7862]检查这些分配。使用这些值可以开发可互操作的原型。
<CODE BEGINS>
<代码开始>
/// /*
/// * ACCESS - Check Access Rights
/// */
/// const ACCESS4_XAREAD = 0x00000040;
/// const ACCESS4_XAWRITE = 0x00000080;
/// const ACCESS4_XALIST = 0x00000100;
/// /*
/// * ACCESS - Check Access Rights
/// */
/// const ACCESS4_XAREAD = 0x00000040;
/// const ACCESS4_XAWRITE = 0x00000080;
/// const ACCESS4_XALIST = 0x00000100;
/// /*
/// * New NFSv4 attribute
/// */
/// typedef bool fattr4_xattr_support;
/// /*
/// * New NFSv4 attribute
/// */
/// typedef bool fattr4_xattr_support;
/// /*
/// * New RECOMMENDED Attribute
/// */
/// const FATTR4_XATTR_SUPPORT = 82;
/// /*
/// * New RECOMMENDED Attribute
/// */
/// const FATTR4_XATTR_SUPPORT = 82;
/// /*
/// * New NFSv4 operations
/// */
/// /* Following lines are to be added to enum nfs_opnum4 */
/// /*
/// OP_GETXATTR = 72,
/// OP_SETXATTR = 73,
/// OP_LISTXATTRS = 74,
/// OP_REMOVEXATTR = 75,
/// */
/// /*
/// * New NFSv4 operations
/// */
/// /* Following lines are to be added to enum nfs_opnum4 */
/// /*
/// OP_GETXATTR = 72,
/// OP_SETXATTR = 73,
/// OP_LISTXATTRS = 74,
/// OP_REMOVEXATTR = 75,
/// */
/// /*
/// * New cases for Operation arrays
/// */
/// /* Following lines are to be added to nfs_argop4 */
/// /*
/// case OP_GETXATTR: GETXATTR4args opgetxattr;
/// case OP_SETXATTR: SETXATTR4args opsetxattr;
/// case OP_LISTXATTRS: LISTXATTRS4args oplistxattrs;
/// case OP_REMOVEXATTR: REMOVEXATTR4args opremovexattr;
/// /*
/// * New cases for Operation arrays
/// */
/// /* Following lines are to be added to nfs_argop4 */
/// /*
/// case OP_GETXATTR: GETXATTR4args opgetxattr;
/// case OP_SETXATTR: SETXATTR4args opsetxattr;
/// case OP_LISTXATTRS: LISTXATTRS4args oplistxattrs;
/// case OP_REMOVEXATTR: REMOVEXATTR4args opremovexattr;
/// */
/// */
/// /* Following lines are to be added to nfs_resop4 */
/// /*
/// case OP_GETXATTR: GETXATTR4res opgetxattr;
/// case OP_SETXATTR: SETXATTR4res opsetxattr;
/// case OP_LISTXATTRS: LISTXATTRS4res oplistxattrs;
/// case OP_REMOVEXATTR: REMOVEXATTR4res opremovexattr;
/// */
/// /* Following lines are to be added to nfs_resop4 */
/// /*
/// case OP_GETXATTR: GETXATTR4res opgetxattr;
/// case OP_SETXATTR: SETXATTR4res opsetxattr;
/// case OP_LISTXATTRS: LISTXATTRS4res oplistxattrs;
/// case OP_REMOVEXATTR: REMOVEXATTR4res opremovexattr;
/// */
<CODE ENDS>
<代码结束>
The caching behavior for extended attributes is similar to other file attributes such as ACLs and is affected by whether or not OPEN delegation has been granted to a client.
扩展属性的缓存行为与其他文件属性（如ACL）类似，并受是否已向客户端授予开放委派的影响。
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 be based 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.
从服务器获取或发送到服务器的Xattr可以被缓存，客户端可以使用它们来避免后续的GETXATTR请求，前提是客户端可以确保缓存的值随后没有被另一个客户端修改。这样的保证可以基于持有相关文件的委托的客户端，或者基于询问更改属性以确保任何缓存值仍然有效的客户端。这种缓存可以是只读的，也可以是直写的。
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, it can dispense with actual interrogation of the change attribute.
本地缓存的结果是，客户端上维护的单个XATTR可能不是最新的。在服务器上按一个顺序所做的更改可能在一个客户端上以不同的顺序显示，在另一个客户端上以第三个顺序显示。为了限制由于获取单个XATTR和其他文件属性的单独操作而可能出现的问题，客户机应将XATTR与缓存方面的其他文件属性一样对待，详见[RFC7530]第10.6节。客户端可以通过获取更改属性并假设如果更改属性具有与缓存属性时相同的值，则xattr没有更改，从而验证文件的xattr缓存版本。如果客户机持有一个确保变更属性不能被另一个客户机修改的委托，那么它可以免除对变更属性的实际询问。
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.
当客户端更改文件的xattrs时，它需要确定其他客户端是否对该文件进行了更改。它通过使用为该操作返回的关联change_info4值中在更改操作（SETXATTR或REMOVEXATTR）之前和之后报告的更改属性来实现这一点。服务器能够与客户端通信，以确定是否以原子方式提供了与变更操作相关的变更信息4数据。如果更改值是以原子方式提供的，则客户机有一个基础，可以在适当注意的情况下确定其他客户机是否正在修改有问题的文件。
An effective way to enable the client to make this determination simply is for it 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.
使客户机能够简单地进行此确定的一种有效方法是将对特定文件所做的所有xattr更改序列化。完成此操作后，服务器以原子方式提供更改属性的before和after值，客户端只需将一个操作中更改属性的after值与修改文件的后续更改操作中的before值进行比较。当这些值相等时，客户机可以确保没有其他客户机正在修改所讨论的文件。
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缓存将从客户端中清除。如果比较表明没有修改，则可以在客户端上更新xattr缓存以反映文件操作，并且可以延长相关超时。需要保存操作后更改值，作为将来更改比较的基础。
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.
Xattr缓存要求客户端通过在缓存Xattr时检查文件的更改属性来重新验证Xattr缓存数据。这要求服务器在修改xattrs时更新change属性。为了让客户端正确地使用change_info4信息，服务器必须以原子方式报告操作前和操作后的change属性值。当服务器无法就xattr更新操作自动报告before和after值时，服务器必须在change_info4返回值中指出这一事实。当信息未按原子方式报告时，客户机不应假定其他客户机未更改XATTR。
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.
该协议不支持xattrs的写回缓存。因此，对xattrs的所有修改都应该通过向服务器发出请求来完成。服务器应同步执行此类更新。
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 access permissions.
Xattr操作在很大程度上独立于与文件锁定状态相关的操作。例如，可以在没有相应的打开操作的情况下查询和修改XATTR。服务器不需要检查与xattr访问或修改操作冲突的锁。例如，使用OPEN4_SHARE_DENY_READ或OPEN4_SHARE_DENY_指定的另一个OPEN都不会阻止对xattrs的访问或修改。请注意，服务器仍必须验证是否允许客户端根据访问权限执行xattr操作。
However, the presence of delegations may dictate how xattr operations interact with the state-related logic. Xattrs cannot be modified when a delegation for the corresponding file is held by 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.
然而，代表团的存在可能决定xattr操作如何与状态相关逻辑交互。当相应文件的委派由另一个客户端持有时，无法修改Xattrs。另一方面，尽管另一个客户机持有写委派，但可以询问XATTR，因为更新是通过写入服务器进行的。
All xattr operations are sent to the metadata server, which is responsible for fetching data from and effecting necessary changes to persistent storage.
所有xattr操作都被发送到元数据服务器，该服务器负责从持久存储中获取数据并对其进行必要的更改。
Since xattrs are application data, security issues are exactly the same as those relating to the storing of file data and named attributes. Clients MUST NOT accord any system-interpreted semantics to xattrs, since their use is restricted to user-managed metadata only as explained in Section 5. Extended attributes are 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 protocol [RFC7530].
由于XATTR是应用程序数据，因此安全问题与存储文件数据和命名属性的问题完全相同。客户端不得将任何系统解释的语义赋予XATTR，因为它们的使用仅限于用户管理的元数据，如第5节所述。扩展属性是各种类型的应用程序数据，在每种情况下，引用方式略有不同这一事实不应被视为与安全相关。因此，添加到NFS协议以支持扩展属性不会改变NFSv4协议[RFC7530]的安全注意事项。
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 allowed to define and use attributes as needed. Unlike named attributes, there is no namespace identifier associated with xattrs that may require registration.
向NFSv4协议添加xattr支持不需要IANA采取任何行动。本文档将xattr名称限制为用户名称空间，允许应用程序开发人员根据需要定义和使用属性。与命名属性不同，Xattr没有需要注册的名称空间标识符。
[LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", Version 5.0, March 2015, <http://trustee.ietf.org/docs/ IETF-Trust-License-Policy.pdf>.
[法律]IETF信托，“与IETF文件相关的法律规定”，版本5.0，2015年3月<http://trustee.ietf.org/docs/ IETF信任许可证策略.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://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, <https://www.rfc-editor.org/info/rfc4506>.
[RFC4506]艾斯勒，M.，编辑，“XDR：外部数据表示标准”，STD 67，RFC 4506，DOI 10.17487/RFC4506，2006年5月<https://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, <https://www.rfc-editor.org/info/rfc5661>.
[RFC5661]Shepler，S.，Ed.，Eisler，M.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1协议”，RFC 5661，DOI 10.17487/RFC5661，2010年1月<https://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <https://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.和D.Noveck，Ed.，“网络文件系统（NFS）第4版协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<https://www.rfc-editor.org/info/rfc7530>.
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[RFC7862]Haynes，T.，“网络文件系统（NFS）版本4次要版本2协议”，RFC 7862，DOI 10.17487/RFC7862，2016年11月<https://www.rfc-editor.org/info/rfc7862>.
[RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description", RFC 7863, DOI 10.17487/RFC7863, November 2016, <https://www.rfc-editor.org/info/rfc7863>.
[RFC7863]Haynes，T.，“网络文件系统（NFS）版本4次要版本2外部数据表示标准（XDR）说明”，RFC 7863，DOI 10.17487/RFC7863，2016年11月<https://www.rfc-editor.org/info/rfc7863>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, <https://www.rfc-editor.org/info/rfc8178>.
[RFC8178]Noveck，D.，“NFSv4扩展和次要版本的规则”，RFC 8178，DOI 10.17487/RFC8178，2017年7月<https://www.rfc-editor.org/info/rfc8178>.
[FreeBSD] FreeBSD, "FreeBSD Manual Pages - extattr", FreeBSD System Calls Manual, January 2008, <http://www.freebsd.org/ cgi/man.cgi?query=extattr&sektion=9>.
[FreeBSD]FreeBSD，“FreeBSD手册页-extattr”，FreeBSD系统调用手册，2008年1月<http://www.freebsd.org/ cgi/man.cgi？query=extattr&sektion=9>。
[freedesktop] freedesktop, "Guidelines for extended attributes", May 2013, <http://www.freedesktop.org/wiki/ CommonExtendedAttributes>.
[freedesktop]freedesktop，“扩展属性指南”，2013年5月<http://www.freedesktop.org/wiki/ CommonExtendedAttributes>。
[fsattr] Oracle, "fsattr - extended file attributes", Man Pages Section 5: Standards, Environments, and Macros, <http://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02>.
[fsattr]Oracle，“fsattr-扩展文件属性”，手册页第5节：标准、环境和宏<http://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02>.
[KDE] Handa, V., "Extended Attributes Updates", August 2014, <http://vhanda.in/blog/2014/08/ extended-attributes-updates/>.
[KDE]Handa，V.，“扩展属性更新”，2014年8月<http://vhanda.in/blog/2014/08/ 扩展属性更新/>。
[Linux] The Linux man-pages project, "Linux Programmer's Manual: xattr(7)", Linux man pages: Section 7, September 2017, <http://man7.org/linux/man-pages/man7/xattr.7.html>.
[Linux]Linux手册项目，“Linux程序员手册：xattr（7）”，Linux手册：第7节，2017年9月<http://man7.org/linux/man-pages/man7/xattr.7.html>.
[Love] Love, R., "Linux System Programming: Talking Directly to the Kernel and C Library", O'Reilly Media, Inc., February 2009.
[Love]Love，R.，“Linux系统编程：直接与内核和C库对话”，O'Reilly Media，Inc.，2009年2月。
[NTFS] Microsoft, "File Streams", <http://msdn.microsoft.com/en-us/library/windows/desktop/aa364404(v=vs.85).aspx>.
[NTFS]Microsoft，“文件流”<http://msdn.microsoft.com/en-us/library/windows/desktop/aa364404（v=vs.85）.aspx>。
[POSIX] The Open Group, "System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2016 Edition (HTML Version), ISBN 1937218812, September 2016, <http://pubs.opengroup.org/onlinepubs/9699919799/>.
[POSIX]开放组，“开放组基本规范第7期的系统接口”，IEEE Std 1003.11916版（HTML版），ISBN 19372188121016年9月<http://pubs.opengroup.org/onlinepubs/9699919799/>.
[Swift] The OpenStack Foundation Wiki, "Swift-on-File", July 2015, <https://wiki.openstack.org/wiki/Swiftonfile>.
[ SWIFT ] OpenStack基金会Wiki，“Swift on file”，2015年7月，<https://wiki.openstack.org/wiki/Swiftonfile>.
Acknowledgments
致谢
This document has attempted to capture the discussion on adding xattrs to the NFSv4 protocol from many participants on the IETF NFSv4 mailing list. Those who provided valuable input and comments on draft versions of this document include: Tom Haynes, Christoph Hellwig, Nico Williams, Dave Noveck, Benny Halevy, and Andreas Gruenbacher.
本文档试图从IETF NFSv4邮件列表上的许多参与者那里捕获关于将XATTR添加到NFSv4协议的讨论。对本文件草稿提供宝贵意见和评论的人包括：汤姆·海恩斯、克里斯托夫·赫尔维格、尼科·威廉姆斯、戴夫·诺维克、本尼·哈雷维和安德烈亚斯·格伦巴赫。
Authors' Addresses
作者地址
Manoj Naik Nutanix 1740 Technology Drive, Suite 150 San Jose, CA 95110 United States of America
美国加利福尼亚州圣何塞市Manoj Naik Nutanix科技大道1740号150室，邮编95110
Email: manoj.naik@nutanix.com
Email: manoj.naik@nutanix.com
Marc Eshel IBM Almaden 650 Harry Road San Jose, CA 95120 United States of America
Marc Eshel IBM Almaden 650加利福尼亚州圣何塞哈里路95120美利坚合众国
Phone: +1 408-927-1894
Email: eshel@us.ibm.com
Phone: +1 408-927-1894
Email: eshel@us.ibm.com