Internet Engineering Task Force (IETF) T. Haynes
Request for Comments: 7862 Primary Data
Category: Standards Track November 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Haynes
Request for Comments: 7862 Primary Data
Category: Standards Track November 2016
ISSN: 2070-1721
Network File System (NFS) Version 4 Minor Version 2 Protocol
网络文件系统（NFS）版本4次要版本2协议
Abstract
摘要
This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O) Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.
本文档介绍NFS版本4次要版本2；它描述了从NFS版本4次要版本1生成的协议扩展。NFS版本4次要版本2中引入的主要扩展包括以下内容：服务器端拷贝、应用程序输入/输出（I/O）建议、空间保留、稀疏文件、应用程序数据块和带标签的NFS。
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 http://www.rfc-editor.org/info/rfc7862.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7862.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Requirements Language ......................................4
1.2. Scope of This Document .....................................5
1.3. NFSv4.2 Goals ..............................................5
1.4. Overview of NFSv4.2 Features ...............................6
1.4.1. Server-Side Clone and Copy ..........................6
1.4.2. Application Input/Output (I/O) Advise ...............6
1.4.3. Sparse Files ........................................6
1.4.4. Space Reservation ...................................7
1.4.5. Application Data Block (ADB) Support ................7
1.4.6. Labeled NFS .........................................7
1.4.7. Layout Enhancements .................................7
1.5. Enhancements to Minor Versioning Model .....................7
2. Minor Versioning ................................................8
3. pNFS Considerations for New Operations ..........................9
3.1. Atomicity for ALLOCATE and DEALLOCATE ......................9
3.2. Sharing of Stateids with NFSv4.1 ...........................9
3.3. NFSv4.2 as a Storage Protocol in pNFS: The File
Layout Type ................................................9
3.3.1. Operations Sent to NFSv4.2 Data Servers .............9
4. Server-Side Copy ...............................................10
4.1. Protocol Overview .........................................10
4.1.1. COPY Operations ....................................11
4.1.2. Requirements for Operations ........................11
4.2. Requirements for Inter-Server Copy ........................13
4.3. Implementation Considerations .............................13
4.3.1. Locking the Files ..................................13
4.3.2. Client Caches ......................................14
4.4. Intra-Server Copy .........................................14
4.5. Inter-Server Copy .........................................16
4.6. Server-to-Server Copy Protocol ............................19
4.6.1. Considerations on Selecting a Copy Protocol ........19
4.6.2. Using NFSv4.x as the Copy Protocol .................19
4.6.3. Using an Alternative Copy Protocol .................20
4.7. netloc4 - Network Locations ...............................21
4.8. Copy Offload Stateids .....................................21
4.9. Security Considerations for Server-Side Copy ..............22
4.9.1. Inter-Server Copy Security .........................22
5. Support for Application I/O Hints ..............................30
6. Sparse Files ...................................................30
6.1. Terminology ...............................................31
6.2. New Operations ............................................32
6.2.1. READ_PLUS ..........................................32
6.2.2. DEALLOCATE .........................................32
7. Space Reservation ..............................................32
1. Introduction ....................................................4
1.1. Requirements Language ......................................4
1.2. Scope of This Document .....................................5
1.3. NFSv4.2 Goals ..............................................5
1.4. Overview of NFSv4.2 Features ...............................6
1.4.1. Server-Side Clone and Copy ..........................6
1.4.2. Application Input/Output (I/O) Advise ...............6
1.4.3. Sparse Files ........................................6
1.4.4. Space Reservation ...................................7
1.4.5. Application Data Block (ADB) Support ................7
1.4.6. Labeled NFS .........................................7
1.4.7. Layout Enhancements .................................7
1.5. Enhancements to Minor Versioning Model .....................7
2. Minor Versioning ................................................8
3. pNFS Considerations for New Operations ..........................9
3.1. Atomicity for ALLOCATE and DEALLOCATE ......................9
3.2. Sharing of Stateids with NFSv4.1 ...........................9
3.3. NFSv4.2 as a Storage Protocol in pNFS: The File
Layout Type ................................................9
3.3.1. Operations Sent to NFSv4.2 Data Servers .............9
4. Server-Side Copy ...............................................10
4.1. Protocol Overview .........................................10
4.1.1. COPY Operations ....................................11
4.1.2. Requirements for Operations ........................11
4.2. Requirements for Inter-Server Copy ........................13
4.3. Implementation Considerations .............................13
4.3.1. Locking the Files ..................................13
4.3.2. Client Caches ......................................14
4.4. Intra-Server Copy .........................................14
4.5. Inter-Server Copy .........................................16
4.6. Server-to-Server Copy Protocol ............................19
4.6.1. Considerations on Selecting a Copy Protocol ........19
4.6.2. Using NFSv4.x as the Copy Protocol .................19
4.6.3. Using an Alternative Copy Protocol .................20
4.7. netloc4 - Network Locations ...............................21
4.8. Copy Offload Stateids .....................................21
4.9. Security Considerations for Server-Side Copy ..............22
4.9.1. Inter-Server Copy Security .........................22
5. Support for Application I/O Hints ..............................30
6. Sparse Files ...................................................30
6.1. Terminology ...............................................31
6.2. New Operations ............................................32
6.2.1. READ_PLUS ..........................................32
6.2.2. DEALLOCATE .........................................32
7. Space Reservation ..............................................32
8. Application Data Block Support .................................34
8.1. Generic Framework .........................................35
8.1.1. Data Block Representation ..........................36
8.2. An Example of Detecting Corruption ........................36
8.3. An Example of READ_PLUS ...................................38
8.4. An Example of Zeroing Space ...............................39
9. Labeled NFS ....................................................39
9.1. Definitions ...............................................40
9.2. MAC Security Attribute ....................................41
9.2.1. Delegations ........................................41
9.2.2. Permission Checking ................................42
9.2.3. Object Creation ....................................42
9.2.4. Existing Objects ...................................42
9.2.5. Label Changes ......................................42
9.3. pNFS Considerations .......................................43
9.4. Discovery of Server Labeled NFS Support ...................43
9.5. MAC Security NFS Modes of Operation .......................43
9.5.1. Full Mode ..........................................44
9.5.2. Limited Server Mode ................................45
9.5.3. Guest Mode .........................................45
9.6. Security Considerations for Labeled NFS ...................46
10. Sharing Change Attribute Implementation Characteristics
with NFSv4 Clients ............................................46
11. Error Values ..................................................47
11.1. Error Definitions ........................................47
11.1.1. General Errors ....................................47
11.1.2. Server-to-Server Copy Errors ......................47
11.1.3. Labeled NFS Errors ................................48
11.2. New Operations and Their Valid Errors ....................49
11.3. New Callback Operations and Their Valid Errors ...........53
12. New File Attributes ...........................................54
12.1. New RECOMMENDED Attributes - List and Definition
References ...............................................54
12.2. Attribute Definitions ....................................54
13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL ................57
14. Modifications to NFSv4.1 Operations ...........................61
14.1. Operation 42: EXCHANGE_ID - Instantiate the client ID ....61
14.2. Operation 48: GETDEVICELIST - Get all device
mappings for a file system ...............................63
15. NFSv4.2 Operations ............................................64
15.1. Operation 59: ALLOCATE - Reserve space in a
region of a file .........................................64
15.2. Operation 60: COPY - Initiate a server-side copy .........65
15.3. Operation 61: COPY_NOTIFY - Notify a source
server of a future copy ..................................70
15.4. Operation 62: DEALLOCATE - Unreserve space in a
region of a file .........................................72
8. Application Data Block Support .................................34
8.1. Generic Framework .........................................35
8.1.1. Data Block Representation ..........................36
8.2. An Example of Detecting Corruption ........................36
8.3. An Example of READ_PLUS ...................................38
8.4. An Example of Zeroing Space ...............................39
9. Labeled NFS ....................................................39
9.1. Definitions ...............................................40
9.2. MAC Security Attribute ....................................41
9.2.1. Delegations ........................................41
9.2.2. Permission Checking ................................42
9.2.3. Object Creation ....................................42
9.2.4. Existing Objects ...................................42
9.2.5. Label Changes ......................................42
9.3. pNFS Considerations .......................................43
9.4. Discovery of Server Labeled NFS Support ...................43
9.5. MAC Security NFS Modes of Operation .......................43
9.5.1. Full Mode ..........................................44
9.5.2. Limited Server Mode ................................45
9.5.3. Guest Mode .........................................45
9.6. Security Considerations for Labeled NFS ...................46
10. Sharing Change Attribute Implementation Characteristics
with NFSv4 Clients ............................................46
11. Error Values ..................................................47
11.1. Error Definitions ........................................47
11.1.1. General Errors ....................................47
11.1.2. Server-to-Server Copy Errors ......................47
11.1.3. Labeled NFS Errors ................................48
11.2. New Operations and Their Valid Errors ....................49
11.3. New Callback Operations and Their Valid Errors ...........53
12. New File Attributes ...........................................54
12.1. New RECOMMENDED Attributes - List and Definition
References ...............................................54
12.2. Attribute Definitions ....................................54
13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL ................57
14. Modifications to NFSv4.1 Operations ...........................61
14.1. Operation 42: EXCHANGE_ID - Instantiate the client ID ....61
14.2. Operation 48: GETDEVICELIST - Get all device
mappings for a file system ...............................63
15. NFSv4.2 Operations ............................................64
15.1. Operation 59: ALLOCATE - Reserve space in a
region of a file .........................................64
15.2. Operation 60: COPY - Initiate a server-side copy .........65
15.3. Operation 61: COPY_NOTIFY - Notify a source
server of a future copy ..................................70
15.4. Operation 62: DEALLOCATE - Unreserve space in a
region of a file .........................................72
15.5. Operation 63: IO_ADVISE - Send client I/O access
pattern hints to the server ..............................73
15.6. Operation 64: LAYOUTERROR - Provide errors for
the layout ...............................................79
15.7. Operation 65: LAYOUTSTATS - Provide statistics
for the layout ...........................................82
15.8. Operation 66: OFFLOAD_CANCEL - Stop an offloaded
operation ................................................84
15.9. Operation 67: OFFLOAD_STATUS - Poll for the
status of an asynchronous operation ......................85
15.10. Operation 68: READ_PLUS - READ data or holes
from a file .............................................86
15.11. Operation 69: SEEK - Find the next data or hole .........91
15.12. Operation 70: WRITE_SAME - WRITE an ADB multiple
times to a file .........................................92
15.13. Operation 71: CLONE - Clone a range of a file
into another file .......................................96
16. NFSv4.2 Callback Operations ...................................98
16.1. Operation 15: CB_OFFLOAD - Report the results of
an asynchronous operation ................................98
17. Security Considerations .......................................99
18. IANA Considerations ...........................................99
19. References ...................................................100
19.1. Normative References ....................................100
19.2. Informative References ..................................101
Acknowledgments ..................................................103
Author's Address .................................................104
15.5. Operation 63: IO_ADVISE - Send client I/O access
pattern hints to the server ..............................73
15.6. Operation 64: LAYOUTERROR - Provide errors for
the layout ...............................................79
15.7. Operation 65: LAYOUTSTATS - Provide statistics
for the layout ...........................................82
15.8. Operation 66: OFFLOAD_CANCEL - Stop an offloaded
operation ................................................84
15.9. Operation 67: OFFLOAD_STATUS - Poll for the
status of an asynchronous operation ......................85
15.10. Operation 68: READ_PLUS - READ data or holes
from a file .............................................86
15.11. Operation 69: SEEK - Find the next data or hole .........91
15.12. Operation 70: WRITE_SAME - WRITE an ADB multiple
times to a file .........................................92
15.13. Operation 71: CLONE - Clone a range of a file
into another file .......................................96
16. NFSv4.2 Callback Operations ...................................98
16.1. Operation 15: CB_OFFLOAD - Report the results of
an asynchronous operation ................................98
17. Security Considerations .......................................99
18. IANA Considerations ...........................................99
19. References ...................................................100
19.1. Normative References ....................................100
19.2. Informative References ..................................101
Acknowledgments ..................................................103
Author's Address .................................................104
The NFS version 4 minor version 2 (NFSv4.2) protocol is the third minor version of the NFS version 4 (NFSv4) protocol. The first minor version, NFSv4.0, is described in [RFC7530], and the second minor version, NFSv4.1, is described in [RFC5661].
NFS版本4次要版本2（NFSv4.2）协议是NFS版本4（NFSv4）协议的第三次要版本。[RFC7530]中描述了第一个次要版本NFSv4.0，而[RFC5661]中描述了第二个次要版本NFSv4.1。
As a minor version, NFSv4.2 is consistent with the overall goals for NFSv4, but NFSv4.2 extends the protocol so as to better meet those goals, based on experiences with NFSv4.1. In addition, NFSv4.2 has adopted some additional goals, which motivate some of the major extensions in NFSv4.2.
作为次要版本，NFSv4.2与NFSv4的总体目标一致，但NFSv4.2根据NFSv4.1的经验扩展了协议，以便更好地实现这些目标。此外，NFSv4.2还采用了一些额外的目标，这些目标推动了NFSv4.2中的一些主要扩展。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document describes the NFSv4.2 protocol as a set of extensions to the specification for NFSv4.1. That specification remains current and forms the basis for the additions defined herein. The specification for NFSv4.0 remains current as well.
本文档将NFSv4.2协议描述为NFSv4.1规范的一组扩展。该规范仍然是最新的，并构成本文定义的新增内容的基础。NFSv4.0的规范仍然是最新的。
It is necessary to implement all the REQUIRED features of NFSv4.1 before adding NFSv4.2 features to the implementation. With respect to NFSv4.0 and NFSv4.1, this document does not:
在将NFSv4.2功能添加到实现之前，有必要实现NFSv4.1的所有必需功能。关于NFSv4.0和NFSv4.1，本文件不：
o describe the NFSv4.0 or NFSv4.1 protocols, except where needed to contrast with NFSv4.2
o 描述NFSv4.0或NFSv4.1协议，除非需要与NFSv4.2进行对比
o modify the specification of the NFSv4.0 or NFSv4.1 protocols
o 修改NFSv4.0或NFSv4.1协议的规范
o clarify the NFSv4.0 or NFSv4.1 protocols -- that is, any clarifications made here apply only to NFSv4.2 and not to NFSv4.0 or NFSv4.1
o 澄清NFSv4.0或NFSv4.1协议——也就是说，此处作出的任何澄清仅适用于NFSv4.2，而不适用于NFSv4.0或NFSv4.1
NFSv4.2 is a superset of NFSv4.1, with all of the new features being optional. As such, NFSv4.2 maintains the same compatibility that NFSv4.1 had with NFSv4.0. Any interactions of a new feature with NFSv4.1 semantics is described in the relevant text.
NFSv4.2是NFSv4.1的超集，所有新功能都是可选的。因此，NFSv4.2保持了NFSv4.1与NFSv4.0相同的兼容性。新特性与NFSv4.1语义的任何交互都将在相关文本中描述。
The full External Data Representation (XDR) [RFC4506] for NFSv4.2 is presented in [RFC7863].
NFSv4.2的完整外部数据表示（XDR）[RFC4506]如[RFC7863]所示。
A major goal of the enhancements provided in NFSv4.2 is to take common local file system features that have not been available through earlier versions of NFS and to offer them remotely. These features might
NFSv4.2中提供的增强功能的一个主要目标是采用早期版本的NFS所没有的通用本地文件系统功能，并远程提供这些功能。这些特征可能
o already be available on the servers, e.g., sparse files
o 已在服务器上可用，例如稀疏文件
o be under development as a new standard, e.g., SEEK pulls in both SEEK_HOLE and SEEK_DATA
o 作为一种新标准正在开发中，例如，SEEK同时引入SEEK_孔和SEEK_数据
o be used by clients with the servers via some proprietary means, e.g., Labeled NFS
o 客户机可以通过一些专有的方式使用服务器，例如，标记为NFS
NFSv4.2 provides means for clients to leverage these features on the server in cases in which such leveraging had previously not been possible within the confines of the NFS protocol.
NFSv4.2为客户机提供了在服务器上利用这些功能的方法，在这种情况下，以前在NFS协议的范围内不可能利用这些功能。
A traditional file copy of a remotely accessed file, whether from one server to another or between locations in the same server, results in the data being put on the network twice -- source to client and then client to destination. New operations are introduced to allow unnecessary traffic to be eliminated:
远程访问文件的传统文件拷贝，无论是从一台服务器到另一台服务器，还是在同一台服务器的不同位置之间，都会导致数据在网络上放置两次——从源到客户端，然后从客户端到目的地。引入了新的操作，以消除不必要的流量：
o The intra-server CLONE feature allows the client to request a synchronous cloning, perhaps by copy-on-write semantics.
o 服务器内克隆功能允许客户端请求同步克隆，可能是通过写时复制语义。
o The intra-server COPY feature allows the client to request the server to perform the copy internally, avoiding unnecessary network traffic.
o 服务器内复制功能允许客户端请求服务器在内部执行复制，从而避免不必要的网络流量。
o The inter-server COPY feature allows the client to authorize the source and destination servers to interact directly.
o 服务器间复制功能允许客户端授权源服务器和目标服务器直接交互。
As such copies can be lengthy, asynchronous support is also provided.
由于此类副本可能很长，因此还提供了异步支持。
Applications and clients want to advise the server as to expected I/O behavior. Using IO_ADVISE (see Section 15.5) to communicate future I/O behavior such as whether a file will be accessed sequentially or randomly, and whether a file will or will not be accessed in the near future, allows servers to optimize future I/O requests for a file by, for example, prefetching or evicting data. This operation can be used to support the posix_fadvise() [posix_fadvise] function. In addition, it may be helpful to applications such as databases and video editors.
应用程序和客户端希望就预期的I/O行为向服务器提供建议。使用IO_ADVISE（见第15.5节）传达未来的I/O行为，如文件是按顺序访问还是随机访问，以及文件在不久的将来是否会被访问，允许服务器通过预取或逐出数据等方式优化未来的文件I/O请求。此操作可用于支持posix_fadvise（）[posix_fadvise]功能。此外，它可能对数据库和视频编辑器等应用程序有所帮助。
Sparse files are files that have unallocated or uninitialized data blocks as holes in the file. Such holes are typically transferred as zeros when read from the file. READ_PLUS (see Section 15.10) allows a server to send back to the client metadata describing the hole, and DEALLOCATE (see Section 15.4) allows the client to punch holes into a file. In addition, SEEK (see Section 15.11) is provided to scan for the next hole or data from a given location.
稀疏文件是将未分配或未初始化的数据块作为文件中的孔的文件。从文件中读取时，此类孔通常作为零传输。READ_PLUS（参见第15.10节）允许服务器将描述漏洞的元数据发送回客户端，而DEALLOCATE（参见第15.4节）允许客户端在文件中打孔。此外，还提供SEEK（见第15.11节）以扫描给定位置的下一个孔或数据。
When a file is sparse, one concern that applications have is ensuring that there will always be enough data blocks available for the file during future writes. ALLOCATE (see Section 15.1) allows a client to request a guarantee that space will be available. Also, DEALLOCATE (see Section 15.4) allows the client to punch a hole into a file, thus releasing a space reservation.
当文件稀疏时，应用程序需要考虑的一个问题是确保在将来的写入过程中始终有足够的数据块可供文件使用。ALLOCATE（见第15.1节）允许客户请求保证空间可用。此外，解除分配（参见第15.4节）允许客户端在文件中打孔，从而释放空间保留。
Some applications treat a file as if it were a disk and as such want to initialize (or format) the file image. The WRITE_SAME operation (see Section 15.12) is introduced to send this metadata to the server to allow it to write the block contents.
有些应用程序将文件视为磁盘，因此希望初始化（或格式化）文件映像。引入写入相同操作（参见第15.12节）将此元数据发送到服务器，以允许其写入块内容。
While both clients and servers can employ Mandatory Access Control (MAC) security models to enforce data access, there has been no protocol support for interoperability. A new file object attribute, sec_label (see Section 12.2.4), allows the server to store MAC labels on files, which the client retrieves and uses to enforce data access (see Section 9.5.3). The format of the sec_label accommodates any MAC security system.
虽然客户端和服务器都可以采用强制访问控制（MAC）安全模型来强制数据访问，但互操作性还没有协议支持。新的文件对象属性sec_label（参见第12.2.4节）允许服务器在文件上存储MAC标签，客户端检索并使用这些文件强制数据访问（参见第9.5.3节）。sec_标签的格式适用于任何MAC安全系统。
In the parallel NFS implementations of NFSv4.1 (see Section 12 of [RFC5661]), the client cannot communicate back to the metadata server any errors or performance characteristics with the storage devices. NFSv4.2 provides two new operations to do so: LAYOUTERROR (see Section 15.6) and LAYOUTSTATS (see Section 15.7), respectively.
在NFSv4.1的并行NFS实现中（请参见[RFC5661]的第12节），客户端无法与元数据服务器通信存储设备的任何错误或性能特征。NFSv4.2提供了两个新的操作：LAYOUTERROR（参见第15.6节）和LAYOUTSTATS（参见第15.7节）。
In NFSv4.1, the only way to introduce new variants of an operation was to introduce a new operation. For instance, READ would have to be replaced or supplemented by, say, either READ2 or READ_PLUS. With the use of discriminated unions as parameters for such functions in NFSv4.2, it is possible to add a new "arm" (i.e., a new entry in the union and a corresponding new field in the structure) in a subsequent minor version. It is also possible to move such an operation from OPTIONAL/RECOMMENDED to REQUIRED. Forcing an implementation to adopt each arm of a discriminated union at such a time does not meet the spirit of the minor versioning rules. As such, new arms of a discriminated union MUST follow the same guidelines for minor
在NFSv4.1中，引入新操作变体的唯一方法是引入新操作。例如，READ必须由READ2或READ_PLUS替换或补充。在NFSv4.2中，使用有区别的并集作为此类函数的参数，可以在后续次要版本中添加新的“arm”（即并集中的新条目和结构中相应的新字段）。也可以将此类操作从可选/推荐移动到必需。在这种情况下，强制实现采用受歧视联盟的每个分支并不符合次要版本控制规则的精神。因此，受歧视工会的新成员必须遵循同样的未成年人指导方针
versioning as operations in NFSv4.1 -- i.e., they may not be made REQUIRED. To support this, a new error code, NFS4ERR_UNION_NOTSUPP, allows the server to communicate to the client that the operation is supported but the specific arm of the discriminated union is not.
在NFSv4.1中作为操作进行版本控制——也就是说，它们可能不是必需的。为了支持这一点，一个新的错误代码NFS4ERR_UNION_NOTSUPP允许服务器与客户端通信，表明该操作受支持，但受歧视的UNION的特定臂不受支持。
NFSv4.2 is a minor version of NFSv4 and is built upon NFSv4.1 as documented in [RFC5661] and [RFC5662].
NFSv4.2是NFSv4的一个次要版本，它建立在[RFC5661]和[RFC5662]中记录的NFSv4.1之上。
NFSv4.2 does not modify the rules applicable to the NFSv4 versioning process and follows the rules set out in [RFC5661] or in Standards Track documents updating that document (e.g., in an RFC based on [NFSv4-Versioning]).
NFSv4.2不修改适用于NFSv4版本控制过程的规则，并遵循[RFC5661]或更新该文档的标准跟踪文档中规定的规则（例如，在基于[NFSv4版本控制]的RFC中）。
NFSv4.2 only defines extensions to NFSv4.1, each of which may be supported (or not) independently. It does not
NFSv4.2仅定义对NFSv4.1的扩展，每个扩展都可以独立支持（或不支持）。事实并非如此
o introduce infrastructural features
o 介绍基础设施特点
o make existing features MANDATORY to NOT implement
o 将现有功能设为不实施的强制功能
o change the status of existing features (i.e., by changing their status among OPTIONAL, RECOMMENDED, REQUIRED)
o 更改现有功能的状态（即，通过在可选、推荐、必需之间更改其状态）
The following versioning-related considerations should be noted.
应注意以下与版本控制相关的注意事项。
o When a new case is added to an existing switch, servers need to report non-support of that new case by returning NFS4ERR_UNION_NOTSUPP.
o 将新案例添加到现有交换机时，服务器需要通过返回NFS4ERR_UNION_NOTSUPP来报告不支持该新案例。
o As regards the potential cross-minor-version transfer of stateids, Parallel NFS (pNFS) (see Section 12 of [RFC5661]) implementations of the file-mapping type may support the use of an NFSv4.2 metadata server (see Sections 1.7.2.2 and 12.2.2 of [RFC5661]) with NFSv4.1 data servers. In this context, a stateid returned by an NFSv4.2 COMPOUND will be used in an NFSv4.1 COMPOUND directed to the data server (see Sections 3.2 and 3.3).
o 关于StateID的潜在跨次要版本传输，文件映射类型的并行NFS（pNFS）（见[RFC5661]第12节）实现可支持使用NFSv4.2元数据服务器（见[RFC5661]第1.7.2.2和12.2.2节）和NFSv4.1数据服务器。在此上下文中，NFSv4.2复合返回的stateid将用于定向到数据服务器的NFSv4.1复合中（参见第3.2节和第3.3节）。
The interactions of the new operations with non-pNFS functionality are straightforward and are covered in the relevant sections. However, the interactions of the new operations with pNFS are more complicated. This section provides an overview.
新操作与非pNFS功能的交互非常简单，相关章节将对此进行介绍。然而，新操作与PNF的交互更为复杂。本节提供了一个概述。
Both ALLOCATE (see Section 15.1) and DEALLOCATE (see Section 15.4) are sent to the metadata server, which is responsible for coordinating the changes onto the storage devices. In particular, both operations must either fully succeed or fail; it cannot be the case that one storage device succeeds whilst another fails.
分配（参见第15.1节）和解除分配（参见第15.4节）都发送到元数据服务器，元数据服务器负责协调对存储设备的更改。特别是，这两项行动要么完全成功，要么失败；不能出现一个存储设备成功而另一个存储设备失败的情况。
An NFSv4.2 metadata server can hand out a layout to an NFSv4.1 storage device. Section 13.9.1 of [RFC5661] discusses how the client gets a stateid from the metadata server to present to a storage device.
NFSv4.2元数据服务器可以向NFSv4.1存储设备分发布局。[RFC5661]的第13.9.1节讨论了客户机如何从元数据服务器获取stateid以呈现给存储设备。
A file layout provided by an NFSv4.2 server may refer to either (1) a storage device that only implements NFSv4.1 as specified in [RFC5661] or (2) a storage device that implements additions from NFSv4.2, in which case the rules in Section 3.3.1 apply. As the file layout type does not provide a means for informing the client as to which minor version a particular storage device is providing, the client will have to negotiate this with the storage device via the normal Remote Procedure Call (RPC) semantics of major and minor version discovery. For example, as per Section 16.2.3 of [RFC5661], the client could try a COMPOUND with a minorversion field value of 2; if it gets NFS4ERR_MINOR_VERS_MISMATCH, it would drop back to 1.
NFSv4.2服务器提供的文件布局可指（1）仅实现[RFC5661]中规定的NFSv4.1的存储设备，或（2）实现NFSv4.2添加的存储设备，在这种情况下，第3.3.1节中的规则适用。由于文件布局类型不提供通知客户端特定存储设备提供的次要版本的方法，因此客户端必须通过主要和次要版本发现的正常远程过程调用（RPC）语义与存储设备协商。例如，根据[RFC5661]第16.2.3节，客户可以尝试minorversion字段值为2的化合物；如果它得到NFS4ERR_MINOR_VERS_失配，它将回落到1。
In addition to the commands listed in [RFC5661], NFSv4.2 data servers MAY accept a COMPOUND containing the following additional operations: IO_ADVISE (see Section 15.5), READ_PLUS (see Section 15.10), WRITE_SAME (see Section 15.12), and SEEK (see Section 15.11), which will be treated like the subset specified as "Operations Sent to NFSv4.1 Data Servers" in Section 13.6 of [RFC5661].
除了[RFC5661]中列出的命令外，NFSv4.2数据服务器还可以接受包含以下附加操作的复合操作：IO_advice（参见第15.5节）、READ_PLUS（参见第15.10节）、WRITE_SAME（参见第15.12节）和SEEK（参见第15.11节），这些操作将被视为[RFC5661]第13.6节中的“发送到NFSv4.1数据服务器的操作”。
Additional details on the implementation of these operations in a pNFS context are documented in the operation-specific sections.
有关在pNFS上下文中实现这些操作的其他详细信息，请参见操作特定部分。
The server-side copy features provide mechanisms that allow an NFS client to copy file data on a server or between two servers without the data being transmitted back and forth over the network through the NFS client. Without these features, an NFS client would copy data from one location to another by reading the data from the source server over the network and then writing the data back over the network to the destination server.
服务器端复制功能提供了允许NFS客户端在服务器上或两台服务器之间复制文件数据的机制，而无需通过NFS客户端在网络上来回传输数据。如果没有这些功能，NFS客户端将通过网络从源服务器读取数据，然后通过网络将数据写回目标服务器，从而将数据从一个位置复制到另一个位置。
If the source object and destination object are on different file servers, the file servers will communicate with one another to perform the COPY operation. The server-to-server protocol by which this is accomplished is not defined in this document.
如果源对象和目标对象位于不同的文件服务器上，则文件服务器将相互通信以执行复制操作。本文档中未定义完成此操作所使用的服务器到服务器协议。
The copy feature allows the server to perform the copying either synchronously or asynchronously. The client can request synchronous copying, but the server may not be able to honor this request. If the server intends to perform asynchronous copying, it supplies the client with a request identifier that the client can use to monitor the progress of the copying and, if appropriate, cancel a request in progress. The request identifier is a stateid representing the internal state held by the server while the copying is performed. Multiple asynchronous copies of all or part of a file may be in progress in parallel on a server; the stateid request identifier allows monitoring and canceling to be applied to the correct request.
复制功能允许服务器同步或异步执行复制。客户端可以请求同步复制，但服务器可能无法满足此请求。如果服务器打算执行异步复制，它会向客户机提供一个请求标识符，客户机可以使用该标识符监视复制的进度，并在适当的情况下取消正在进行的请求。请求标识符是一个stateid，表示执行复制时服务器持有的内部状态。一台服务器上可能并行进行文件全部或部分的多个异步副本；stateid请求标识符允许对正确的请求应用监视和取消。
The server-side copy offload operations support both intra-server and inter-server file copies. An intra-server copy is a copy in which the source file and destination file reside on the same server. In an inter-server copy, the source file and destination file are on different servers. In both cases, the copy may be performed synchronously or asynchronously.
服务器端拷贝卸载操作支持服务器内和服务器间文件拷贝。服务器内副本是源文件和目标文件位于同一服务器上的副本。在服务器间副本中，源文件和目标文件位于不同的服务器上。在这两种情况下，可以同步或异步执行复制。
In addition, the CLONE operation provides COPY-like functionality in the intra-server case, which is both synchronous and atomic in that other operations may not see the target file in any state between the state before the CLONE operation and the state after it.
此外，克隆操作在服务器内部情况下提供了类似复制的功能，这是同步和原子的，因为其他操作可能看不到目标文件处于克隆操作之前和之后的任何状态。
Throughout the rest of this document, the NFS server containing the source file is referred to as the "source server" and the NFS server to which the file is transferred as the "destination server". In the case of an intra-server copy, the source server and destination server are the same server. Therefore, in the context of an intra-server copy, the terms "source server" and "destination server" refer to the single server performing the copy.
在本文档的其余部分中，包含源文件的NFS服务器称为“源服务器”，文件传输到的NFS服务器称为“目标服务器”。对于服务器内副本，源服务器和目标服务器是相同的服务器。因此，在服务器内复制的上下文中，术语“源服务器”和“目标服务器”指执行复制的单个服务器。
The new operations are designed to copy files or regions within them. Other file system objects can be copied by building on these operations or using other techniques. For example, if a user wishes to copy a directory, the client can synthesize a directory COPY operation by first creating the destination directory and the individual (empty) files within it and then copying the contents of the source directory's files to files in the new destination directory.
新操作旨在复制其中的文件或区域。通过构建这些操作或使用其他技术，可以复制其他文件系统对象。例如，如果用户希望复制目录，客户端可以通过首先创建目标目录和其中的单个（空）文件，然后将源目录文件的内容复制到新目标目录中的文件来合成目录复制操作。
For the inter-server copy, the operations are defined to be compatible with the traditional copy authorization approach. The client and user are authorized at the source for reading. Then, they are authorized at the destination for writing.
对于服务器间拷贝，操作定义为与传统拷贝授权方法兼容。客户端和用户在源代码处被授权阅读。然后，他们在目的地被授权写作。
CLONE: Used by the client to request a synchronous atomic COPY-like operation. (Section 15.13)
克隆：客户端用于请求类似于原子拷贝的同步操作。（第15.13节）
COPY_NOTIFY: Used by the client to request the source server to authorize a future file copy that will be made by a given destination server on behalf of the given user. (Section 15.3)
COPY_NOTIFY：客户端用于请求源服务器授权将来由给定目标服务器代表给定用户进行的文件复制。（第15.3节）
COPY: Used by the client to request a file copy. (Section 15.2)
副本：客户端用于请求文件副本。（第15.2节）
OFFLOAD_CANCEL: Used by the client to terminate an asynchronous file copy. (Section 15.8)
卸载\u取消：客户端用于终止异步文件复制。（第15.8节）
OFFLOAD_STATUS: Used by the client to poll the status of an asynchronous file copy. (Section 15.9)
卸载状态：客户端用于轮询异步文件副本的状态。（第15.9节）
CB_OFFLOAD: Used by the destination server to report the results of an asynchronous file copy to the client. (Section 16.1)
CB_卸载：由目标服务器用于向客户端报告异步文件复制的结果。（第16.1节）
Inter-server copy, intra-server copy, and intra-server clone are each OPTIONAL features in the context of server-side copy. A server may choose independently to implement any of them. A server implementing any of these features may be REQUIRED to implement certain operations. Other operations are OPTIONAL in the context of a particular feature (see Table 5 in Section 13) but may become REQUIRED, depending on server behavior. Clients need to use these operations to successfully copy a file.
服务器间拷贝、服务器内拷贝和服务器内克隆都是服务器端拷贝上下文中的可选功能。服务器可以独立选择实现它们中的任何一个。实现这些功能的服务器可能需要实现某些操作。在特定功能的上下文中，其他操作是可选的（参见第13节中的表5），但可能是必需的，具体取决于服务器行为。客户端需要使用这些操作来成功复制文件。
For a client to do an intra-server file copy, it needs to use either the COPY or the CLONE operation. If COPY is used, the client MUST support the CB_OFFLOAD operation. If COPY is used and it returns a stateid, then the client MAY use the OFFLOAD_CANCEL and OFFLOAD_STATUS operations.
对于要执行服务器内文件复制的客户端，它需要使用复制或克隆操作。如果使用复制，客户端必须支持CB_卸载操作。如果使用了COPY并返回stateid，则客户端可以使用卸载\取消和卸载\状态操作。
For a client to do an inter-server file copy, it needs to use the COPY and COPY_NOTIFY operations and MUST support the CB_OFFLOAD operation. If COPY returns a stateid, then the client MAY use the OFFLOAD_CANCEL and OFFLOAD_STATUS operations.
对于要执行服务器间文件复制的客户端，它需要使用copy和copy_NOTIFY操作，并且必须支持CB_卸载操作。如果COPY返回stateid，则客户端可以使用卸载\取消和卸载\状态操作。
If a server supports the intra-server COPY feature, then the server MUST support the COPY operation. If a server's COPY operation returns a stateid, then the server MUST also support these operations: CB_OFFLOAD, OFFLOAD_CANCEL, and OFFLOAD_STATUS.
如果服务器支持服务器内复制功能，则服务器必须支持复制操作。如果服务器的复制操作返回stateid，则服务器还必须支持以下操作：CB_卸载、卸载_取消和卸载_状态。
If a server supports the CLONE feature, then it MUST support the CLONE operation and the clone_blksize attribute on any file system on which CLONE is supported (as either source or destination file).
如果服务器支持克隆功能，则它必须在支持克隆的任何文件系统（作为源文件或目标文件）上支持克隆操作和CLONE_blksize属性。
If a source server supports the inter-server COPY feature, then it MUST support the COPY_NOTIFY and OFFLOAD_CANCEL operations. If a destination server supports the inter-server COPY feature, then it MUST support the COPY operation. If a destination server's COPY operation returns a stateid, then the destination server MUST also support these operations: CB_OFFLOAD, OFFLOAD_CANCEL, COPY_NOTIFY, and OFFLOAD_STATUS.
如果源服务器支持服务器间复制功能，则它必须支持复制通知和卸载取消操作。如果目标服务器支持服务器间复制功能，则必须支持复制操作。如果目标服务器的复制操作返回stateid，则目标服务器还必须支持以下操作：CB_卸载、卸载_取消、复制_通知和卸载_状态。
Each operation is performed in the context of the user identified by the Open Network Computing (ONC) RPC credential in the RPC request containing the COMPOUND or CB_COMPOUND request. For example, an OFFLOAD_CANCEL operation issued by a given user indicates that a specified COPY operation initiated by the same user is to be canceled. Therefore, an OFFLOAD_CANCEL MUST NOT interfere with a copy of the same file initiated by another user.
每个操作都在包含复合或CB_复合请求的RPC请求中由开放网络计算（ONC）RPC凭据标识的用户上下文中执行。例如，给定用户发出的卸载取消操作表示要取消由同一用户发起的指定复制操作。因此，卸载取消不得干扰由另一用户启动的同一文件的副本。
An NFS server MAY allow an administrative user to monitor or cancel COPY operations using an implementation-specific interface.
NFS服务器可以允许管理用户使用特定于实现的接口监视或取消复制操作。
The specification of the inter-server copy is driven by several requirements:
服务器间副本的规范由以下几个要求驱动：
o The specification MUST NOT mandate the server-to-server protocol.
o 规范不得强制使用服务器到服务器协议。
o The specification MUST provide guidance for using NFSv4.x as a copy protocol. For those source and destination servers willing to use NFSv4.x, there are specific security considerations that the specification MUST address.
o 规范必须提供使用NFSv4.x作为复制协议的指南。对于那些愿意使用NFSv4.x的源服务器和目标服务器，规范必须解决一些特定的安全问题。
o The specification MUST NOT mandate preconfiguration between the source and destination servers. Requiring that the source and destination servers first have a "copying relationship" increases the administrative burden. However, the specification MUST NOT preclude implementations that require preconfiguration.
o 规范不得强制要求在源服务器和目标服务器之间进行预配置。要求源服务器和目标服务器首先具有“复制关系”会增加管理负担。但是，规范不得排除需要预配置的实现。
o The specification MUST NOT mandate a trust relationship between the source and destination servers. The NFSv4 security model requires mutual authentication between a principal on an NFS client and a principal on an NFS server. This model MUST continue with the introduction of COPY.
o 规范不得强制要求源服务器和目标服务器之间存在信任关系。NFSv4安全模型要求NFS客户端上的主体和NFS服务器上的主体之间进行相互身份验证。这种模式必须继续引入复制。
Both the source file and the destination file may need to be locked to protect the content during the COPY operations. A client can achieve this by a combination of OPEN and LOCK operations. That is, either share locks or byte-range locks might be desired.
在复制操作期间，可能需要锁定源文件和目标文件以保护内容。客户端可以通过组合打开和锁定操作来实现这一点。也就是说，可能需要共享锁或字节范围锁。
Note that when the client establishes a lock stateid on the source, the context of that stateid is for the client and not the destination. As such, there might already be an outstanding stateid, issued to the destination as the client of the source, with the same value as that provided for the lock stateid. The source MUST interpret the lock stateid as that of the client, i.e., when the destination presents it in the context of an inter-server copy, it is on behalf of the client.
请注意，当客户端在源上建立锁stateid时，该stateid的上下文是针对客户端的，而不是针对目标的。因此，可能已经有一个未完成的stateid作为源的客户机发布到目标，其值与为lock stateid提供的值相同。源必须将锁stateid解释为客户端的锁stateid，即，当目标在服务器间副本的上下文中显示锁stateid时，它代表客户端。
In a traditional copy, if the client is in the process of writing to the file before the copy (and perhaps with a write delegation), it will be straightforward to update the destination server. With an inter-server copy, the source has no insight into the changes cached on the client. The client SHOULD write the data back to the source. If it does not do so, it is possible that the destination will receive a corrupt copy of the file.
在传统的副本中，如果客户机在副本之前正在写入文件（可能还有写入委派），则直接更新目标服务器。对于服务器间副本，源无法洞察客户端上缓存的更改。客户端应该将数据写回源。如果不这样做，则目标可能会收到文件的损坏副本。
To copy a file on a single server, the client uses a COPY operation. The server may respond to the COPY operation with the final results of the copy, or it may perform the copy asynchronously and deliver the results using a CB_OFFLOAD callback operation. If the copy is performed asynchronously, the client may poll the status of the copy using OFFLOAD_STATUS or cancel the copy using OFFLOAD_CANCEL.
要在单个服务器上复制文件，客户端使用复制操作。服务器可以使用复制的最终结果响应复制操作，也可以异步执行复制并使用CB_卸载回调操作交付结果。如果复制是异步执行的，则客户端可以使用OFFLOAD\u status轮询复制的状态，或者使用OFFLOAD\u cancel取消复制。
A synchronous intra-server copy is shown in Figure 1. In this example, the NFS server chooses to perform the copy synchronously. The COPY operation is completed, either successfully or unsuccessfully, before the server replies to the client's request. The server's reply contains the final result of the operation.
图1显示了一个同步的服务器内部拷贝。在本例中，NFS服务器选择同步执行复制。复制操作在服务器答复客户端请求之前完成（成功或失败）。服务器的回复包含操作的最终结果。
Client Server
+ +
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the source file
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the destination file
| |
|--- COPY ---------------------------->| Client requests
|<------------------------------------/| a file copy
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the destination file
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the source file
| |
| |
Client Server
+ +
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the source file
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the destination file
| |
|--- COPY ---------------------------->| Client requests
|<------------------------------------/| a file copy
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the destination file
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the source file
| |
| |
Figure 1: A Synchronous Intra-Server Copy
图1：同步服务器内拷贝
An asynchronous intra-server copy is shown in Figure 2. In this example, the NFS server performs the copy asynchronously. The server's reply to the copy request indicates that the COPY operation was initiated and the final result will be delivered at a later time. The server's reply also contains a copy stateid. The client may use this copy stateid to poll for status information (as shown) or to cancel the copy using an OFFLOAD_CANCEL. When the server completes the copy, the server performs a callback to the client and reports the results.
异步服务器内部副本如图2所示。在本例中，NFS服务器异步执行复制。服务器对复制请求的答复表明复制操作已启动，最终结果将在稍后交付。服务器的回复还包含一个副本stateid。客户端可以使用此副本stateid轮询状态信息（如图所示），或者使用卸载按钮取消副本。当服务器完成复制时，服务器将向客户端执行回调并报告结果。
Client Server
+ +
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the source file
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the destination file
| |
|--- COPY ---------------------------->| Client requests
|<------------------------------------/| a file copy
| |
| |
|--- OFFLOAD_STATUS ------------------>| Client may poll
|<------------------------------------/| for status
| |
| . | Multiple OFFLOAD_STATUS
| . | operations may be sent
| . |
| |
|<-- CB_OFFLOAD -----------------------| Server reports results
|\------------------------------------>|
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the destination file
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the source file
| |
| |
Client Server
+ +
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the source file
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the destination file
| |
|--- COPY ---------------------------->| Client requests
|<------------------------------------/| a file copy
| |
| |
|--- OFFLOAD_STATUS ------------------>| Client may poll
|<------------------------------------/| for status
| |
| . | Multiple OFFLOAD_STATUS
| . | operations may be sent
| . |
| |
|<-- CB_OFFLOAD -----------------------| Server reports results
|\------------------------------------>|
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the destination file
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the source file
| |
| |
Figure 2: An Asynchronous Intra-Server Copy
图2：异步服务器内副本
A copy may also be performed between two servers. The copy protocol is designed to accommodate a variety of network topologies. As shown in Figure 3, the client and servers may be connected by multiple networks. In particular, the servers may be connected by a specialized, high-speed network (network 192.0.2.0/24 in the diagram) that does not include the client. The protocol allows the client to set up the copy between the servers (over network 203.0.113.0/24 in the diagram) and for the servers to communicate on the high-speed network if they choose to do so.
还可以在两台服务器之间执行复制。复制协议旨在适应各种网络拓扑。如图3所示，客户机和服务器可以通过多个网络连接。特别地，服务器可以通过不包括客户端的专用高速网络（图中的网络192.0.2.0/24）连接。该协议允许客户端在服务器之间设置副本（在图中通过网络203.0.113.0/24），并允许服务器在高速网络上进行通信（如果它们选择这样做）。
192.0.2.0/24
+-------------------------------------+
| |
| |
| 192.0.2.18 | 192.0.2.56
+-------+------+ +------+------+
| Source | | Destination |
+-------+------+ +------+------+
| 203.0.113.18 | 203.0.113.56
| |
| |
| 203.0.113.0/24 |
+------------------+------------------+
|
|
| 203.0.113.243
+-----+-----+
| Client |
+-----------+
192.0.2.0/24
+-------------------------------------+
| |
| |
| 192.0.2.18 | 192.0.2.56
+-------+------+ +------+------+
| Source | | Destination |
+-------+------+ +------+------+
| 203.0.113.18 | 203.0.113.56
| |
| |
| 203.0.113.0/24 |
+------------------+------------------+
|
|
| 203.0.113.243
+-----+-----+
| Client |
+-----------+
Figure 3: An Example Inter-Server Network Topology
图3：服务器间网络拓扑示例
For an inter-server copy, the client notifies the source server that a file will be copied by the destination server using a COPY_NOTIFY operation. The client then initiates the copy by sending the COPY operation to the destination server. The destination server may perform the copy synchronously or asynchronously.
对于服务器间复制，客户端通知源服务器，目标服务器将使用“复制通知”操作复制文件。然后，客户端通过将复制操作发送到目标服务器来启动复制。目标服务器可以同步或异步执行复制。
A synchronous inter-server copy is shown in Figure 4. In this case, the destination server chooses to perform the copy before responding to the client's COPY request.
同步服务器间拷贝如图4所示。在这种情况下，目标服务器选择在响应客户端的复制请求之前执行复制。
Client Source Destination
+ + +
| | |
|--- OPEN --->| | Returns
|<------------------/| | open state os1
| | |
|--- COPY_NOTIFY --->| |
|<------------------/| |
| | |
|--- OPEN ---------------------------->| Returns
|<------------------------------------/| open state os2
| | |
|--- COPY ---------------------------->|
| | |
| | |
| |<----- READ -----|
| |\--------------->|
| | |
| | . | Multiple READs may
| | . | be necessary
| | . |
| | |
| | |
|<------------------------------------/| Destination replies
| | | to COPY
| | |
|--- CLOSE --------------------------->| Release os2
|<------------------------------------/|
| | |
|--- CLOSE --->| | Release os1
|<------------------/| |
Client Source Destination
+ + +
| | |
|--- OPEN --->| | Returns
|<------------------/| | open state os1
| | |
|--- COPY_NOTIFY --->| |
|<------------------/| |
| | |
|--- OPEN ---------------------------->| Returns
|<------------------------------------/| open state os2
| | |
|--- COPY ---------------------------->|
| | |
| | |
| |<----- READ -----|
| |\--------------->|
| | |
| | . | Multiple READs may
| | . | be necessary
| | . |
| | |
| | |
|<------------------------------------/| Destination replies
| | | to COPY
| | |
|--- CLOSE --------------------------->| Release os2
|<------------------------------------/|
| | |
|--- CLOSE --->| | Release os1
|<------------------/| |
Figure 4: A Synchronous Inter-Server Copy
图4：同步服务器间拷贝
An asynchronous inter-server copy is shown in Figure 5. In this case, the destination server chooses to respond to the client's COPY request immediately and then perform the copy asynchronously.
异步服务器间副本如图5所示。在这种情况下，目标服务器选择立即响应客户端的复制请求，然后异步执行复制。
Client Source Destination
+ + +
| | |
|--- OPEN --->| | Returns
|<------------------/| | open state os1
| | |
|--- LOCK --->| | Optional; could be done
|<------------------/| | with a share lock
| | |
|--- COPY_NOTIFY --->| | Need to pass in
|<------------------/| | os1 or lock state
| | |
| | |
| | |
|--- OPEN ---------------------------->| Returns
|<------------------------------------/| open state os2
| | |
|--- LOCK ---------------------------->| Optional ...
|<------------------------------------/|
| | |
|--- COPY ---------------------------->| Need to pass in
|<------------------------------------/| os2 or lock state
| | |
| | |
| |<----- READ -----|
| |\--------------->|
| | |
| | . | Multiple READs may
| | . | be necessary
| | . |
| | |
| | |
|--- OFFLOAD_STATUS ------------------>| Client may poll
|<------------------------------------/| for status
| | |
| | . | Multiple OFFLOAD_STATUS
| | . | operations may be sent
| | . |
| | |
| | |
| | |
|<-- CB_OFFLOAD -----------------------| Destination reports
|\------------------------------------>| results
| | |
Client Source Destination
+ + +
| | |
|--- OPEN --->| | Returns
|<------------------/| | open state os1
| | |
|--- LOCK --->| | Optional; could be done
|<------------------/| | with a share lock
| | |
|--- COPY_NOTIFY --->| | Need to pass in
|<------------------/| | os1 or lock state
| | |
| | |
| | |
|--- OPEN ---------------------------->| Returns
|<------------------------------------/| open state os2
| | |
|--- LOCK ---------------------------->| Optional ...
|<------------------------------------/|
| | |
|--- COPY ---------------------------->| Need to pass in
|<------------------------------------/| os2 or lock state
| | |
| | |
| |<----- READ -----|
| |\--------------->|
| | |
| | . | Multiple READs may
| | . | be necessary
| | . |
| | |
| | |
|--- OFFLOAD_STATUS ------------------>| Client may poll
|<------------------------------------/| for status
| | |
| | . | Multiple OFFLOAD_STATUS
| | . | operations may be sent
| | . |
| | |
| | |
| | |
|<-- CB_OFFLOAD -----------------------| Destination reports
|\------------------------------------>| results
| | |
|--- LOCKU --------------------------->| Only if LOCK was done
|<------------------------------------/|
| | |
|--- CLOSE --------------------------->| Release os2
|<------------------------------------/|
| | |
|--- LOCKU --->| | Only if LOCK was done
|<------------------/| |
| | |
|--- CLOSE --->| | Release os1
|<------------------/| |
| | |
|--- LOCKU --------------------------->| Only if LOCK was done
|<------------------------------------/|
| | |
|--- CLOSE --------------------------->| Release os2
|<------------------------------------/|
| | |
|--- LOCKU --->| | Only if LOCK was done
|<------------------/| |
| | |
|--- CLOSE --->| | Release os1
|<------------------/| |
| | |
Figure 5: An Asynchronous Inter-Server Copy
图5：异步服务器间副本
The choice of what protocol to use in an inter-server copy is ultimately the destination server's decision. However, the destination server has to be cognizant that it is working on behalf of the client.
在服务器间副本中使用何种协议的选择最终由目标服务器决定。但是，目标服务器必须知道它是代表客户机工作的。
The client can have requirements over both the size of transactions and error recovery semantics. It may want to split the copy up such that each chunk is synchronously transferred. It may want the copy protocol to copy the bytes in consecutive order such that upon an error the client can restart the copy at the last known good offset. If the destination server cannot meet these requirements, the client may prefer the traditional copy mechanism such that it can meet those requirements.
客户机可以对事务的大小和错误恢复语义都有要求。它可能希望分割副本，以便同步传输每个块。它可能希望复制协议以连续顺序复制字节，以便在出现错误时，客户端可以在最后一个已知的正确偏移量处重新启动复制。如果目标服务器无法满足这些要求，客户机可能更喜欢传统的复制机制，以便能够满足这些要求。
The destination server MAY use standard NFSv4.x (where x >= 1) operations to read the data from the source server. If NFSv4.x is used for the server-to-server copy protocol, the destination server can use the source filehandle and ca_src_stateid provided in the COPY request with standard NFSv4.x operations to read data from the source server. Note that the ca_src_stateid MUST be the cnr_stateid returned from the source via the COPY_NOTIFY (Section 15.3).
目标服务器可以使用标准NFSv4.x（其中x>=1）操作从源服务器读取数据。如果服务器到服务器复制协议使用NFSv4.x，则目标服务器可以使用复制请求中提供的源文件句柄和ca_src_stateid以及标准NFSv4.x操作从源服务器读取数据。请注意，ca_src_stateid必须是通过副本通知从源返回的cnr_stateid（第15.3节）。
In a homogeneous environment, the source and destination servers might be able to perform the file copy extremely efficiently using specialized protocols. For example, the source and destination servers might be two nodes sharing a common file system format for the source and destination file systems. Thus, the source and destination are in an ideal position to efficiently render the image of the source file to the destination file by replicating the file system formats at the block level. Another possibility is that the source and destination might be two nodes sharing a common storage area network, and thus there is no need to copy any data at all; instead, ownership of the file and its contents might simply be reassigned to the destination. To allow for these possibilities, the destination server is allowed to use a server-to-server copy protocol of its choice.
在同构环境中，源服务器和目标服务器可能能够使用专用协议极其高效地执行文件复制。例如，源服务器和目标服务器可能是共享源文件系统和目标文件系统的公共文件系统格式的两个节点。因此，源和目标处于理想位置，通过在块级别复制文件系统格式，可以有效地将源文件的图像渲染到目标文件。另一种可能性是源和目标可能是共享公共存储区域网络的两个节点，因此根本不需要复制任何数据；相反，文件及其内容的所有权可能只是重新分配给目标。为了考虑这些可能性，允许目标服务器使用其选择的服务器到服务器复制协议。
In a heterogeneous environment, using a protocol other than NFSv4.x (e.g., HTTP [RFC7230] or FTP [RFC959]) presents some challenges. In particular, the destination server is presented with the challenge of accessing the source file given only an NFSv4.x filehandle.
在异构环境中，使用NFSv4.x以外的协议（例如HTTP[RFC7230]或FTP[RFC959]）会带来一些挑战。特别是，目标服务器面临的挑战是，仅在给定NFSv4.x文件句柄的情况下访问源文件。
One option for protocols that identify source files with pathnames is to use an ASCII hexadecimal representation of the source filehandle as the filename.
使用路径名标识源文件的协议的一个选项是使用源文件句柄的ASCII十六进制表示形式作为文件名。
Another option for the source server is to use URLs to direct the destination server to a specialized service. For example, the response to COPY_NOTIFY could include the URL <ftp://s1.example.com:9999/_FH/0x12345>, where 0x12345 is the ASCII hexadecimal representation of the source filehandle. When the destination server receives the source server's URL, it would use "_FH/0x12345" as the filename to pass to the FTP server listening on port 9999 of s1.example.com. On port 9999 there would be a special instance of the FTP service that understands how to convert NFS filehandles to an open file descriptor (in many operating systems, this would require a new system call, one that is the inverse of the makefh() function that the pre-NFSv4 MOUNT service needs).
源服务器的另一个选项是使用URL将目标服务器定向到专用服务。例如，对COPY_NOTIFY的响应可能包括URL<ftp://s1.example.com:9999/_FH/0x12345>，其中0x12345是源文件句柄的ASCII十六进制表示形式。当目标服务器接收到源服务器的URL时，它将使用“_FH/0x12345”作为文件名传递给在s1.example.com的端口9999上侦听的FTP服务器。在端口9999上，将有一个FTP服务的特殊实例，它了解如何将NFS文件句柄转换为打开的文件描述符（在许多操作系统中，这将需要一个新的系统调用，该调用与NFSv4装载前服务所需的makefh（）函数相反）。
Authenticating and identifying the destination server to the source server is also a challenge. One solution would be to construct unique URLs for each destination server.
向源服务器验证和标识目标服务器也是一项挑战。一种解决方案是为每个目标服务器构造唯一的URL。
The server-side COPY operations specify network locations using the netloc4 data type shown below (see [RFC7863]):
服务器端复制操作使用如下所示的netloc4数据类型指定网络位置（请参阅[RFC7863]）：
<CODE BEGINS>
<代码开始>
enum netloc_type4 {
NL4_NAME = 1,
NL4_URL = 2,
NL4_NETADDR = 3
};
enum netloc_type4 {
NL4_NAME = 1,
NL4_URL = 2,
NL4_NETADDR = 3
};
union netloc4 switch (netloc_type4 nl_type) {
case NL4_NAME: utf8str_cis nl_name;
case NL4_URL: utf8str_cis nl_url;
case NL4_NETADDR: netaddr4 nl_addr;
};
union netloc4 switch (netloc_type4 nl_type) {
case NL4_NAME: utf8str_cis nl_name;
case NL4_URL: utf8str_cis nl_url;
case NL4_NETADDR: netaddr4 nl_addr;
};
<CODE ENDS>
<代码结束>
If the netloc4 is of type NL4_NAME, the nl_name field MUST be specified as a UTF-8 string. The nl_name is expected to be resolved to a network address via DNS, the Lightweight Directory Access Protocol (LDAP), the Network Information Service (NIS), /etc/hosts, or some other means. If the netloc4 is of type NL4_URL, a server URL [RFC3986] appropriate for the server-to-server COPY operation is specified as a UTF-8 string. If the netloc4 is of type NL4_NETADDR, the nl_addr field MUST contain a valid netaddr4 as defined in Section 3.3.9 of [RFC5661].
如果netloc4的类型为NL4_NAME，则必须将nl_NAME字段指定为UTF-8字符串。nl_名称应通过DNS、轻型目录访问协议（LDAP）、网络信息服务（NIS）、/etc/hosts或其他方式解析为网络地址。如果netloc4为NL4_URL类型，则适用于服务器到服务器复制操作的服务器URL[RFC3986]被指定为UTF-8字符串。如果netloc4为NL4_NetAddress类型，则nl_addr字段必须包含[RFC5661]第3.3.9节中定义的有效NetAddress4。
When netloc4 values are used for an inter-server copy as shown in Figure 3, their values may be evaluated on the source server, destination server, and client. The network environment in which these systems operate should be configured so that the netloc4 values are interpreted as intended on each system.
如图3所示，当netloc4值用于服务器间副本时，可以在源服务器、目标服务器和客户机上评估它们的值。应对这些系统运行的网络环境进行配置，以便将netloc4值解释为每个系统上的预期值。
A server may perform a copy offload operation asynchronously. An asynchronous copy is tracked using a copy offload stateid. Copy offload stateids are included in the COPY, OFFLOAD_CANCEL, OFFLOAD_STATUS, and CB_OFFLOAD operations.
服务器可以异步执行拷贝卸载操作。使用拷贝卸载状态ID跟踪异步拷贝。复制卸载状态ID包括在复制、卸载取消、卸载状态和CB卸载操作中。
A copy offload stateid will be valid until either (A) the client or server restarts or (B) the client returns the resource by issuing an OFFLOAD_CANCEL operation or the client replies to a CB_OFFLOAD operation.
拷贝卸载stateid将一直有效，直到（A）客户端或服务器重新启动，或者（B）客户端通过发出卸载\u取消操作返回资源，或者客户端回复CB\u卸载操作。
A copy offload stateid's seqid MUST NOT be zero. In the context of a copy offload operation, it is inappropriate to indicate "the most recent copy offload operation" using a stateid with a seqid of zero (see Section 8.2.2 of [RFC5661]). It is inappropriate because the stateid refers to internal state in the server and there may be several asynchronous COPY operations being performed in parallel on the same file by the server. Therefore, a copy offload stateid with a seqid of zero MUST be considered invalid.
副本卸载stateid的seqid不能为零。在副本卸载操作的上下文中，使用seqid为零的stateid表示“最近的副本卸载操作”是不合适的（请参见[RFC5661]第8.2.2节）。这是不合适的，因为stateid引用服务器中的内部状态，并且服务器可能会对同一文件并行执行多个异步复制操作。因此，seqid为零的副本卸载stateid必须视为无效。
All security considerations pertaining to NFSv4.1 [RFC5661] apply to this section; as such, the standard security mechanisms used by the protocol can be used to secure the server-to-server operations.
与NFSv4.1[RFC5661]相关的所有安全注意事项适用于本节；因此，协议使用的标准安全机制可用于保护服务器到服务器的操作。
NFSv4 clients and servers supporting the inter-server COPY operations described in this section are REQUIRED to implement the mechanism described in Section 4.9.1.1 and to support rejecting COPY_NOTIFY requests that do not use the RPC security protocol (RPCSEC_GSS) [RFC7861] with privacy. If the server-to-server copy protocol is based on ONC RPC, the servers are also REQUIRED to implement [RFC7861], including the RPCSEC_GSSv3 "copy_to_auth", "copy_from_auth", and "copy_confirm_auth" structured privileges. This requirement to implement is not a requirement to use; for example, a server may, depending on configuration, also allow COPY_NOTIFY requests that use only AUTH_SYS.
支持本节所述服务器间复制操作的NFSv4客户端和服务器需要实现第4.9.1.1节所述的机制，并支持拒绝不使用RPC安全协议（RPCSEC_GSS）[RFC7861]且具有隐私的复制通知请求。如果服务器到服务器复制协议基于ONC-RPC，则服务器还需要实现[RFC7861]，包括RPCSEC_GSSv3“复制到_-auth”、“复制自_-auth”和“复制确认_-auth”结构化权限。该实施要求不是使用要求；例如，根据配置，服务器可能还允许仅使用AUTH_SYS的COPY_NOTIFY请求。
If a server requires the use of an RPCSEC_GSSv3 copy_to_auth, copy_from_auth, or copy_confirm_auth privilege and it is not used, the server will reject the request with NFS4ERR_PARTNER_NO_AUTH.
如果服务器需要使用RPCSEC\u GSSv3 copy\u to\u auth、copy\u from\u auth或copy\u confirm\u auth权限，但未使用该权限，则服务器将使用NFS4ERR\u PARTNER\u NO\u auth拒绝该请求。
When the client sends a COPY_NOTIFY to the source server to expect the destination to attempt to copy data from the source server, it is expected that this copy is being done on behalf of the principal (called the "user principal") that sent the RPC request that encloses the COMPOUND procedure that contains the COPY_NOTIFY operation. The user principal is identified by the RPC credentials. A mechanism that allows the user principal to authorize the destination server to perform the copy, lets the source server properly authenticate the destination's copy, and does not allow the destination server to exceed this authorization is necessary.
当客户端向源服务器发送复制通知以期望目标尝试从源服务器复制数据时，该复制应代表发送RPC请求的主体（称为“用户主体”）完成，该RPC请求包含包含复制通知操作的复合过程。用户主体由RPC凭据标识。需要一种机制，允许用户主体授权目标服务器执行复制，允许源服务器正确验证目标的副本，并且不允许目标服务器超出此授权。
An approach that sends delegated credentials of the client's user principal to the destination server is not used for the following reason. If the client's user delegated its credentials, the destination would authenticate as the user principal. If the destination were using the NFSv4 protocol to perform the copy, then the source server would authenticate the destination server as the user principal, and the file copy would securely proceed. However, this approach would allow the destination server to copy other files. The user principal would have to trust the destination server to not do so. This is counter to the requirements and therefore is not considered.
由于以下原因，不使用将客户端用户主体的委派凭据发送到目标服务器的方法。如果客户端的用户委派了其凭据，则目标将作为用户主体进行身份验证。如果目标使用NFSv4协议执行复制，那么源服务器将验证目标服务器作为用户主体，并且文件复制将安全地进行。但是，这种方法允许目标服务器复制其他文件。用户主体必须信任目标服务器才能这样做。这与要求背道而驰，因此不予考虑。
Instead, a feature of the RPCSEC_GSSv3 protocol [RFC7861] can be used: RPC-application-defined structured privilege assertion. This feature allows the destination server to authenticate to the source server as acting on behalf of the user principal and to authorize the destination server to perform READs of the file to be copied from the source on behalf of the user principal. Once the copy is complete, the client can destroy the RPCSEC_GSSv3 handles to end the authorization of both the source and destination servers to copy.
相反，可以使用RPCSEC_GSSv3协议[RFC7861]的一个特性：RPC应用程序定义的结构化特权断言。此功能允许目标服务器代表用户主体向源服务器进行身份验证，并授权目标服务器代表用户主体从源服务器读取要复制的文件。复制完成后，客户端可以销毁RPCSEC_GSSv3句柄，以结束源服务器和目标服务器的复制授权。
For each structured privilege assertion defined by an RPC application, RPCSEC_GSSv3 requires the application to define a name string and a data structure that will be encoded and passed between client and server as opaque data. For NFSv4, the data structures specified below MUST be serialized using XDR.
对于RPC应用程序定义的每个结构化特权断言，RPCSEC_GSSv3要求应用程序定义一个名称字符串和一个数据结构，该名称字符串和数据结构将被编码并作为不透明数据在客户端和服务器之间传递。对于NFSv4，下面指定的数据结构必须使用XDR序列化。
Three RPCSEC_GSSv3 structured privilege assertions that work together to authorize the copy are defined here. For each of the assertions, the description starts with the name string passed in the rp_name field of the rgss3_privs structure defined in Section 2.7.1.4 of [RFC7861] and specifies the XDR encoding of the associated structured data passed via the rp_privilege field of the structure.
这里定义了三个RPCSEC_GSSv3结构化权限断言，它们共同工作以授权副本。对于每个断言，描述从[RFC7861]第2.7.1.4节中定义的rgss3_privs结构的rp_name字段中传递的名称字符串开始，并指定通过结构的rp_privilege字段传递的关联结构化数据的XDR编码。
copy_from_auth: A user principal is authorizing a source principal ("nfs@<source>") to allow a destination principal ("nfs@<destination>") to set up the copy_confirm_auth privilege required to copy a file from the source to the destination on behalf of the user principal. This privilege is established on the source server before the user principal sends a COPY_NOTIFY operation to the source server, and the resultant RPCSEC_GSSv3 context is used to secure the COPY_NOTIFY operation.
copy_from_auth：用户主体正在授权源主体（“nfs@<source>”）以允许目标主体（“nfs@<destination>”）代表用户主体设置将文件从源复制到目标所需的copy_confirm_auth权限。在用户主体向源服务器发送复制通知操作之前，在源服务器上建立此权限，并使用生成的RPCSEC_GSSv3上下文保护复制通知操作。
<CODE BEGINS>
<代码开始>
struct copy_from_auth_priv {
secret4 cfap_shared_secret;
netloc4 cfap_destination;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed cfap_username;
};
struct copy_from_auth_priv {
secret4 cfap_shared_secret;
netloc4 cfap_destination;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed cfap_username;
};
<CODE ENDS>
<代码结束>
cfap_shared_secret is an automatically generated random number secret value.
cfap_shared_secret是自动生成的随机数秘密值。
copy_to_auth: A user principal is authorizing a destination principal ("nfs@<destination>") to set up a copy_confirm_auth privilege with a source principal ("nfs@<source>") to allow it to copy a file from the source to the destination on behalf of the user principal. This privilege is established on the destination server before the user principal sends a COPY operation to the destination server, and the resultant RPCSEC_GSSv3 context is used to secure the COPY operation.
复制到身份验证：用户主体正在授权目标主体（“nfs@<destination>”）使用源主体（“nfs@<source>”）设置复制确认身份验证权限，以允许其代表用户主体将文件从源复制到目标。在用户主体向目标服务器发送复制操作之前，在目标服务器上建立此权限，并使用生成的RPCSEC_GSSv3上下文保护复制操作。
<CODE BEGINS>
<代码开始>
struct copy_to_auth_priv {
/* equal to cfap_shared_secret */
secret4 ctap_shared_secret;
netloc4 ctap_source<>;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ctap_username;
};
struct copy_to_auth_priv {
/* equal to cfap_shared_secret */
secret4 ctap_shared_secret;
netloc4 ctap_source<>;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ctap_username;
};
<CODE ENDS>
<代码结束>
ctap_shared_secret is the automatically generated secret value used to establish the copy_from_auth privilege with the source principal. See Section 4.9.1.1.1.
ctap_shared_secret是自动生成的机密值，用于与源主体建立“从_复制”身份验证权限。见第4.9.1.1.1节。
copy_confirm_auth: A destination principal ("nfs@<destination>") is confirming with the source principal ("nfs@<source>") that it is authorized to copy data from the source. This privilege is established on the destination server before the file is copied from the source to the destination. The resultant RPCSEC_GSSv3 context is used to secure the READ operations from the source to the destination server.
copy_confirm_auth：目标主体（“nfs@<destination>”）正在与源主体（“nfs@<source>”）确认其有权从源复制数据。在将文件从源复制到目标之前，在目标服务器上建立此权限。生成的RPCSEC_GSSv3上下文用于保护从源服务器到目标服务器的读取操作。
<CODE BEGINS>
<代码开始>
struct copy_confirm_auth_priv {
/* equal to GSS_GetMIC() of cfap_shared_secret */
opaque ccap_shared_secret_mic<>;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ccap_username;
};
struct copy_confirm_auth_priv {
/* equal to GSS_GetMIC() of cfap_shared_secret */
opaque ccap_shared_secret_mic<>;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ccap_username;
};
<CODE ENDS>
<代码结束>
When the user principal wants to copy a file between two servers, if it has not established copy_from_auth and copy_to_auth privileges on the servers, it establishes them as follows:
当用户主体希望在两台服务器之间复制文件时，如果它没有在服务器上建立“从\u auth复制\u”和“复制\u到\u auth”权限，则它将按如下方式建立这些权限：
o As noted in [RFC7861], the client uses an existing RPCSEC_GSSv3 context termed the "parent" handle to establish and protect RPCSEC_GSSv3 structured privilege assertion exchanges. The copy_from_auth privilege will use the context established between the user principal and the source server used to OPEN the source file as the RPCSEC_GSSv3 parent handle. The copy_to_auth privilege will use the context established between the user principal and the destination server used to OPEN the destination file as the RPCSEC_GSSv3 parent handle.
o 如[RFC7861]中所述，客户机使用称为“父”句柄的现有RPCSEC_GSSv3上下文来建立和保护RPCSEC_GSSv3结构化权限断言交换。copy_from_auth权限将使用在用户主体和用于打开源文件的源服务器之间建立的上下文作为RPCSEC_GSSv3父句柄。copy_to_auth权限将使用在用户主体和用于打开目标文件的目标服务器之间建立的上下文作为RPCSEC_GSSv3父句柄。
o A random number is generated to use as a secret to be shared between the two servers. Note that the random number SHOULD NOT be reused between establishing different security contexts. The resulting shared secret will be placed in the copy_from_auth_priv cfap_shared_secret field and the copy_to_auth_priv ctap_shared_secret field. Because of this shared_secret, the RPCSEC_GSS3_CREATE control messages for copy_from_auth and copy_to_auth MUST use a Quality of Protection (QoP) of rpc_gss_svc_privacy.
o 生成一个随机数，用作两台服务器之间共享的秘密。请注意，不应在建立不同安全上下文之间重复使用随机数。生成的共享机密将被放置在“复制自授权私有cfap共享机密”字段和“复制至授权私有ctap共享机密”字段中。由于此共享密钥，RPCSEC_GSS3_为从_auth复制_和复制_到_auth创建的控制消息必须使用rpc_gss_svc_隐私的保护质量（QoP）。
o An instance of copy_from_auth_priv is filled in with the shared secret, the destination server, and the NFSv4 user id of the user principal and is placed in rpc_gss3_create_args assertions[0].privs.privilege. The string "copy_from_auth" is placed in assertions[0].privs.name. The source server unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload and verifies that the NFSv4 user id being asserted matches the source server's mapping of the user principal. If it does, the privilege is established on the source server as <copy_from_auth, user id, destination>. The field "handle" in a successful reply is the RPCSEC_GSSv3 copy_from_auth "child" handle that the client will use in COPY_NOTIFY requests to the source server.
o 来自_auth_priv的copy_实例由共享机密、目标服务器和用户主体的NFSv4用户id填充，并放置在rpc_gss3_create_args断言[0].privs.privilege中。字符串“copy_from_auth”位于断言[0].privs.name中。源服务器打开rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload并验证所断言的NFSv4用户id是否与源服务器的用户主体映射匹配。如果是，则在源服务器上建立权限为<copy\u from\u auth，user id，destination>。成功回复中的字段“句柄”是RPCSEC_GSSv3 copy_from_auth“child”句柄，客户端将在对源服务器的复制通知请求中使用该句柄。
o An instance of copy_to_auth_priv is filled in with the shared secret, the cnr_source_server list returned by COPY_NOTIFY, and the NFSv4 user id of the user principal. The copy_to_auth_priv instance is placed in rpc_gss3_create_args assertions[0].privs.privilege. The string "copy_to_auth" is placed in assertions[0].privs.name. The destination server unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload and verifies that the NFSv4 user id being asserted matches the destination server's mapping of the user principal. If it does, the privilege is established on the destination server as <copy_to_auth, user id, source list>. The field "handle" in a successful reply is the RPCSEC_GSSv3 copy_to_auth child handle that the client will use in COPY requests to the destination server involving the source server.
o copy_to_auth_priv的实例中填写了共享机密、copy_NOTIFY返回的cnr_source_服务器列表以及用户主体的NFSv4用户id。“复制到”auth“priv实例放置在rpc\u gss3\u create\u args断言[0].privs.privilege中。字符串“copy_to_auth”位于断言[0].privs.name中。目标服务器打开rpc_gss_svc_privacy RPCSEC_GSS3_CREATE负载，并验证所断言的NFSv4用户id是否与目标服务器的用户主体映射匹配。如果是，则在目标服务器上建立权限为<copy\u to\u auth，user id，source list>。成功回复中的字段“handle”是RPCSEC_GSSv3 copy_to_auth子句柄，客户端将在涉及源服务器的目标服务器的复制请求中使用该子句柄。
As noted in Section 2.7.1 of [RFC7861] ("New Control Procedure - RPCSEC_GSS_CREATE"), both the client and the source server should associate the RPCSEC_GSSv3 child handle with the parent RPCSEC_GSSv3 handle used to create the RPCSEC_GSSv3 child handle.
如[RFC7861]（“新控制程序-RPCSEC_GSS_CREATE”）第2.7.1节所述，客户端和源服务器都应将RPCSEC_GSSv3子句柄与用于创建RPCSEC_GSSv3子句柄的父RPCSEC_GSSv3句柄相关联。
When the client sends a COPY_NOTIFY request to the source server, it uses the privileged copy_from_auth RPCSEC_GSSv3 handle. cna_destination_server in the COPY_NOTIFY MUST be the same as cfap_destination specified in copy_from_auth_priv. Otherwise, the COPY_NOTIFY will fail with NFS4ERR_ACCESS. The source server verifies that the privilege <copy_from_auth, user id, destination> exists and annotates it with the source filehandle, if the user principal has read access to the source file and if administrative policies give the user principal and the NFS client read access to the source file (i.e., if the ACCESS operation would grant read access). Otherwise, the COPY_NOTIFY will fail with NFS4ERR_ACCESS.
当客户端向源服务器发送复制通知请求时，它使用来自\u auth RPCSEC\u GSSv3句柄的特权复制通知。复制通知中的cna\u目的地\u服务器必须与从\u auth\u priv复制通知中指定的cfap\u目的地相同。否则，复制通知将失败，NFS4ERR\u访问失败。如果用户主体具有对源文件的读取权限，并且管理策略授予用户主体和NFS客户端对源文件的读取权限，则源服务器将验证权限<copy\u from\u auth，user id，destination>是否存在，并使用源文件句柄对其进行注释（即，如果访问操作将授予读取访问权）。否则，复制通知将失败，NFS4ERR\U访问将失败。
When the client sends a COPY request to the destination server, it uses the privileged copy_to_auth RPCSEC_GSSv3 handle. ca_source_server list in the COPY MUST be the same as ctap_source list specified in copy_to_auth_priv. Otherwise, the COPY will fail with NFS4ERR_ACCESS. The destination server verifies that the privilege <copy_to_auth, user id, source list> exists and annotates it with the source and destination filehandles. If the COPY returns a wr_callback_id, then this is an asynchronous copy and the wr_callback_id must also must be annotated to the copy_to_auth privilege. If the client has failed to establish the copy_to_auth privilege, it will reject the request with NFS4ERR_PARTNER_NO_AUTH.
当客户端向目标服务器发送复制请求时，它将使用特权的COPY_to_auth RPCSEC_GSSv3句柄。副本中的ca_source_服务器列表必须与COPY_to_auth_priv中指定的ctap_source列表相同。否则，副本将因NFS4ERR_访问而失败。目标服务器验证权限<copy\u to\u auth，user id，source list>是否存在，并用源和目标文件句柄对其进行注释。如果副本返回wr_callback_id，则这是一个异步副本，并且wr_callback_id还必须注释到COPY_to_auth权限。如果客户端未能建立复制到身份验证权限，它将使用NFS4ERR\u PARTNER\u NO\u auth拒绝请求。
If either the COPY_NOTIFY operation or the COPY operations fail, the associated copy_from_auth and copy_to_auth RPCSEC_GSSv3 handles MUST be destroyed.
如果COPY_NOTIFY操作或COPY操作失败，则必须销毁关联的COPY_from_auth和COPY_to_auth RPCSEC_GSSv3句柄。
After a destination server has a copy_to_auth privilege established on it and it receives a COPY request, if it knows it will use an ONC RPC protocol to copy data, it will establish a copy_confirm_auth privilege on the source server prior to responding to the COPY operation, as follows:
目标服务器在其上建立了copy_to_auth权限并接收到复制请求后，如果它知道将使用ONC RPC协议复制数据，它将在响应复制操作之前在源服务器上建立copy_confirm_auth权限，如下所示：
o Before establishing an RPCSEC_GSSv3 context, a parent context needs to exist between nfs@<destination> as the initiator principal and nfs@<source> as the target principal. If NFS is to be used as the copy protocol, this means that the destination server must mount the source server using RPCSEC_GSSv3.
o 在建立RPCSEC_GSSv3上下文之前，父上下文需要存在于作为启动器主体的nfs@<destination>和作为目标主体的nfs@<source>之间。如果要将NFS用作复制协议，这意味着目标服务器必须使用RPCSEC_GSSv3装载源服务器。
o An instance of copy_confirm_auth_priv is filled in with information from the established copy_to_auth privilege. The value of the ccap_shared_secret_mic field is a GSS_GetMIC() of the ctap_shared_secret in the copy_to_auth privilege using the parent handle context. The ccap_username field is the mapping of the user principal to an NFSv4 user name ("user"@"domain" form) and MUST be the same as the ctap_username in the copy_to_auth privilege. The copy_confirm_auth_priv instance is placed in rpc_gss3_create_args assertions[0].privs.privilege. The string "copy_confirm_auth" is placed in assertions[0].privs.name.
o copy_confirm_auth_priv的实例中填充了已建立的copy_to_auth权限中的信息。ccap_shared_secret_mic字段的值是使用父句柄上下文的copy_to_auth权限中ctap_shared_secret的GSS_GetMIC（）。ccap_用户名字段是用户主体到NFSv4用户名（“用户”@“域”形式）的映射，并且必须与复制到身份验证权限中的ctap_用户名相同。copy_confirm_auth_priv实例放置在rpc_gss3_create_args断言[0].privs.privilege中。字符串“copy\u confirm\u auth”位于断言[0].privs.name中。
o The RPCSEC_GSS3_CREATE copy_from_auth message is sent to the source server with a QoP of rpc_gss_svc_privacy. The source server unwraps the rpc_gss_svc_privacy RPCSEC_GSS3_CREATE payload and verifies the cap_shared_secret_mic by calling GSS_VerifyMIC() using the parent context on the cfap_shared_secret from the established copy_from_auth privilege, and verifies that the ccap_username equals the cfap_username.
o RPCSEC_GSS3_CREATE copy_from_auth消息以rpc_gss_svc_privacy的QoP发送到源服务器。源服务器打开rpc_gss_svc_privacy RPCSEC_GSS3_CREATE有效负载，并通过使用cfap_shared_secret上的父上下文从已建立的copy_from_auth权限调用gss_VerifyMIC（）来验证cap_shared_secret，并验证ccap_用户名是否等于cfap_用户名。
o If all verifications succeed, the copy_confirm_auth privilege is established on the source server as <copy_confirm_auth, shared_secret_mic, user id>. Because the shared secret has been verified, the resultant copy_confirm_auth RPCSEC_GSSv3 child handle is noted to be acting on behalf of the user principal.
o 如果所有验证都成功，则在源服务器上建立复制确认身份验证权限，即<copy\u confirm\u auth，shared\u secret\u mic，user id>。由于共享机密已被验证，因此生成的copy_confirm_auth RPCSEC_GSSv3子句柄将代表用户主体。
o If the source server fails to verify the copy_from_auth privilege, the COPY_NOTIFY operation will be rejected with NFS4ERR_PARTNER_NO_AUTH.
o 如果源服务器无法验证“从授权复制”权限，则“复制通知”操作将被NFS4ERR\u PARTNER\u NO\u auth拒绝。
o If the destination server fails to verify the copy_to_auth or copy_confirm_auth privilege, the COPY will be rejected with NFS4ERR_PARTNER_NO_AUTH, causing the client to destroy the associated copy_from_auth and copy_to_auth RPCSEC_GSSv3 structured privilege assertion handles.
o 如果目标服务器未能验证“复制到”身份验证或“复制确认”身份验证权限，则将使用NFS4ERR\u PARTNER\u NO\u auth拒绝该副本，从而导致客户端销毁与“从”身份验证和“复制到”身份验证相关联的副本RPCSEC\u GSSv3结构化权限断言句柄。
o All subsequent ONC RPC READ requests sent from the destination to copy data from the source to the destination will use the RPCSEC_GSSv3 copy_confirm_auth child handle.
o 从目标发送的所有后续ONC RPC读取请求（用于将数据从源复制到目标）都将使用RPCSEC_GSSv3 copy_confirm_auth子句柄。
Note that the use of the copy_confirm_auth privilege accomplishes the following:
请注意，使用copy_confirm_auth权限可实现以下功能：
o If a protocol like NFS is being used with export policies, the export policies can be overridden if the destination server is not authorized to act as an NFS client.
o 如果将NFS之类的协议与导出策略一起使用，则如果目标服务器未被授权作为NFS客户端，则可以覆盖导出策略。
o Manual configuration to allow a copy relationship between the source and destination is not needed.
o 不需要手动配置以允许源和目标之间的复制关系。
If the client determines that either the copy_from_auth or the copy_to_auth handle becomes invalid during a copy, then the copy MUST be aborted by the client sending an OFFLOAD_CANCEL to both the source and destination servers and destroying the respective copy-related context handles as described in Section 4.9.1.1.5.
如果客户端在复制过程中确定“从\u验证复制”或“从\u验证复制”句柄无效，则必须通过客户端向源服务器和目标服务器发送“卸载\u取消”并销毁第4.9.1.1.5节所述的相应复制相关上下文句柄来中止复制。
Under normal operation, the client MUST destroy the copy_from_auth and the copy_to_auth RPCSEC_GSSv3 handle once the COPY operation returns for a synchronous inter-server copy or a CB_OFFLOAD reports the result of an asynchronous copy.
在正常操作下，一旦复制操作返回同步服务器间复制或CB_卸载报告异步复制的结果，客户端必须销毁来自_auth的复制和到_auth的复制RPCSEC_GSSv3句柄。
The copy_confirm_auth privilege is constructed from information held by the copy_to_auth privilege and MUST be destroyed by the destination server (via an RPCSEC_GSS3_DESTROY call) when the copy_to_auth RPCSEC_GSSv3 handle is destroyed.
copy_confirm_auth权限是根据copy_to_auth权限持有的信息构造的，当copy_to_auth RPCSEC_GSSv3句柄被销毁时，目标服务器必须（通过RPCSEC_GSS3_DESTROY调用）销毁该权限。
The copy_confirm_auth RPCSEC_GSS3 handle is associated with a copy_from_auth RPCSEC_GSS3 handle on the source server via the shared secret and MUST be locally destroyed (there is no RPCSEC_GSS3_DESTROY, as the source server is not the initiator) when the copy_from_auth RPCSEC_GSSv3 handle is destroyed.
copy_confirm_auth RPCSEC_GSS3句柄通过共享机密与源服务器上的副本_auth RPCSEC_GSS3句柄相关联，并且在销毁来自\u auth RPCSEC_GSSv3句柄的副本时，必须在本地销毁该句柄（不存在RPCSEC_GSS3_销毁，因为源服务器不是启动器）。
If the client sends an OFFLOAD_CANCEL to the source server to rescind the destination server's synchronous copy privilege, it uses the privileged copy_from_auth RPCSEC_GSSv3 handle, and the cra_destination_server in the OFFLOAD_CANCEL MUST be the same as the name of the destination server specified in copy_from_auth_priv. The source server will then delete the <copy_from_auth, user id, destination> privilege and fail any subsequent copy requests sent under the auspices of this privilege from the destination server. The client MUST destroy both the copy_from_auth and the copy_to_auth RPCSEC_GSSv3 handles.
如果客户端向源服务器发送卸载\u取消以取消目标服务器的同步复制权限，它将使用来自\u auth RPCSEC\u GSSv3句柄的特权复制\u，卸载\u取消中的cra\u目标\u服务器必须与从\u auth\u priv复制\u中指定的目标服务器的名称相同。然后，源服务器将删除<copy\u from\u auth，user id，destination>权限，并使在该权限下从目标服务器发送的任何后续复制请求失败。客户端必须同时销毁从\u auth复制的\u和到\u auth复制的\u RPCSEC\u GSSv3句柄。
If the client sends an OFFLOAD_STATUS to the destination server to check on the status of an asynchronous copy, it uses the privileged copy_to_auth RPCSEC_GSSv3 handle, and the osa_stateid in the OFFLOAD_STATUS MUST be the same as the wr_callback_id specified in the copy_to_auth privilege stored on the destination server.
如果客户端向目标服务器发送卸载状态以检查异步复制的状态，则它将使用特权复制授权RPCSEC\u GSSv3句柄，并且卸载状态下的osa\u stateid必须与存储在目标服务器上的复制授权特权中指定的wr\u callback\u id相同。
If the client sends an OFFLOAD_CANCEL to the destination server to cancel an asynchronous copy, it uses the privileged copy_to_auth RPCSEC_GSSv3 handle, and the oaa_stateid in the OFFLOAD_CANCEL MUST be the same as the wr_callback_id specified in the copy_to_auth privilege stored on the destination server. The destination server will then delete the <copy_to_auth, user id, source list> privilege and the associated copy_confirm_auth RPCSEC_GSSv3 handle. The client MUST destroy both the copy_to_auth and copy_from_auth RPCSEC_GSSv3 handles.
如果客户端向目标服务器发送卸载\u取消以取消异步复制，它将使用特权复制\u到\u身份验证RPCSEC\u GSSv3句柄，卸载\u取消中的oaa\u stateid必须与存储在目标服务器上的复制\u到\u身份验证特权中指定的wr\u回调\u id相同。然后，目标服务器将删除<copy_to_auth，user id，source list>权限和关联的copy_confirm_auth RPCSEC_GSSv3句柄。客户端必须销毁复制到授权和复制自授权RPCSEC GSSv3句柄。
ONC RPC security flavors other than RPCSEC_GSS MAY be used with the server-side copy offload operations described in this section. In particular, host-based ONC RPC security flavors such as AUTH_NONE and AUTH_SYS MAY be used. If a host-based security flavor is used, a minimal level of protection for the server-to-server copy protocol is possible.
除了RPCSEC_GSS之外的ONC-RPC安全风格可用于本节所述的服务器端拷贝卸载操作。特别是，可以使用基于主机的ONC-RPC安全风格，例如AUTH_-NONE和AUTH_-SYS。如果使用基于主机的安全特性，则可以对服务器到服务器复制协议提供最低级别的保护。
The biggest issue is that there is a lack of a strong security method to allow the source server and destination server to identify themselves to each other. A further complication is that in a multihomed environment the destination server might not contact the source server from the same network address specified by the client in the COPY_NOTIFY. The cnr_stateid returned from the COPY_NOTIFY can be used to uniquely identify the destination server to the source server. The use of the cnr_stateid provides initial authentication of the destination server but cannot defend against man-in-the-middle attacks after authentication or against an eavesdropper that observes the opaque stateid on the wire. Other secure communication techniques (e.g., IPsec) are necessary to block these attacks.
最大的问题是，缺乏一种强大的安全方法来允许源服务器和目标服务器相互标识自己。另一个复杂情况是，在多主机环境中，目标服务器可能无法从复制通知中客户端指定的相同网络地址与源服务器联系。从COPY_NOTIFY返回的cnr_stateid可用于唯一标识源服务器的目标服务器。cnr_stateid的使用提供了目标服务器的初始身份验证，但无法抵御身份验证后的中间人攻击，也无法抵御观察到线路上不透明stateid的窃听者。其他安全通信技术（如IPsec）是阻止这些攻击所必需的。
Servers SHOULD reject COPY_NOTIFY requests that do not use RPCSEC_GSS with privacy, thus ensuring that the cnr_stateid in the COPY_NOTIFY reply is encrypted. For the same reason, clients SHOULD send COPY requests to the destination using RPCSEC_GSS with privacy.
服务器应拒绝不使用带有隐私的RPCSEC GSS的COPY_NOTIFY请求，从而确保COPY_NOTIFY回复中的cnr_stateid是加密的。出于同样的原因，客户端应使用带有隐私的RPCSEC_GSS将复制请求发送到目标。
Applications can issue client I/O hints via posix_fadvise() [posix_fadvise] to the NFS client. While this can help the NFS client optimize I/O and caching for a file, it does not allow the NFS server and its exported file system to do likewise. The IO_ADVISE procedure (Section 15.5) is used to communicate the client file access patterns to the NFS server. The NFS server, upon receiving an IO_ADVISE operation, MAY choose to alter its I/O and caching behavior but is under no obligation to do so.
应用程序可以通过posix_fadvise（）[posix_fadvise]向NFS客户端发出客户端I/O提示。虽然这可以帮助NFS客户端优化文件的I/O和缓存，但它不允许NFS服务器及其导出的文件系统也这样做。IO_ADVISE过程（第15.5节）用于将客户端文件访问模式传送到NFS服务器。NFS服务器在收到IO_advice操作后，可以选择更改其I/O和缓存行为，但没有义务这样做。
Application-specific NFS clients such as those used by hypervisors and databases can also leverage application hints to communicate their specialized requirements.
特定于应用程序的NFS客户端（如虚拟机监控程序和数据库使用的客户端）也可以利用应用程序提示来传达其特定需求。
A sparse file is a common way of representing a large file without having to utilize all of the disk space for it. Consequently, a sparse file uses less physical space than its size indicates. This means the file contains "holes", byte ranges within the file that contain no data. Most modern file systems support sparse files, including most UNIX file systems and Microsoft's New Technology File System (NTFS); however, it should be noted that Apple's Hierarchical File System Plus (HFS+) does not. Common examples of sparse files include Virtual Machine (VM) OS/disk images, database files, log files, and even checkpoint recovery files most commonly used by the High-Performance Computing (HPC) community.
稀疏文件是一种表示大文件的常用方法，而不必为其利用所有磁盘空间。因此，稀疏文件使用的物理空间比其大小指示的要少。这意味着文件包含“孔”，即文件中不包含数据的字节范围。大多数现代文件系统支持稀疏文件，包括大多数UNIX文件系统和Microsoft的新技术文件系统（NTFS）；然而，应该注意的是，苹果的分级文件系统升级版（HFS+）没有。稀疏文件的常见示例包括虚拟机（VM）操作系统/磁盘映像、数据库文件、日志文件，甚至是高性能计算（HPC）社区最常用的检查点恢复文件。
In addition, many modern file systems support the concept of "unwritten" or "uninitialized" blocks, which have uninitialized space allocated to them on disk but will return zeros until data is written to them. Such functionality is already present in the data model of the pNFS block/volume layout (see [RFC5663]). Uninitialized blocks can be thought of as holes inside a space reservation window.
此外，许多现代文件系统支持“未写入”或“未初始化”块的概念，这些块在磁盘上分配有未初始化的空间，但在数据写入之前将返回零。pNFS块/卷布局的数据模型中已经存在此类功能（请参见[RFC5663]）。未初始化的块可以视为空间保留窗口内的孔。
If an application reads a hole in a sparse file, the file system must return all zeros to the application. For local data access there is little penalty, but with NFS these zeros must be transferred back to the client. If an application uses the NFS client to read data into memory, this wastes time and bandwidth as the application waits for the zeros to be transferred.
如果应用程序读取稀疏文件中的孔，文件系统必须将所有零返回给应用程序。对于本地数据访问，惩罚很小，但对于NFS，这些零必须传输回客户端。如果应用程序使用NFS客户端将数据读取到内存中，则在应用程序等待传输零时会浪费时间和带宽。
A sparse file is typically created by initializing the file to be all zeros. Nothing is written to the data in the file; instead, the hole is recorded in the metadata for the file. So, an 8G disk image might be represented initially by a few hundred bits in the metadata (on UNIX file systems, the inode) and nothing on the disk. If the VM then writes 100M to a file in the middle of the image, there would now be two holes represented in the metadata and 100M in the data.
稀疏文件通常通过将文件初始化为全零来创建。不向文件中的数据写入任何内容；相反，该孔记录在文件的元数据中。因此，8G磁盘映像最初可能由元数据中的几百位（在UNIX文件系统上，inode）表示，而磁盘上没有任何内容。如果VM然后将100M写入图像中间的一个文件中，那么现在在元数据中表示两个孔，并且在数据中有100M。
No new operation is needed to allow the creation of a sparsely populated file; when a file is created and a write occurs past the current size of the file, the non-allocated region will either be a hole or be filled with zeros. The choice of behavior is dictated by the underlying file system and is transparent to the application. However, the abilities to read sparse files and to punch holes to reinitialize the contents of a file are needed.
无需新操作即可创建填充稀疏的文件；当创建文件且写入超过文件的当前大小时，未分配的区域将是一个孔或用零填充。行为的选择由底层文件系统决定，并且对应用程序是透明的。但是，需要具备读取稀疏文件和打孔以重新初始化文件内容的能力。
Two new operations -- DEALLOCATE (Section 15.4) and READ_PLUS (Section 15.10) -- are introduced. DEALLOCATE allows for the hole punching, where an application might want to reset the allocation and reservation status of a range of the file. READ_PLUS supports all the features of READ but includes an extension to support sparse files. READ_PLUS is guaranteed to perform no worse than READ and can dramatically improve performance with sparse files. READ_PLUS does not depend on pNFS protocol features but can be used by pNFS to support sparse files.
引入了两个新的操作——释放（第15.4节）和读取（第15.10节）。释放允许打孔，应用程序可能希望重置文件范围的分配和保留状态。READ_PLUS支持READ的所有功能，但包含支持稀疏文件的扩展。READ_PLUS的性能保证不会比READ差，并且可以显著提高稀疏文件的性能。READ_PLUS不依赖于pNFS协议功能，但可由pNFS用于支持稀疏文件。
Regular file: An object of file type NF4REG or NF4NAMEDATTR.
常规文件：文件类型为NF4REG或NF4NAMEDATTR的对象。
Sparse file: A regular file that contains one or more holes.
稀疏文件：包含一个或多个孔的常规文件。
Hole: A byte range within a sparse file that contains all zeros. A hole might or might not have space allocated or reserved to it.
空洞：稀疏文件中包含所有零的字节范围。孔可能有也可能没有为其分配或保留空间。
READ_PLUS is a new variant of the NFSv4.1 READ operation [RFC5661]. Besides being able to support all of the data semantics of the READ operation, it can also be used by the client and server to efficiently transfer holes. Because the client does not know in advance whether a hole is present or not, if the client supports READ_PLUS and so does the server, then it should always use the READ_PLUS operation in preference to the READ operation.
READ_PLUS是NFSv4.1读取操作[RFC5661]的新变体。除了能够支持读取操作的所有数据语义外，客户端和服务器还可以使用它来高效地传输漏洞。因为客户端事先不知道是否存在漏洞，如果客户端支持READ_PLUS，服务器也支持READ_PLUS，那么它应该始终优先使用READ_PLUS操作而不是READ操作。
READ_PLUS extends the response with a new arm representing holes to avoid returning data for portions of the file that are initialized to zero and may or may not contain a backing store. Returning actual data blocks corresponding to holes wastes computational and network resources, thus reducing performance.
READ_PLUS使用表示孔的新arm扩展响应，以避免返回文件中初始化为零的部分的数据，这些部分可能包含也可能不包含备份存储。返回与孔对应的实际数据块会浪费计算和网络资源，从而降低性能。
When a client sends a READ operation, it is not prepared to accept a READ_PLUS-style response providing a compact encoding of the scope of holes. If a READ occurs on a sparse file, then the server must expand such data to be raw bytes. If a READ occurs in the middle of a hole, the server can only send back bytes starting from that offset. By contrast, if a READ_PLUS occurs in the middle of a hole, the server can send back a range that starts before the offset and extends past the requested length.
当客户端发送读取操作时，它不准备接受提供孔范围压缩编码的READ_PLUS样式的响应。如果对稀疏文件进行读取，则服务器必须将此类数据扩展为原始字节。如果一个读发生在一个空洞的中间，服务器只能从该偏移开始发送回字节。相比之下，如果在孔的中间出现一个Read OpRelp，服务器可以发送一个在偏移之前开始的范围，并延伸超过所请求的长度。
The client can use the DEALLOCATE operation on a range of a file as a hole punch, which allows the client to avoid the transfer of a repetitive pattern of zeros across the network. This hole punch is a result of the unreserved space returning all zeros until overwritten.
客户机可以将文件范围上的解除分配操作用作打孔，这允许客户机避免在网络上传输重复的零模式。此打孔是无保留空间返回所有零直到覆盖的结果。
Applications want to be able to reserve space for a file, report the amount of actual disk space a file occupies, and free up the backing space of a file when it is not required.
应用程序希望能够为文件保留空间，报告文件实际占用的磁盘空间量，并在不需要时释放文件的备份空间。
One example is the posix_fallocate() operation [posix_fallocate], which allows applications to ask for space reservations from the operating system, usually to provide a better file layout and reduce overhead for random or slow-growing file-appending workloads.
一个例子是posix_fallocate（）操作[posix_fallocate]，它允许应用程序向操作系统请求空间保留，通常是为了提供更好的文件布局，并减少随机或缓慢增长的文件附加工作负载的开销。
Another example is space reservation for virtual disks in a hypervisor. In virtualized environments, virtual disk files are often stored on NFS-mounted volumes. When a hypervisor creates a virtual disk file, it often tries to preallocate the space for the file so that there are no future allocation-related errors during the operation of the VM. Such errors prevent a VM from continuing execution and result in downtime.
另一个例子是虚拟机监控程序中虚拟磁盘的空间保留。在虚拟化环境中，虚拟磁盘文件通常存储在NFS装载的卷上。当虚拟机监控程序创建虚拟磁盘文件时，它通常会尝试为该文件预先分配空间，以便在虚拟机运行期间不会出现与分配相关的错误。此类错误会阻止VM继续执行并导致停机。
Currently, in order to achieve such a guarantee, applications zero the entire file. The initial zeroing allocates the backing blocks, and all subsequent writes are overwrites of already-allocated blocks. This approach is not only inefficient in terms of the amount of I/O done; it is also not guaranteed to work on file systems that are log-structured or deduplicated. An efficient way of guaranteeing space reservation would be beneficial to such applications.
目前，为了实现这样的保证，应用程序将整个文件归零。初始归零分配备份块，所有后续写入都覆盖已分配的块。这种方法不仅在I/O量方面效率低下；它也不能保证在日志结构或重复数据消除的文件系统上工作。保证空间保留的有效方法将有利于此类应用。
The new ALLOCATE operation (see Section 15.1) allows a client to request a guarantee that space will be available. The ALLOCATE operation guarantees that any future writes to the region it was successfully called for will not fail with NFS4ERR_NOSPC.
新的分配操作（见第15.1节）允许客户请求保证空间可用。ALLOCATE操作保证将来对成功调用的区域进行的任何写入不会因NFS4ERR_NOSPC而失败。
Another useful feature is the ability to report the number of blocks that would be freed when a file is deleted. Currently, NFS reports two size attributes:
另一个有用的功能是报告删除文件时将释放的块数。目前，NFS报告两个大小属性：
size The logical file size of the file.
大小文件的逻辑文件大小。
space_used The size in bytes that the file occupies on disk.
space_使用文件在磁盘上占用的字节大小。
While these attributes are sufficient for space accounting in traditional file systems, they prove to be inadequate in modern file systems that support block-sharing. In such file systems, multiple inodes (the metadata portion of the file system object) can point to a single block with a block reference count to guard against premature freeing. Having a way to tell the number of blocks that would be freed if the file was deleted would be useful to applications that wish to migrate files when a volume is low on space.
虽然这些属性在传统文件系统中足以占用空间，但在支持块共享的现代文件系统中，它们被证明是不够的。在这样的文件系统中，多个inode（文件系统对象的元数据部分）可以指向具有块引用计数的单个块，以防止过早释放。如果有一种方法可以告诉删除文件后将释放的块数，那么对于希望在卷空间不足时迁移文件的应用程序将非常有用。
Since virtual disks represent a hard drive in a VM, a virtual disk can be viewed as a file system within a file. Since not all blocks within a file system are in use, there is an opportunity to reclaim blocks that are no longer in use. A call to deallocate blocks could result in better space efficiency; less space might be consumed for backups after block deallocation.
由于虚拟磁盘代表虚拟机中的硬盘驱动器，因此可以将虚拟磁盘视为文件中的文件系统。由于并非文件系统中的所有块都在使用中，因此有机会回收不再使用的块。释放块的调用可以提高空间效率；块解除分配后，备份可能会占用更少的空间。
The following attribute and operation can be used to resolve these issues:
以下属性和操作可用于解决这些问题：
space_freed This attribute reports the space that would be freed when a file is deleted, taking block-sharing into consideration.
space_freed此属性报告删除文件时将释放的空间，并将块共享考虑在内。
DEALLOCATE This operation deallocates the blocks backing a region of the file.
解除分配此操作解除分配支持文件区域的块。
If space_used of a file is interpreted to mean the size in bytes of all disk blocks pointed to by the inode of the file, then shared blocks get double-counted, over-reporting the space utilization. This also has the adverse effect that the deletion of a file with shared blocks frees up less than space_used bytes.
如果将文件使用的空间_解释为该文件的inode指向的所有磁盘块的字节大小，则共享块会重复计数，从而过度报告空间利用率。这还有一个不利影响，即删除带有共享块的文件释放的空间小于使用的字节数。
On the other hand, if space_used is interpreted to mean the size in bytes of those disk blocks unique to the inode of the file, then shared blocks are not counted in any file, resulting in under-reporting of the space utilization.
另一方面，如果将使用的空间_解释为文件inode特有的磁盘块的字节大小，则共享块不计入任何文件，从而导致空间利用率报告不足。
For example, two files, A and B, have 10 blocks each. Let six of these blocks be shared between them. Thus, the combined space utilized by the two files is 14 * BLOCK_SIZE bytes. In the former case, the combined space utilization of the two files would be reported as 20 * BLOCK_SIZE. However, deleting either would only result in 4 * BLOCK_SIZE being freed. Conversely, the latter interpretation would report that the space utilization is only 8 * BLOCK_SIZE.
例如，两个文件A和B各有10个块。让他们共享其中六个区块。因此，两个文件使用的组合空间为14×BLOCK_大小字节。在前一种情况下，两个文件的组合空间利用率将报告为20*BLOCK_SIZE。但是，删除其中一个只会导致释放4*块大小。相反，后一种解释将报告空间利用率仅为8*块大小。
Using the space_freed attribute (see Section 12.2.2) is helpful in solving this problem. space_freed is the number of blocks that are allocated to the given file that would be freed on its deletion. In the example, both A and B would report space_freed as 4 * BLOCK_SIZE and space_used as 10 * BLOCK_SIZE. If A is deleted, B will report space_freed as 10 * BLOCK_SIZE, as the deletion of B would result in the deallocation of all 10 blocks.
使用space_freed属性（参见第12.2.2节）有助于解决此问题。space_freed是分配给给定文件的块数，该文件在删除时将被释放。在本例中，A和B都会将释放的空间_报告为4*BLOCK_大小，将使用的空间_报告为10*BLOCK_大小。如果删除A，B将报告释放的空间_为10*BLOCK_大小，因为删除B将导致所有10个块的释放。
Using the space_freed attribute does not solve the problem of space being over-reported. However, over-reporting is better than under-reporting.
使用space_freed属性并不能解决空间被过度报告的问题。然而，过度报告比报告不足要好。
At the OS level, files are contained on disk blocks. Applications are also free to impose structure on the data contained in a file and thus can define an Application Data Block (ADB) to be such a structure. From the application's viewpoint, it only wants to handle ADBs and not raw bytes (see [Strohm11]). An ADB is typically
在操作系统级别，文件包含在磁盘块上。应用程序还可以自由地对文件中包含的数据施加结构，因此可以将应用程序数据块（ADB）定义为这样的结构。从应用程序的角度来看，它只想处理ADB，而不是原始字节（请参见[Strohm11]）。亚洲开发银行通常是
comprised of two sections: header and data. The header describes the characteristics of the block and can provide a means to detect corruption in the data payload. The data section is typically initialized to all zeros.
由两部分组成：标题和数据。报头描述块的特征，并可提供检测数据有效负载中损坏的方法。数据段通常初始化为全零。
The format of the header is application specific, but there are two main components typically encountered:
标头的格式是特定于应用程序的，但通常会遇到两个主要组件：
1. An Application Data Block Number (ADBN), which allows the application to determine which data block is being referenced. This is useful when the client is not storing the blocks in contiguous memory, i.e., a logical block number.
1. 应用程序数据块编号（ADBN），允许应用程序确定引用哪个数据块。当客户机未将块存储在连续内存（即逻辑块编号）中时，这非常有用。
2. Fields to describe the state of the ADB and a means to detect block corruption. For both pieces of data, a useful property would be that the allowed values are specially selected so that, if passed across the network, corruption due to translation between big-endian and little-endian architectures is detectable. For example, 0xf0dedef0 has the same (32 wide) bit pattern in both architectures, making it inappropriate.
2. 描述ADB状态的字段以及检测块损坏的方法。对于这两段数据，一个有用的特性是专门选择允许的值，这样，如果通过网络传递，就可以检测到由于big-endian和little-endian体系结构之间的转换而导致的损坏。例如，0xf0dedef0在两种体系结构中具有相同的（32宽）位模式，因此不合适。
Applications already impose structures on files [Strohm11] and detect corruption in data blocks [Ashdown08]. What they are not able to do is efficiently transfer and store ADBs. To initialize a file with ADBs, the client must send each full ADB to the server, and that must be stored on the server.
应用程序已经在文件[Strohm11]上施加结构，并检测数据块中的损坏[Ashdown08]。他们不能做的是高效地传输和存储ADB。要使用ADB初始化文件，客户端必须将每个完整的ADB发送到服务器，并且必须存储在服务器上。
This section defines a framework for transferring the ADB from client to server and presents one approach to detecting corruption in a given ADB implementation.
本节定义了一个用于将ADB从客户端传输到服务器的框架，并介绍了一种在给定ADB实现中检测损坏的方法。
The representation of the ADB needs to be flexible enough to support many different applications. The most basic approach is no imposition of a block at all, which entails working with the raw bytes. Such an approach would be useful for storing holes, punching holes, etc. In more complex deployments, a server might be supporting multiple applications, each with their own definition of the ADB. One might store the ADBN at the start of the block and then have a guard pattern to detect corruption [McDougall07]. The next might store the ADBN at an offset of 100 bytes within the block and have no guard pattern at all, i.e., existing applications might already have well-defined formats for their data blocks.
ADB的表示需要足够灵活，以支持许多不同的应用程序。最基本的方法是根本不强加块，这需要处理原始字节。这种方法对于存储漏洞、打孔等非常有用。在更复杂的部署中，服务器可能支持多个应用程序，每个应用程序都有自己的ADB定义。可以在块的开头存储ADBN，然后使用保护模式来检测损坏[McDougall07]。下一个应用程序可能在块内以100字节的偏移量存储ADBN，并且根本没有保护模式，即，现有应用程序可能已经为其数据块定义了良好的格式。
The guard pattern can be used to represent the state of the block, to protect against corruption, or both. Again, it needs to be able to be placed anywhere within the ADB.
保护模式可用于表示块的状态、防止损坏，或两者兼而有之。同样，它需要能够放在亚洲开发银行的任何地方。
Both the starting offset of the block and the size of the block need to be represented. Note that nothing prevents the application from defining different-sized blocks in a file.
块的起始偏移量和块的大小都需要表示。请注意，应用程序无法在文件中定义不同大小的块。
<CODE BEGINS>
<代码开始>
struct app_data_block4 {
offset4 adb_offset;
length4 adb_block_size;
length4 adb_block_count;
length4 adb_reloff_blocknum;
count4 adb_block_num;
length4 adb_reloff_pattern;
opaque adb_pattern<>;
};
struct app_data_block4 {
offset4 adb_offset;
length4 adb_block_size;
length4 adb_block_count;
length4 adb_reloff_blocknum;
count4 adb_block_num;
length4 adb_reloff_pattern;
opaque adb_pattern<>;
};
<CODE ENDS>
<代码结束>
The app_data_block4 structure captures the abstraction presented for the ADB. The additional fields present are to allow the transmission of adb_block_count ADBs at one time. The adb_block_num is used to convey the ADBN of the first block in the sequence. Each ADB will contain the same adb_pattern string.
app_data_block4结构捕获了为ADB提供的抽象。存在的附加字段允许一次性传输adb_block_count adb。adb_block_num用于传送序列中第一个块的ADBN。每个ADB将包含相同的ADB_模式字符串。
As both adb_block_num and adb_pattern are optional, if either adb_reloff_pattern or adb_reloff_blocknum is set to NFS4_UINT64_MAX, then the corresponding field is not set in any of the ADBs.
由于adb_block_num和adb_pattern都是可选的，如果adb_reloff_pattern或adb_reloff_blocknum设置为NFS4_UINT64_MAX，则在任何adb中都不会设置相应的字段。
In this section, an example ADB format is defined in which corruption can be detected. Note that this is just one possible format and means to detect corruption.
在本节中，定义了一个示例ADB格式，其中可以检测到损坏。请注意，这只是检测损坏的一种可能的格式和方法。
Consider a very basic implementation of an operating system's disk blocks. A block is either data or an indirect block that allows for files that are larger than one block. It is desired to be able to initialize a block. Lastly, to quickly unlink a file, a block can be marked invalid. The contents remain intact; this would enable the OS application in question to undelete a file.
考虑操作系统的磁盘块的一个非常基本的实现。块可以是数据块，也可以是允许文件大于一个块的间接块。希望能够初始化一个块。最后，要快速取消文件链接，可以将块标记为无效。内容保持完整；这将使相关操作系统应用程序能够取消删除文件。
The application defines 4K-sized data blocks, with an 8-byte block counter occurring at offset 0 in the block, and with the guard pattern occurring at offset 8 inside the block. Furthermore, the guard pattern can take one of four states:
应用程序定义4K大小的数据块，其中8字节块计数器出现在块中的偏移量0处，保护模式出现在块中的偏移量8处。此外，保护模式可以采取四种状态之一：
0xfeedface - This is the FREE state and indicates that the ADB format has been applied.
0xfeedface-这是自由状态，表示已应用ADB格式。
0xcafedead - This is the DATA state and indicates that real data has been written to this block.
0xcafedead-这是数据状态，表示实际数据已写入此块。
0xe4e5c001 - This is the INDIRECT state and indicates that the block contains block counter numbers that are chained off of this block.
0xe4e5c001-这是间接状态，表示块包含链接到此块的块计数器编号。
0xba1ed4a3 - This is the INVALID state and indicates that the block contains data whose contents are garbage.
0xba1ed4a3-这是无效状态，表示块包含内容为垃圾的数据。
Finally, it also defines an 8-byte checksum starting at byte 16 that applies to the remaining contents of the block (see [Baira08] for an example of using checksums to detect data corruption). If the state is FREE, then that checksum is trivially zero. As such, the application has no need to transfer the checksum implicitly inside the ADB -- it need not make the transfer layer aware of the fact that there is a checksum (see [Ashdown08] for an example of checksums used to detect corruption in application data blocks).
最后，它还定义了从字节16开始的8字节校验和，该校验和适用于块的剩余内容（有关使用校验和检测数据损坏的示例，请参见[Baira08]）。如果状态是自由的，那么校验和就是零。因此，应用程序不需要在ADB内部隐式传输校验和——它不需要让传输层知道存在校验和的事实（有关用于检测应用程序数据块中损坏的校验和的示例，请参见[Ashdown08]）。
Corruption in each ADB can thus be detected:
因此，可以检测每个ADB中的损坏：
o If the guard pattern is anything other than one of the allowed values, including all zeros.
o 如果保护模式不是允许的值之一，包括所有零。
o If the guard pattern is FREE and any other byte in the remainder of the ADB is anything other than zero.
o 如果保护模式是空闲的，ADB其余部分中的任何其他字节都不是零。
o If the guard pattern is anything other than FREE, then if the stored checksum does not match the computed checksum.
o 如果保护模式不是自由模式，则如果存储的校验和与计算的校验和不匹配。
o If the guard pattern is INDIRECT and one of the stored indirect block numbers has a value greater than the number of ADBs in the file.
o 如果保护模式是间接的，并且其中一个存储的间接块号的值大于文件中的ADB数。
o If the guard pattern is INDIRECT and one of the stored indirect block numbers is a duplicate of another stored indirect block number.
o 如果防护图案是间接的，且其中一个存储的间接块号与另一个存储的间接块号重复。
As can be seen, the application can detect errors based on the combination of the guard pattern state and the checksum but also can detect corruption based on the state and the contents of the ADB.
可以看出，应用程序可以基于保护模式状态和校验和的组合检测错误，但也可以基于ADB的状态和内容检测损坏。
This last point is important in validating the minimum amount of data incorporated into the generic framework. That is, the guard pattern is sufficient in allowing applications to design their own corruption detection.
最后一点对于验证合并到通用框架中的最小数据量非常重要。也就是说，保护模式足以允许应用程序设计自己的损坏检测。
Finally, it is important to note that none of these corruption checks occur in the transport layer. The server and client components are totally unaware of the file format and might report everything as being transferred correctly, even in cases where the application detects corruption.
最后，需要注意的是，这些损坏检查都不会发生在传输层。服务器和客户端组件完全不知道文件格式，甚至在应用程序检测到损坏的情况下，也可能会将所有内容报告为已正确传输。
The hypothetical application presented in Section 8.2 can be used to illustrate how READ_PLUS would return an array of results. A file is created and initialized with 100 4K ADBs in the FREE state with the WRITE_SAME operation (see Section 15.12):
第8.2节中的假设应用程序可用于说明READ_PLUS如何返回结果数组。使用100个处于空闲状态的4K ADB，通过相同的写入操作创建并初始化文件（见第15.12节）：
WRITE_SAME {0, 4K, 100, 0, 0, 8, 0xfeedface}
写相同的{0，4K，100，0，0，8，0xfeedface}
Further, assume that the application writes a single ADB at 16K, changing the guard pattern to 0xcafedead; then there would be in memory:
此外，假设应用程序以16K写入单个ADB，将保护模式更改为0xcafedead；然后在内存中会有：
0K -> (4K - 1) : 00 00 00 00 ... fe ed fa ce 00 00 ... 00
4K -> (8K - 1) : 00 00 00 01 ... fe ed fa ce 00 00 ... 00
8K -> (12K - 1) : 00 00 00 02 ... fe ed fa ce 00 00 ... 00
12K -> (16K - 1) : 00 00 00 03 ... fe ed fa ce 00 00 ... 00
16K -> (20K - 1) : 00 00 00 04 ... ca fe de ad 00 00 ... 00
20K -> (24K - 1) : 00 00 00 05 ... fe ed fa ce 00 00 ... 00
24K -> (28K - 1) : 00 00 00 06 ... fe ed fa ce 00 00 ... 00
...
396K -> (400K - 1) : 00 00 00 63 ... fe ed fa ce 00 00 ... 00
0K -> (4K - 1) : 00 00 00 00 ... fe ed fa ce 00 00 ... 00
4K -> (8K - 1) : 00 00 00 01 ... fe ed fa ce 00 00 ... 00
8K -> (12K - 1) : 00 00 00 02 ... fe ed fa ce 00 00 ... 00
12K -> (16K - 1) : 00 00 00 03 ... fe ed fa ce 00 00 ... 00
16K -> (20K - 1) : 00 00 00 04 ... ca fe de ad 00 00 ... 00
20K -> (24K - 1) : 00 00 00 05 ... fe ed fa ce 00 00 ... 00
24K -> (28K - 1) : 00 00 00 06 ... fe ed fa ce 00 00 ... 00
...
396K -> (400K - 1) : 00 00 00 63 ... fe ed fa ce 00 00 ... 00
And when the client did a READ_PLUS of 64K at the start of the file, it could get back a result of data:
当客户机在文件开始时读取64K时，它可能会返回一个数据结果：
0K -> (4K - 1) : 00 00 00 00 ... fe ed fa ce 00 00 ... 00
4K -> (8K - 1) : 00 00 00 01 ... fe ed fa ce 00 00 ... 00
8K -> (12K - 1) : 00 00 00 02 ... fe ed fa ce 00 00 ... 00
12K -> (16K - 1) : 00 00 00 03 ... fe ed fa ce 00 00 ... 00
16K -> (20K - 1) : 00 00 00 04 ... ca fe de ad 00 00 ... 00
20K -> (24K - 1) : 00 00 00 05 ... fe ed fa ce 00 00 ... 00
24K -> (28K - 1) : 00 00 00 06 ... fe ed fa ce 00 00 ... 00
...
62K -> (64K - 1) : 00 00 00 15 ... fe ed fa ce 00 00 ... 00
0K -> (4K - 1) : 00 00 00 00 ... fe ed fa ce 00 00 ... 00
4K -> (8K - 1) : 00 00 00 01 ... fe ed fa ce 00 00 ... 00
8K -> (12K - 1) : 00 00 00 02 ... fe ed fa ce 00 00 ... 00
12K -> (16K - 1) : 00 00 00 03 ... fe ed fa ce 00 00 ... 00
16K -> (20K - 1) : 00 00 00 04 ... ca fe de ad 00 00 ... 00
20K -> (24K - 1) : 00 00 00 05 ... fe ed fa ce 00 00 ... 00
24K -> (28K - 1) : 00 00 00 06 ... fe ed fa ce 00 00 ... 00
...
62K -> (64K - 1) : 00 00 00 15 ... fe ed fa ce 00 00 ... 00
A simpler use case for WRITE_SAME is applications that want to efficiently zero out a file, but do not want to modify space reservations. This can easily be achieved by a call to WRITE_SAME without an ADB block numbers and pattern, e.g.:
WRITE_的一个更简单的用例是希望有效地清空文件，但不希望修改空间保留的应用程序。这可以很容易地通过调用来实现，在没有ADB块编号和模式的情况下写入相同的块，例如：
WRITE_SAME {0, 1K, 10000, 0, 0, 0, 0}
写相同的{0，1K，10000，0，0，0，0}
Access control models such as UNIX permissions or Access Control Lists (ACLs) are commonly referred to as Discretionary Access Control (DAC) models. These systems base their access decisions on user identity and resource ownership. In contrast, Mandatory Access Control (MAC) models base their access control decisions on the label on the subject (usually a process) and the object it wishes to access [RFC4949]. These labels may contain user identity information but usually contain additional information. In DAC systems, users are free to specify the access rules for resources that they own. MAC models base their security decisions on a system-wide policy -- established by an administrator or organization -- that the users do not have the ability to override. In this section, a MAC model is added to NFSv4.2.
诸如UNIX权限或访问控制列表（ACL）之类的访问控制模型通常称为自主访问控制（DAC）模型。这些系统的访问决策基于用户身份和资源所有权。相反，强制访问控制（MAC）模型将其访问控制决策建立在主题（通常是一个进程）和它希望访问的对象的标签上[RFC4949]。这些标签可能包含用户身份信息，但通常包含附加信息。在DAC系统中，用户可以自由指定其拥有的资源的访问规则。MAC机型的安全决策基于系统范围的策略（由管理员或组织制定），用户无法覆盖该策略。在本节中，一个MAC模型被添加到NFSv4.2中。
First, a method is provided for transporting and storing security label data on NFSv4 file objects. Security labels have several semantics that are met by NFSv4 recommended attributes such as the ability to set the label value upon object creation. Access control on these attributes is done through a combination of two mechanisms. As with other recommended attributes on file objects, the usual DAC checks, based on the ACLs and permission bits, will be performed to ensure that proper file ownership is enforced. In addition, a MAC system MAY be employed on the client, server, or both to enforce additional policy on what subjects may modify security label information.
首先，提供用于在NFSv4文件对象上传输和存储安全标签数据的方法。安全标签具有NFSv4推荐属性所满足的几种语义，例如在创建对象时设置标签值的能力。对这些属性的访问控制是通过两种机制的组合来完成的。与文件对象上的其他推荐属性一样，将基于ACL和权限位执行通常的DAC检查，以确保强制执行正确的文件所有权。此外，可以在客户端、服务器或两者上使用MAC系统，以对可能修改安全标签信息的主体实施附加策略。
Second, a method is described for the client to determine if an NFSv4 file object security label has changed. A client that needs to know if a label on a file or set of files is going to change SHOULD request a delegation on each labeled file. In order to change such a security label, the server will have to recall delegations on any file affected by the label change, so informing clients of the label change.
其次，描述了一种用于客户端确定NFSv4文件对象安全标签是否已更改的方法。如果客户机需要知道文件或文件集上的标签是否要更改，则应请求对每个标记文件进行委派。为了更改这样一个安全标签，服务器必须重新调用受标签更改影响的任何文件上的委托，以便将标签更改通知客户端。
An additional useful feature would be modification to the RPC layer used by NFSv4 to allow RPCs to assert client process subject security labels and enable the enforcement of Full Mode as described in Section 9.5.1. Such modifications are outside the scope of this document (see [RFC7861]).
另一个有用的特性是修改NFSv4使用的RPC层，以允许RPC断言客户端进程主题安全标签，并启用第9.5.1节所述的完整模式。此类修改不在本文件范围内（见[RFC7861]）。
Label Format Specifier (LFS): an identifier used by the client to establish the syntactic format of the security label and the semantic meaning of its components. LFSs exist in a registry associated with documents describing the format and semantics of the label.
标签格式说明符（LFS）：客户端用于建立安全标签的语法格式及其组件的语义的标识符。LFS存在于与描述标签格式和语义的文档相关联的注册表中。
Security Label Format Selection Registry: the IANA registry (see [RFC7569]) containing all registered LFSs, along with references to the documents that describe the syntactic format and semantics of the security label.
安全标签格式选择注册表：包含所有已注册LFS的IANA注册表（参见[RFC7569]），以及对描述安全标签语法格式和语义的文档的引用。
Policy Identifier (PI): an optional part of the definition of an LFS. The PI allows clients and servers to identify specific security policies.
策略标识符（PI）：LFS定义的可选部分。PI允许客户端和服务器识别特定的安全策略。
Object: a passive resource within the system that is to be protected. Objects can be entities such as files, directories, pipes, sockets, and many other system resources relevant to the protection of the system state.
对象：系统中要保护的被动资源。对象可以是实体，如文件、目录、管道、套接字和许多其他与系统状态保护相关的系统资源。
Subject: an active entity, usually a process that is requesting access to an object.
主题：活动实体，通常是请求访问对象的进程。
MAC-Aware: a server that can transmit and store object labels.
MAC感知：可以传输和存储对象标签的服务器。
MAC-Functional: a client or server that is Labeled NFS enabled. Such a system can interpret labels and apply policies based on the security system.
MAC Functional：标记为启用NFS的客户端或服务器。这样的系统可以基于安全系统解释标签和应用策略。
Multi-Level Security (MLS): a traditional model where objects are given a sensitivity level (Unclassified, Secret, Top Secret, etc.) and a category set (see [LB96], [RFC1108], [RFC2401], and [RFC4949]).
多级安全性（MLS）：一种传统模型，其中对象被赋予一个敏感级别（未分类、机密、绝密等）和一个类别集（请参见[LB96]、[RFC1108]、[RFC2401]和[RFC4949]）。
(Note: RFC 2401 has been obsoleted by RFC 4301, but we list RFC 2401 here because RFC 4301 does not discuss MLS.)
（注：RFC 4301已淘汰RFC 2401，但我们在此列出RFC 2401，因为RFC 4301不讨论MLS。）
MAC models base access decisions on security attributes bound to subjects (usually processes) and objects (for NFS, file objects). This information can range from a user identity for an identity-based MAC model, sensitivity levels for MLS, or a type for type enforcement. These models base their decisions on different criteria, but the semantics of the security attribute remain the same. The semantics required by the security attribute are listed below:
MAC模型基于绑定到主题（通常是进程）和对象（对于NFS，文件对象）的安全属性来做出访问决策。这些信息的范围包括基于身份的MAC模型的用户身份、MLS的敏感度级别或类型强制的类型。这些模型的决策基于不同的标准，但安全属性的语义保持不变。安全属性所需的语义如下所示：
o MUST provide flexibility with respect to the MAC model.
o 必须提供MAC模式方面的灵活性。
o MUST provide the ability to atomically set security information upon object creation.
o 必须提供在创建对象时自动设置安全信息的能力。
o MUST provide the ability to enforce access control decisions on both the client and the server.
o 必须提供在客户端和服务器上强制执行访问控制决策的能力。
o MUST NOT expose an object to either the client or server namespace before its security information has been bound to it.
o 在将对象的安全信息绑定到该对象之前，不得将其公开给客户端或服务器命名空间。
NFSv4 implements the MAC security attribute as a recommended attribute. This attribute has a fixed format and semantics, which conflicts with the flexible nature of security attributes in general. To resolve this, the MAC security attribute consists of two components. The first component is an LFS, as defined in [RFC7569], to allow for interoperability between MAC mechanisms. The second component is an opaque field, which is the actual security attribute data. To allow for various MAC models, NFSv4 should be used solely as a transport mechanism for the security attribute. It is the responsibility of the endpoints to consume the security attribute and make access decisions based on their respective models. In addition, creation of objects through OPEN and CREATE allows the security attribute to be specified upon creation. By providing an atomic create and set operation for the security attribute, it is possible to enforce the second and fourth requirements listed above. The recommended attribute FATTR4_SEC_LABEL (see Section 12.2.4) will be used to satisfy this requirement.
NFSv4将MAC安全属性作为推荐属性实现。该属性具有固定的格式和语义，这与一般安全属性的灵活性相冲突。要解决此问题，MAC安全属性由两个组件组成。第一个组件是LFS，如[RFC7569]中所定义，以允许MAC机制之间的互操作性。第二个组件是不透明字段，它是实际的安全属性数据。为了支持各种MAC模型，NFSv4应单独用作安全属性的传输机制。端点负责使用安全属性，并根据各自的模型做出访问决策。此外，通过OPEN和CREATE创建对象允许在创建时指定security属性。通过为security属性提供原子创建和设置操作，可以强制执行上面列出的第二个和第四个要求。推荐的属性FATTR4_SEC_标签（见第12.2.4节）将用于满足该要求。
In the event that a security attribute is changed on the server while a client holds a delegation on the file, both the server and the client MUST follow the NFSv4.1 protocol (see Section 10 of [RFC5661]) with respect to attribute changes. It SHOULD flush all changes back to the server and relinquish the delegation.
如果在客户端持有文件委托的情况下更改服务器上的安全属性，则服务器和客户端必须遵守NFSv4.1协议（参见[RFC5661]第10节）中有关属性更改的规定。它应该将所有更改刷新回服务器并放弃委派。
It is not feasible to enumerate all possible MAC models and even levels of protection within a subset of these models. This means that the NFSv4 client and servers cannot be expected to directly make access control decisions based on the security attribute. Instead, NFSv4 should defer permission checking on this attribute to the host system. These checks are performed in addition to existing DAC and ACL checks outlined in the NFSv4 protocol. Section 9.5 gives a specific example of how the security attribute is handled under a particular MAC model.
列举所有可能的MAC模型以及这些模型子集内的保护级别是不可行的。这意味着NFSv4客户端和服务器不能直接根据安全属性做出访问控制决策。相反，NFSv4应该将此属性的权限检查推迟到主机系统。这些检查是在NFSv4协议中概述的现有DAC和ACL检查之外执行的。第9.5节给出了在特定MAC模型下如何处理安全属性的具体示例。
When creating files in NFSv4, the OPEN and CREATE operations are used. One of the parameters for these operations is an fattr4 structure containing the attributes the file is to be created with. This allows NFSv4 to atomically set the security attribute of files upon creation. When a client is MAC-Functional, it must always provide the initial security attribute upon file creation. In the event that the server is MAC-Functional as well, it should determine by policy whether it will accept the attribute from the client or instead make the determination itself. If the client is not MAC-Functional, then the MAC-Functional server must decide on a default label. A more in-depth explanation can be found in Section 9.5.
在NFSv4中创建文件时，将使用“打开”和“创建”操作。这些操作的参数之一是fattr4结构，其中包含要使用其创建文件的属性。这允许NFSv4在创建文件时自动设置文件的安全属性。当客户端具有MAC功能时，它必须在创建文件时始终提供初始安全属性。如果服务器也是MAC功能的，它应该通过策略确定是接受来自客户端的属性，还是自行确定。如果客户端没有MAC功能，则MAC功能服务器必须决定默认标签。更深入的解释见第9.5节。
Note that under the MAC model, all objects must have labels. Therefore, if an existing server is upgraded to include Labeled NFS support, then it is the responsibility of the security system to define the behavior for existing objects.
请注意，在MAC模型下，所有对象都必须有标签。因此，如果现有服务器升级为包含标记的NFS支持，则安全系统负责定义现有对象的行为。
Consider a Guest Mode system (Section 9.5.3) in which the clients enforce MAC checks and the server has only a DAC security system that stores the labels along with the file data. In this type of system, a user with the appropriate DAC credentials on a client with poorly configured or disabled MAC labeling enforcement is allowed access to the file label (and data) on the server and can change the label.
考虑一个客户模式系统（章节95.3），其中客户端强制执行MAC检查，服务器只有一个DAC安全系统，该系统与文件数据一起存储标签。在这种类型的系统中，允许在配置不当或禁用MAC标签强制的客户端上具有适当DAC凭据的用户访问服务器上的文件标签（和数据），并可以更改标签。
Clients that need to know if a label on a file or set of files has changed SHOULD request a delegation on each labeled file so that a label change by another client will be known via the process described in Section 9.2.1, which must be followed: the delegation will be recalled, which effectively notifies the client of the change.
需要知道文件或文件集上的标签是否已更改的客户应请求对每个已标记文件进行委派，以便通过第9.2.1节中描述的流程了解另一客户的标签更改，必须遵循该流程：将召回委派，从而有效地通知客户更改。
Note that the MAC security policies on a client can be such that the client does not have access to the file unless it has a delegation.
请注意，客户机上的MAC安全策略可以使客户机无法访问该文件，除非它具有委派。
The new FATTR4_SEC_LABEL attribute is metadata information, and as such the storage device is not aware of the value contained on the metadata server. Fortunately, the NFSv4.1 protocol [RFC5661] already has provisions for doing access-level checks from the storage device to the metadata server. In order for the storage device to validate the subject label presented by the client, it SHOULD utilize this mechanism.
新的FATTR4_SEC_LABEL属性是元数据信息，因此存储设备不知道元数据服务器上包含的值。幸运的是，NFSv4.1协议[RFC5661]已经为从存储设备到元数据服务器的访问级别检查做好了准备。为了让存储设备验证客户端提供的主题标签，它应该利用这种机制。
The server can easily determine that a client supports Labeled NFS when it queries for the FATTR4_SEC_LABEL label for an object. Further, it can then determine which LFS the client understands. The client might want to discover whether the server supports Labeled NFS and which LFS the server supports.
服务器在查询对象的FATTR4_secu_标签时，可以轻松确定客户端是否支持带标签的NFS。此外，它还可以确定客户了解哪些LFS。客户端可能希望发现服务器是否支持标记为NFS的文件，以及服务器支持哪些LFS。
The following COMPOUND MUST NOT be denied by any MAC label check:
以下化合物不得被任何MAC标签检查拒绝：
PUTROOTFH, GETATTR {FATTR4_SEC_LABEL}
PUTROOTFH，GETATTR{FATTR4_SEC_LABEL}
Note that the server might have imposed a security flavor on the root that precludes such access. That is, if the server requires Kerberized access and the client presents a COMPOUND with AUTH_SYS, then the server is allowed to return NFS4ERR_WRONGSEC in this case. But if the client presents a correct security flavor, then the server MUST return the FATTR4_SEC_LABEL attribute with the supported LFS filled in.
请注意，服务器可能在根目录上施加了一种安全特性，从而阻止了这种访问。也就是说，如果服务器需要Kerberized访问，并且客户端提供了一个带有AUTH_SYS的复合，那么在这种情况下，允许服务器返回NFS4ERR_errosec。但是，如果客户端提供了正确的安全风格，那么服务器必须返回FATTR4_secu_LABEL属性，并填入支持的LFS。
A system using Labeled NFS may operate in three modes (see Section 4 of [RFC7204]). The first mode provides the most protection and is called "Full Mode". In this mode, both the client and server implement a MAC model allowing each end to make an access control decision. The second mode is a subset of the Full Mode and is called "Limited Server Mode". In this mode, the server cannot enforce the
使用带标签NFS的系统可在三种模式下运行（请参阅[RFC7204]第4节）。第一种模式提供最多的保护，称为“全模式”。在这种模式下，客户端和服务器都实现了一个MAC模型，允许每一端做出访问控制决策。第二种模式是完整模式的子集，称为“受限服务器模式”。在此模式下，服务器无法强制
labels, but it can store and transmit them. The remaining mode is called the "Guest Mode"; in this mode, one end of the connection is not implementing a MAC model and thus offers less protection than Full Mode.
标签，但它可以存储和传输它们。剩下的模式称为“来宾模式”；在此模式下，连接的一端未实现MAC模式，因此提供的保护比完全模式少。
Full Mode environments consist of MAC-Functional NFSv4 servers and clients and may be composed of mixed MAC models and policies. The system requires that both the client and server have an opportunity to perform an access control check based on all relevant information within the network. The file object security attribute is provided using the mechanism described in Section 9.2.
全模式环境由具有MAC功能的NFSv4服务器和客户端组成，可能由混合MAC模型和策略组成。系统要求客户端和服务器都有机会根据网络中的所有相关信息执行访问控制检查。文件对象安全属性是使用第9.2节中描述的机制提供的。
Fully MAC-Functional NFSv4 servers are not possible in the absence of RPCSEC_GSSv3 [RFC7861] support for client process subject label assertion. However, servers may make decisions based on the RPC credential information available.
如果没有RPCSEC_GSSv3[RFC7861]对客户端进程主题标签断言的支持，则不可能实现完全MAC功能的NFSv4服务器。但是，服务器可以根据可用的RPC凭据信息做出决定。
The ability to create a file is an action that a MAC model may wish to mediate. The client is given the responsibility to determine the initial security attribute to be placed on a file. This allows the client to make a decision as to the acceptable security attribute to create a file with before sending the request to the server. Once the server receives the creation request from the client, it may choose to evaluate if the security attribute is acceptable.
创建文件的能力是MAC机型可能希望调解的操作。客户机负责确定要放置在文件上的初始安全属性。这允许客户机在将请求发送到服务器之前，决定使用哪个可接受的安全属性创建文件。一旦服务器从客户端接收到创建请求，它可以选择评估安全属性是否可接受。
Security attributes on the client and server may vary based on MAC model and policy. To handle this, the security attribute field has an LFS component. This component is a mechanism for the host to identify the format and meaning of the opaque portion of the security attribute. A Full Mode environment may contain hosts operating in several different LFSs. In this case, a mechanism for translating the opaque portion of the security attribute is needed. The actual translation function will vary based on MAC model and policy and is outside the scope of this document. If a translation is unavailable for a given LFS, then the request MUST be denied. Another recourse is to allow the host to provide a fallback mapping for unknown security attributes.
客户端和服务器上的安全属性可能因MAC模型和策略而异。为了处理这个问题，security属性字段有一个LFS组件。该组件是主机识别安全属性不透明部分的格式和含义的机制。全模式环境可能包含在多个不同LFS中运行的主机。在这种情况下，需要一种转换安全属性不透明部分的机制。实际翻译功能将根据MAC模式和政策而有所不同，不在本文件范围内。如果给定LFS的翻译不可用，则必须拒绝该请求。另一种方法是允许主机为未知安全属性提供回退映射。
In Full Mode, access control decisions are made by both the clients and servers. When a client makes a request, it takes the security attribute from the requesting process and makes an access control decision based on that attribute and the security attribute of the
在完全模式下，访问控制决策由客户端和服务器共同做出。当客户机发出请求时，它从请求进程获取安全属性，并基于该属性和请求进程的安全属性做出访问控制决策
object it is trying to access. If the client denies that access, an RPC to the server is never made. If, however, the access is allowed, the client will make a call to the NFS server.
它试图访问的对象。如果客户端拒绝该访问，则永远不会向服务器发送RPC。但是，如果允许访问，客户端将调用NFS服务器。
When the server receives the request from the client, it uses any credential information conveyed in the RPC request and the attributes of the object the client is trying to access to make an access control decision. If the server's policy allows this access, it will fulfill the client's request; otherwise, it will return NFS4ERR_ACCESS.
当服务器从客户端接收到请求时，它使用RPC请求中传递的任何凭据信息以及客户端试图访问的对象的属性来做出访问控制决策。如果服务器的策略允许这种访问，它将满足客户端的请求；否则，它将返回NFS4ERR_访问。
Future protocol extensions may also allow the server to factor into the decision a security label extracted from the RPC request.
未来的协议扩展还允许服务器将从RPC请求中提取的安全标签纳入决策。
Implementations MAY validate security attributes supplied over the network to ensure that they are within a set of attributes permitted from a specific peer and, if not, reject them. Note that a system may permit a different set of attributes to be accepted from each peer.
实现可以验证通过网络提供的安全属性，以确保它们在特定对等方允许的一组属性内，如果不在，则拒绝它们。请注意，系统可能允许从每个对等方接受不同的属性集。
A Limited Server mode (see Section 4.2 of [RFC7204]) consists of a server that is label aware but does not enforce policies. Such a server will store and retrieve all object labels presented by clients and will utilize the methods described in Section 9.2.5 to allow the clients to detect changing labels, but may not factor the label into access decisions. Instead, it will expect the clients to enforce all such access locally.
有限服务器模式（请参阅[RFC7204]第4.2节）由一个可识别标签但不强制执行策略的服务器组成。此类服务器将存储和检索客户端提供的所有对象标签，并将利用第9.2.5节中描述的方法允许客户端检测不断变化的标签，但可能不会将标签纳入访问决策。相反，它希望客户端在本地强制执行所有此类访问。
Guest Mode implies that either the client or the server does not handle labels. If the client is not Labeled NFS aware, then it will not offer subject labels to the server. The server is the only entity enforcing policy and may selectively provide standard NFS services to clients based on their authentication credentials and/or associated network attributes (e.g., IP address, network interface). The level of trust and access extended to a client in this mode is configuration specific. If the server is not Labeled NFS aware, then it will not return object labels to the client. Clients in this environment may consist of groups implementing different MAC model policies. The system requires that all clients in the environment be responsible for access control checks.
来宾模式意味着客户机或服务器不处理标签。如果客户端未标记为NFS感知，则它不会向服务器提供主题标签。服务器是实施策略的唯一实体，可以根据客户端的身份验证凭据和/或相关网络属性（例如，IP地址、网络接口）选择性地向客户端提供标准NFS服务。在此模式下扩展到客户端的信任和访问级别是特定于配置的。如果服务器未标记为NFS感知，则不会将对象标签返回给客户端。此环境中的客户端可能由实现不同MAC模型策略的组组成。系统要求环境中的所有客户端负责访问控制检查。
Depending on the level of protection the MAC system offers, there may be a requirement to tightly bind the security attribute to the data.
根据MAC系统提供的保护级别，可能需要将安全属性与数据紧密绑定。
When only one of the client or server enforces labels, it is important to realize that the other side is not enforcing MAC protections. Alternate methods might be in use to handle the lack of MAC support, and care should be taken to identify and mitigate threats from possible tampering outside of these methods.
当只有一个客户端或服务器强制执行标签时，必须认识到另一方没有强制执行MAC保护。可能会使用其他方法来处理缺乏MAC支持的问题，并且应注意识别和减轻这些方法之外可能的篡改威胁。
An example of this is that a server that modifies READDIR or LOOKUP results based on the client's subject label might want to always construct the same subject label for a client that does not present one. This will prevent a non-Labeled NFS client from mixing entries in the directory cache.
例如，根据客户端的主题标签修改READDIR或查找结果的服务器可能希望始终为不显示主题标签的客户端构造相同的主题标签。这将防止未标记的NFS客户端在目录缓存中混合条目。
10. Sharing Change Attribute Implementation Characteristics with NFSv4 Clients
10. 与NFSv4客户端共享更改属性实现特征
Although both the NFSv4 [RFC7530] and NFSv4.1 [RFC5661] protocols define the change attribute as being mandatory to implement, there is little in the way of guidance as to its construction. The only mandated constraint is that the value must change whenever the file data or metadata changes.
尽管NFSv4[RFC7530]和NFSv4.1[RFC5661]协议都将变更属性定义为必须实现的，但对于其构造，几乎没有指导。唯一的强制约束是，每当文件数据或元数据更改时，该值必须更改。
While this allows for a wide range of implementations, it also leaves the client with no way to determine which is the most recent value for the change attribute in a case where several RPCs have been issued in parallel. In other words, if two COMPOUNDs, both containing WRITE and GETATTR requests for the same file, have been issued in parallel, how does the client determine which of the two change attribute values returned in the replies to the GETATTR requests corresponds to the most recent state of the file? In some cases, the only recourse may be to send another COMPOUND containing a third GETATTR that is fully serialized with the first two.
虽然这允许广泛的实现，但在多个RPC并行发布的情况下，客户端也无法确定更改属性的最新值。换句话说，如果同时发出了两个复合文件（都包含对同一文件的写入和GETATTR请求），那么客户端如何确定在对GETATTR请求的回复中返回的两个更改属性值中的哪一个对应于文件的最新状态？在某些情况下，唯一的办法可能是发送另一个包含第三个GETATTR的化合物，该化合物与前两个完全序列化。
NFSv4.2 avoids this kind of inefficiency by allowing the server to share details about how the change attribute is expected to evolve, so that the client may immediately determine which, out of the several change attribute values returned by the server, is the most recent. change_attr_type is defined as a new recommended attribute (see Section 12.2.3) and is a per-file system attribute.
NFSv4.2通过允许服务器共享有关更改属性如何演变的详细信息，避免了这种低效，因此客户端可以立即确定服务器返回的多个更改属性值中哪一个是最新的。change_attr_type定义为新的推荐属性（请参见第12.2.3节），是每个文件系统的属性。
NFS error numbers are assigned to failed operations within a COMPOUND (COMPOUND or CB_COMPOUND) request. A COMPOUND request contains a number of NFS operations that have their results encoded in sequence in a COMPOUND reply. The results of successful operations will consist of an NFS4_OK status followed by the encoded results of the operation. If an NFS operation fails, an error status will be entered in the reply and the COMPOUND request will be terminated.
NFS错误号分配给复合（复合或CB_复合）请求中的失败操作。复合请求包含许多NFS操作，这些操作的结果在复合应答中按顺序编码。成功操作的结果将包括NFS4_OK状态，然后是编码的操作结果。如果NFS操作失败，将在回复中输入错误状态，复合请求将终止。
+-------------------------+--------+------------------+
| Error | Number | Description |
+-------------------------+--------+------------------+
| NFS4ERR_BADLABEL | 10093 | Section 11.1.3.1 |
| NFS4ERR_OFFLOAD_DENIED | 10091 | Section 11.1.2.1 |
| NFS4ERR_OFFLOAD_NO_REQS | 10094 | Section 11.1.2.2 |
| NFS4ERR_PARTNER_NO_AUTH | 10089 | Section 11.1.2.3 |
| NFS4ERR_PARTNER_NOTSUPP | 10088 | Section 11.1.2.4 |
| NFS4ERR_UNION_NOTSUPP | 10090 | Section 11.1.1.1 |
| NFS4ERR_WRONG_LFS | 10092 | Section 11.1.3.2 |
+-------------------------+--------+------------------+
+-------------------------+--------+------------------+
| Error | Number | Description |
+-------------------------+--------+------------------+
| NFS4ERR_BADLABEL | 10093 | Section 11.1.3.1 |
| NFS4ERR_OFFLOAD_DENIED | 10091 | Section 11.1.2.1 |
| NFS4ERR_OFFLOAD_NO_REQS | 10094 | Section 11.1.2.2 |
| NFS4ERR_PARTNER_NO_AUTH | 10089 | Section 11.1.2.3 |
| NFS4ERR_PARTNER_NOTSUPP | 10088 | Section 11.1.2.4 |
| NFS4ERR_UNION_NOTSUPP | 10090 | Section 11.1.1.1 |
| NFS4ERR_WRONG_LFS | 10092 | Section 11.1.3.2 |
+-------------------------+--------+------------------+
Table 1: Protocol Error Definitions
表1：协议错误定义
This section deals with errors that are applicable to a broad set of different purposes.
本节讨论适用于各种不同目的的错误。
One of the arguments to the operation is a discriminated union, and while the server supports the given operation, it does not support the selected arm of the discriminated union.
该操作的一个参数是判别联合，虽然服务器支持给定的操作，但不支持判别联合的选定分支。
These errors deal with the interaction between server-to-server copies.
这些错误处理服务器到服务器副本之间的交互。
The COPY offload operation is supported by both the source and the destination, but the destination is not allowing it for this file. If the client sees this error, it should fall back to the normal copy semantics.
源和目标都支持复制卸载操作，但目标不允许该操作用于此文件。如果客户端看到这个错误，它应该返回到正常的复制语义。
The COPY offload operation is supported by both the source and the destination, but the destination cannot meet the client requirements for either consecutive byte copy or synchronous copy. If the client sees this error, it should either relax the requirements (if any) or fall back to the normal copy semantics.
源和目标都支持复制卸载操作，但目标无法满足客户端对连续字节复制或同步复制的要求。如果客户机看到这个错误，它应该放松需求（如果有的话），或者回到正常的复制语义。
The source server does not authorize a server-to-server COPY offload operation. This may be due to the client's failure to send the COPY_NOTIFY operation to the source server, the source server receiving a server-to-server copy offload request after the copy lease time expired, or some other permission problem.
源服务器未授权服务器到服务器复制卸载操作。这可能是由于客户端未能将复制通知操作发送到源服务器、源服务器在复制租用时间到期后接收到服务器到服务器的复制卸载请求，或者其他一些权限问题造成的。
The destination server does not authorize a server-to-server COPY offload operation. This may be due to an inter-server COPY request where the destination server requires RPCSEC_GSSv3 and it is not used, or some other permissions problem.
目标服务器未授权服务器到服务器复制卸载操作。这可能是由于目标服务器需要RPCSEC_GSSv3但未使用的服务器间复制请求，或者其他一些权限问题造成的。
The remote server does not support the server-to-server COPY offload protocol.
远程服务器不支持服务器到服务器复制卸载协议。
These errors are used in Labeled NFS.
这些错误在标记的NFS中使用。
The label specified is invalid in some manner.
指定的标签在某些方面无效。
The LFS specified in the subject label is not compatible with the LFS in the object label.
主题标签中指定的LFS与对象标签中的LFS不兼容。
This section contains a table that gives the valid error returns for each new NFSv4.2 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 of [RFC5661].
本节包含一个表，该表给出了每个新NFSv4.2协议操作的有效错误返回。错误代码NFS4_OK（表示无错误）未列出，但应理解为可由所有新操作返回。[RFC5661]第15.2节定义了所有其他操作的误差值。
+----------------+--------------------------------------------------+
| Operation | Errors |
+----------------+--------------------------------------------------+
| ALLOCATE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | 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_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| CLONE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | 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_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE, |
| | NFS4ERR_XDEV |
+----------------+--------------------------------------------------+
| Operation | Errors |
+----------------+--------------------------------------------------+
| ALLOCATE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | 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_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| CLONE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | 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_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE, |
| | NFS4ERR_XDEV |
+----------------+--------------------------------------------------+
| COPY | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_OFFLOAD_DENIED, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PARTNER_NO_AUTH, |
| | NFS4ERR_PARTNER_NOTSUPP, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, 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_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| COPY_NOTIFY | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| DEALLOCATE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
+----------------+--------------------------------------------------+
| COPY | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_OFFLOAD_DENIED, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PARTNER_NO_AUTH, |
| | NFS4ERR_PARTNER_NOTSUPP, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, 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_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| COPY_NOTIFY | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| DEALLOCATE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | 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_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| GETDEVICELIST | NFS4ERR_NOTSUPP |
+----------------+--------------------------------------------------+
| IO_ADVISE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| LAYOUTERROR | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, |
| | NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_NO_GRACE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OP_NOT_IN_SESSION, |
| | 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_UNKNOWN_LAYOUTTYPE, NFS4ERR_WRONG_CRED, |
| | NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| LAYOUTSTATS | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, |
| | NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_NO_GRACE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| GETDEVICELIST | NFS4ERR_NOTSUPP |
+----------------+--------------------------------------------------+
| IO_ADVISE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| LAYOUTERROR | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, |
| | NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_NO_GRACE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OP_NOT_IN_SESSION, |
| | 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_UNKNOWN_LAYOUTTYPE, NFS4ERR_WRONG_CRED, |
| | NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| LAYOUTSTATS | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, |
| | NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_NO_GRACE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OP_NOT_IN_SESSION, |
| | 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_UNKNOWN_LAYOUTTYPE, NFS4ERR_WRONG_CRED, |
| | NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| OFFLOAD_CANCEL | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_COMPLETE_ALREADY, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_GRACE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS |
+----------------+--------------------------------------------------+
| OFFLOAD_STATUS | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_COMPLETE_ALREADY, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_GRACE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS |
+----------------+--------------------------------------------------+
| READ_PLUS | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PARTNER_NO_AUTH, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| SEEK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PNFS_IO_HOLE, NFS4ERR_PNFS_NO_LAYOUT, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_UNKNOWN_LAYOUTTYPE, NFS4ERR_WRONG_CRED, |
| | NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| OFFLOAD_CANCEL | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_COMPLETE_ALREADY, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_GRACE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS |
+----------------+--------------------------------------------------+
| OFFLOAD_STATUS | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_COMPLETE_ALREADY, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_GRACE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_TOO_MANY_OPS |
+----------------+--------------------------------------------------+
| READ_PLUS | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PARTNER_NO_AUTH, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| SEEK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTSUPP, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PNFS_IO_HOLE, NFS4ERR_PNFS_NO_LAYOUT, |
| | NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_UNION_NOTSUPP, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| WRITE_SAME | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, 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_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, |
| | NFS4ERR_UNION_NOTSUPP, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
| WRITE_SAME | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, 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_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+----------------+--------------------------------------------------+
Table 2: Valid Error Returns for Each New Protocol Operation
表2：每个新协议操作的有效错误返回
This section contains a table that gives the valid error returns for each new NFSv4.2 callback operation. The error code NFS4_OK (indicating no error) is not listed but should be understood to be returnable by all new callback operations. The error values for all other callback operations are defined in Section 15.3 of [RFC5661].
本节包含一个表，该表为每个新的NFSv4.2回调操作提供有效的错误返回。错误代码NFS4_OK（表示无错误）未列出，但应理解为可由所有新回调操作返回。[RFC5661]第15.3节定义了所有其他回调操作的错误值。
+------------+------------------------------------------------------+
| Callback | Errors |
| Operation | |
+------------+------------------------------------------------------+
| CB_OFFLOAD | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
+------------+------------------------------------------------------+
+------------+------------------------------------------------------+
| Callback | Errors |
| Operation | |
+------------+------------------------------------------------------+
| CB_OFFLOAD | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, NFS4ERR_REQ_TOO_BIG, |
| | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_TOO_MANY_OPS |
+------------+------------------------------------------------------+
Table 3: Valid Error Returns for Each New Protocol Callback Operation
表3：每个新协议回调操作的有效错误返回
The list of new RECOMMENDED attributes appears in Table 4. The meanings of the columns of the table are:
新推荐属性列表如表4所示。表中各列的含义如下：
Name: The name of the attribute.
名称：属性的名称。
Id: The number assigned to the attribute. In the event of conflicts between the assigned number and [RFC7863], the latter is authoritative, but in such an event, it should be resolved with errata to this document and/or [RFC7863]. See [IESG08] for the errata process.
Id：分配给属性的编号。如果分配的编号与[RFC7863]之间存在冲突，后者具有权威性，但在这种情况下，应使用本文件和/或[RFC7863]的勘误表予以解决。有关勘误表过程，请参见[IESG08]。
Data Type: The XDR data type of the attribute.
数据类型：属性的XDR数据类型。
Acc: Access allowed to the attribute.
Acc：允许访问该属性。
R means read-only (GETATTR may retrieve, SETATTR may not set).
R表示只读（GETATTR可以检索，SETATTR可以不设置）。
W means write-only (SETATTR may set, GETATTR may not retrieve).
W表示仅写（SETATTR可以设置，GETATTR不能检索）。
R W means read/write (GETATTR may retrieve, SETATTR may set).
RW表示读/写（GETATTR可以检索，SETATTR可以设置）。
Defined in: The section of this specification that describes the attribute.
定义于：本规范中描述属性的部分。
+------------------+----+-------------------+-----+----------------+
| Name | Id | Data Type | Acc | Defined in |
+------------------+----+-------------------+-----+----------------+
| clone_blksize | 77 | uint32_t | R | Section 12.2.1 |
| space_freed | 78 | length4 | R | Section 12.2.2 |
| change_attr_type | 79 | change_attr_type4 | R | Section 12.2.3 |
| sec_label | 80 | sec_label4 | R W | Section 12.2.4 |
+------------------+----+-------------------+-----+----------------+
+------------------+----+-------------------+-----+----------------+
| Name | Id | Data Type | Acc | Defined in |
+------------------+----+-------------------+-----+----------------+
| clone_blksize | 77 | uint32_t | R | Section 12.2.1 |
| space_freed | 78 | length4 | R | Section 12.2.2 |
| change_attr_type | 79 | change_attr_type4 | R | Section 12.2.3 |
| sec_label | 80 | sec_label4 | R W | Section 12.2.4 |
+------------------+----+-------------------+-----+----------------+
Table 4: New RECOMMENDED Attributes
表4：建议的新属性
The clone_blksize attribute indicates the granularity of a CLONE operation.
clone_blksize属性表示克隆操作的粒度。
space_freed gives the number of bytes freed if the file is deleted. This attribute is read-only and is of type length4. It is a per-file attribute.
space_freed给出删除文件时释放的字节数。此属性是只读的，类型为length4。它是每个文件的属性。
<CODE BEGINS>
<代码开始>
enum change_attr_type4 {
NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR = 0,
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER = 1,
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS = 2,
NFS4_CHANGE_TYPE_IS_TIME_METADATA = 3,
NFS4_CHANGE_TYPE_IS_UNDEFINED = 4
};
enum change_attr_type4 {
NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR = 0,
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER = 1,
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS = 2,
NFS4_CHANGE_TYPE_IS_TIME_METADATA = 3,
NFS4_CHANGE_TYPE_IS_UNDEFINED = 4
};
<CODE ENDS>
<代码结束>
change_attr_type is a per-file system attribute that enables the NFSv4.2 server to provide additional information about how it expects the change attribute value to evolve after the file data or metadata has changed. While Section 5.4 of [RFC5661] discusses per-file system attributes, it is expected that the value of change_attr_type will not depend on the value of "homogeneous" and will only change in the event of a migration.
change_attr_type是每个文件系统的属性，它使NFSv4.2服务器能够提供有关其期望在文件数据或元数据更改后更改属性值如何变化的附加信息。虽然[RFC5661]的第5.4节讨论了每个文件系统的属性，但预计change_attr_type的值将不取决于“同质”的值，而仅在迁移时更改。
NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR: The change attribute value MUST monotonically increase for every atomic change to the file attributes, data, or directory contents.
NFS4_CHANGE_TYPE_IS_monotional_INCR：对于文件属性、数据或目录内容的每次原子更改，更改属性值必须单调增加。
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER: The change attribute value MUST be incremented by one unit for every atomic change to the file attributes, data, or directory contents. This property is preserved when writing to pNFS data servers.
NFS4_CHANGE_TYPE_IS_VERSION_计数器：对于文件属性、数据或目录内容的每次原子更改，更改属性值必须增加一个单位。此属性在写入pNFS数据服务器时保留。
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS: The change attribute value MUST be incremented by one unit for every atomic change to the file attributes, data, or directory contents. In the case where the client is writing to pNFS data servers, the number of increments is not guaranteed to exactly match the number of WRITEs.
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS：对于文件属性、数据或目录内容的每个原子更改，更改属性值必须增加一个单位。在客户端向pNFS数据服务器写入数据的情况下，增量的数量不能保证与写入的数量完全匹配。
NFS4_CHANGE_TYPE_IS_TIME_METADATA: The change attribute is implemented as suggested in [RFC7530] in terms of the time_metadata attribute.
NFS4_CHANGE_TYPE_是_TIME_元数据：根据时间_元数据属性，按照[RFC7530]中的建议实现CHANGE属性。
NFS4_CHANGE_TYPE_IS_UNDEFINED: The change attribute does not take values that fit into any of these categories.
NFS4_CHANGE_TYPE_未定义：CHANGE属性不接受适合这些类别的值。
If either NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR, NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, or NFS4_CHANGE_TYPE_IS_TIME_METADATA is set, then the client knows at the very least that the change attribute is monotonically increasing, which is sufficient to resolve the question of which value is the most recent.
如果设置了NFS4\u CHANGE\u TYPE\u为单调增量、NFS4\u CHANGE\u TYPE\u为版本计数器或NFS4\u CHANGE\u TYPE\u为时间\u元数据，则客户端至少知道CHANGE属性是单调递增的，这足以解决哪个值是最新值的问题。
If the client sees the value NFS4_CHANGE_TYPE_IS_TIME_METADATA, then by inspecting the value of the "time_delta" attribute it additionally has the option of detecting rogue server implementations that use time_metadata in violation of the specification.
如果客户端看到值NFS4_CHANGE_TYPE_IS_TIME_METADATA，那么通过检查“TIME_delta”属性的值，它还可以选择检测违反规范使用TIME_METADATA的恶意服务器实现。
If the client sees NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, it has the ability to predict what the resulting change attribute value should be after a COMPOUND containing a SETATTR, WRITE, or CREATE. This again allows it to detect changes made in parallel by another client. The value NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS permits the same, but only if the client is not doing pNFS WRITEs.
如果客户端看到NFS4_CHANGE_TYPE_IS_VERSION_计数器，则它能够预测在包含SETATTR、WRITE或CREATE的复合后，结果更改属性值应该是什么。这再次允许它检测由另一个客户端并行进行的更改。值NFS4\u CHANGE\u TYPE\u是\u VERSION\u COUNTER\u NOPNFS允许相同的值，但仅当客户端未进行pNFS写入时。
Finally, if the server does not support change_attr_type or if NFS4_CHANGE_TYPE_IS_UNDEFINED is set, then the server SHOULD make an effort to implement the change attribute in terms of the time_metadata attribute.
最后，如果服务器不支持change\u attr\u type，或者如果设置了NFS4\u change\u type\u IS\u UNDEFINED，那么服务器应该努力根据time\u元数据属性实现change属性。
<CODE BEGINS>
<代码开始>
typedef uint32_t policy4;
typedef uint32_t policy 4；
struct labelformat_spec4 {
policy4 lfs_lfs;
policy4 lfs_pi;
};
struct labelformat_spec4 {
policy4 lfs_lfs;
policy4 lfs_pi;
};
struct sec_label4 {
labelformat_spec4 slai_lfs;
opaque slai_data<>;
};
struct sec_label4 {
labelformat_spec4 slai_lfs;
opaque slai_data<>;
};
<CODE ENDS>
<代码结束>
The FATTR4_SEC_LABEL contains an array of two components, with the first component being an LFS. It serves to provide the receiving end with the information necessary to translate the security attribute into a form that is usable by the endpoint. Label Formats assigned an LFS may optionally choose to include a Policy Identifier field to allow for complex policy deployments. The LFS and the Security Label Format Selection Registry are described in detail in [RFC7569]. The translation used to interpret the security attribute is not specified as part of the protocol, as it may depend on various factors. The second component is an opaque section that contains the data of the attribute. This component is dependent on the MAC model to interpret and enforce.
FATTR4_SEC_标签包含两个组件的数组，第一个组件是LFS。它用于向接收端提供将安全属性转换为端点可用的形式所需的信息。分配给LFS的标签格式可以选择包括策略标识符字段，以允许复杂的策略部署。LFS和安全标签格式选择注册表在[RFC7569]中有详细描述。用于解释安全属性的转换未指定为协议的一部分，因为它可能取决于各种因素。第二个组件是包含属性数据的不透明部分。该组件依赖于MAC模型来解释和实施。
In particular, it is the responsibility of the LFS specification to define a maximum size for the opaque section, slai_data<>. When creating or modifying a label for an object, the client needs to be guaranteed that the server will accept a label that is sized correctly. By both client and server being part of a specific MAC model, the client will be aware of the size.
特别是，LFS规范负责定义不透明部分的最大尺寸，即slai_数据<>。在为对象创建或修改标签时，需要确保客户端能够接受大小正确的标签。由于客户端和服务器都是特定MAC模型的一部分，客户端将知道其大小。
Tables 5 and 6 summarize the operations of the NFSv4.2 protocol and the corresponding designations of REQUIRED, RECOMMENDED, and OPTIONAL to implement or MUST NOT implement. The "MUST NOT implement" designation is reserved for those operations that were defined in either NFSv4.0 or NFSv4.1 and MUST NOT be implemented in NFSv4.2.
表5和表6总结了NFSv4.2协议的操作以及需要、建议和可选实施或不得实施的相应名称。“不得实施”指定保留用于NFSv4.0或NFSv4.1中定义的操作，且不得在NFSv4.2中实施。
For the most part, the REQUIRED, RECOMMENDED, or OPTIONAL designation for operations sent by the client is for the server implementation. The client is generally required to implement the operations needed for the operating environment that it serves. For example, a read-only NFSv4.2 client would have no need to implement the WRITE operation and is not required to do so.
在大多数情况下，客户机发送的操作的必需、推荐或可选名称用于服务器实现。客户机通常需要实现其所服务的操作环境所需的操作。例如，只读NFSv4.2客户端不需要实现写操作，也不需要这样做。
The REQUIRED or OPTIONAL designation for callback operations sent by the server is for both the client and server. Generally, the client has the option of creating the backchannel and sending the operations on the forechannel that will be a catalyst for the server sending callback operations. A partial exception is CB_RECALL_SLOT; the only way the client can avoid supporting this operation is by not creating a backchannel.
由服务器发送的回调操作的必需或可选指定同时适用于客户端和服务器。通常，客户端可以选择创建反向通道并在前通道上发送操作，这将成为服务器发送回调操作的催化剂。部分例外情况是CB_RECALL_插槽；客户端避免支持此操作的唯一方法是不创建反向通道。
Since this is a summary of the operations and their designation, there are subtleties that are not presented here. Therefore, if there is a question regarding implementation requirements, the operation descriptions themselves must be consulted, along with other relevant explanatory text within either this specification or the NFSv4.1 specification [RFC5661].
由于这是操作及其指定的摘要，因此这里没有介绍一些微妙之处。因此，如果存在有关实施要求的问题，必须参考操作说明本身以及本规范或NFSv4.1规范[RFC5661]中的其他相关解释文本。
The abbreviations used in the second and third columns of Tables 5 and 6 are defined as follows:
表5和表6第二列和第三列中使用的缩写定义如下：
REQ: REQUIRED to implement
REQ：需要实现
REC: RECOMMENDED to implement
REC：建议实施
OPT: OPTIONAL to implement
OPT：实现的可选选项
MNI: MUST NOT implement
MNI：不得实施
For the NFSv4.2 features that are OPTIONAL, the operations that support those features are OPTIONAL, and the server MUST return NFS4ERR_NOTSUPP in response to the client's use of those operations when those operations are not implemented by the server. If an OPTIONAL feature is supported, it is possible that a set of operations related to the feature become REQUIRED to implement. The third column of the tables designates the feature(s) and if the operation is REQUIRED or OPTIONAL in the presence of support for the feature.
对于可选的NFSv4.2功能，支持这些功能的操作是可选的，当服务器未实现这些操作时，服务器必须返回NFS4ERR_NOTSUPP以响应客户端对这些操作的使用。如果支持可选功能，则可能需要执行一组与该功能相关的操作。表格的第三列指定了功能，以及在支持该功能的情况下，该操作是必需的还是可选的。
The OPTIONAL features identified and their abbreviations are as follows:
确定的可选功能及其缩写如下：
pNFS: Parallel NFS
pNFS：并行NFS
FDELG: File Delegations
FDELG：文件授权
DDELG: Directory Delegations
目录授权
COPYra: Intra-server Server-Side Copy
COPYra：服务器内部服务器端拷贝
COPYer: Inter-server Server-Side Copy
复制者：服务器间服务器端复制
ADB: Application Data Blocks
ADB：应用程序数据块
+----------------------+--------------------+-----------------------+
| Operation | REQ, REC, OPT, or | Feature (REQ, REC, or |
| | MNI | OPT) |
+----------------------+--------------------+-----------------------+
| ACCESS | REQ | |
| ALLOCATE | OPT | |
| BACKCHANNEL_CTL | REQ | |
| BIND_CONN_TO_SESSION | REQ | |
| CLONE | OPT | |
| CLOSE | REQ | |
| COMMIT | REQ | |
| COPY | OPT | COPYer (REQ), COPYra |
| | | (REQ) |
| COPY_NOTIFY | OPT | COPYer (REQ) |
| CREATE | REQ | |
| CREATE_SESSION | REQ | |
| DEALLOCATE | OPT | |
| DELEGPURGE | OPT | FDELG (REQ) |
| DELEGRETURN | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
| DESTROY_CLIENTID | REQ | |
| DESTROY_SESSION | REQ | |
| EXCHANGE_ID | REQ | |
| FREE_STATEID | REQ | |
| GETATTR | REQ | |
| GETDEVICEINFO | OPT | pNFS (REQ) |
| GETDEVICELIST | MNI | pNFS (MNI) |
| GETFH | REQ | |
| GET_DIR_DELEGATION | OPT | DDELG (REQ) |
| ILLEGAL | REQ | |
| IO_ADVISE | OPT | |
| LAYOUTCOMMIT | OPT | pNFS (REQ) |
| LAYOUTERROR | OPT | pNFS (OPT) |
| LAYOUTGET | OPT | pNFS (REQ) |
| LAYOUTRETURN | OPT | pNFS (REQ) |
| LAYOUTSTATS | OPT | pNFS (OPT) |
| LINK | OPT | |
| LOCK | REQ | |
| LOCKT | REQ | |
| LOCKU | REQ | |
| LOOKUP | REQ | |
| LOOKUPP | REQ | |
| NVERIFY | REQ | |
| OFFLOAD_CANCEL | OPT | COPYer (OPT), COPYra |
| | | (OPT) |
| OFFLOAD_STATUS | OPT | COPYer (OPT), COPYra |
| | | (OPT) |
+----------------------+--------------------+-----------------------+
| Operation | REQ, REC, OPT, or | Feature (REQ, REC, or |
| | MNI | OPT) |
+----------------------+--------------------+-----------------------+
| ACCESS | REQ | |
| ALLOCATE | OPT | |
| BACKCHANNEL_CTL | REQ | |
| BIND_CONN_TO_SESSION | REQ | |
| CLONE | OPT | |
| CLOSE | REQ | |
| COMMIT | REQ | |
| COPY | OPT | COPYer (REQ), COPYra |
| | | (REQ) |
| COPY_NOTIFY | OPT | COPYer (REQ) |
| CREATE | REQ | |
| CREATE_SESSION | REQ | |
| DEALLOCATE | OPT | |
| DELEGPURGE | OPT | FDELG (REQ) |
| DELEGRETURN | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
| DESTROY_CLIENTID | REQ | |
| DESTROY_SESSION | REQ | |
| EXCHANGE_ID | REQ | |
| FREE_STATEID | REQ | |
| GETATTR | REQ | |
| GETDEVICEINFO | OPT | pNFS (REQ) |
| GETDEVICELIST | MNI | pNFS (MNI) |
| GETFH | REQ | |
| GET_DIR_DELEGATION | OPT | DDELG (REQ) |
| ILLEGAL | REQ | |
| IO_ADVISE | OPT | |
| LAYOUTCOMMIT | OPT | pNFS (REQ) |
| LAYOUTERROR | OPT | pNFS (OPT) |
| LAYOUTGET | OPT | pNFS (REQ) |
| LAYOUTRETURN | OPT | pNFS (REQ) |
| LAYOUTSTATS | OPT | pNFS (OPT) |
| LINK | OPT | |
| LOCK | REQ | |
| LOCKT | REQ | |
| LOCKU | REQ | |
| LOOKUP | REQ | |
| LOOKUPP | REQ | |
| NVERIFY | REQ | |
| OFFLOAD_CANCEL | OPT | COPYer (OPT), COPYra |
| | | (OPT) |
| OFFLOAD_STATUS | OPT | COPYer (OPT), COPYra |
| | | (OPT) |
| OPEN | REQ | |
| OPENATTR | OPT | |
| OPEN_CONFIRM | MNI | |
| OPEN_DOWNGRADE | REQ | |
| PUTFH | REQ | |
| PUTPUBFH | REQ | |
| PUTROOTFH | REQ | |
| READ | REQ | |
| READDIR | REQ | |
| READLINK | OPT | |
| READ_PLUS | OPT | |
| RECLAIM_COMPLETE | REQ | |
| RELEASE_LOCKOWNER | MNI | |
| REMOVE | REQ | |
| RENAME | REQ | |
| RENEW | MNI | |
| RESTOREFH | REQ | |
| SAVEFH | REQ | |
| SECINFO | REQ | |
| SECINFO_NO_NAME | REC | pNFS file layout |
| | | (REQ) |
| SEEK | OPT | |
| SEQUENCE | REQ | |
| SETATTR | REQ | |
| SETCLIENTID | MNI | |
| SETCLIENTID_CONFIRM | MNI | |
| SET_SSV | REQ | |
| TEST_STATEID | REQ | |
| VERIFY | REQ | |
| WANT_DELEGATION | OPT | FDELG (OPT) |
| WRITE | REQ | |
| WRITE_SAME | OPT | ADB (REQ) |
+----------------------+--------------------+-----------------------+
| OPEN | REQ | |
| OPENATTR | OPT | |
| OPEN_CONFIRM | MNI | |
| OPEN_DOWNGRADE | REQ | |
| PUTFH | REQ | |
| PUTPUBFH | REQ | |
| PUTROOTFH | REQ | |
| READ | REQ | |
| READDIR | REQ | |
| READLINK | OPT | |
| READ_PLUS | OPT | |
| RECLAIM_COMPLETE | REQ | |
| RELEASE_LOCKOWNER | MNI | |
| REMOVE | REQ | |
| RENAME | REQ | |
| RENEW | MNI | |
| RESTOREFH | REQ | |
| SAVEFH | REQ | |
| SECINFO | REQ | |
| SECINFO_NO_NAME | REC | pNFS file layout |
| | | (REQ) |
| SEEK | OPT | |
| SEQUENCE | REQ | |
| SETATTR | REQ | |
| SETCLIENTID | MNI | |
| SETCLIENTID_CONFIRM | MNI | |
| SET_SSV | REQ | |
| TEST_STATEID | REQ | |
| VERIFY | REQ | |
| WANT_DELEGATION | OPT | FDELG (OPT) |
| WRITE | REQ | |
| WRITE_SAME | OPT | ADB (REQ) |
+----------------------+--------------------+-----------------------+
Table 5: Operations
表5：业务
+-------------------------+------------------+----------------------+
| Operation | REQ, REC, OPT, | Feature (REQ, REC, |
| | or MNI | or OPT) |
+-------------------------+------------------+----------------------+
| CB_GETATTR | OPT | FDELG (REQ) |
| CB_ILLEGAL | REQ | |
| CB_LAYOUTRECALL | OPT | pNFS (REQ) |
| CB_NOTIFY | OPT | DDELG (REQ) |
| CB_NOTIFY_DEVICEID | OPT | pNFS (OPT) |
| CB_NOTIFY_LOCK | OPT | |
| CB_OFFLOAD | OPT | COPYer (REQ), COPYra |
| | | (REQ) |
| CB_PUSH_DELEG | OPT | FDELG (OPT) |
| CB_RECALL | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
| CB_RECALL_ANY | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
| CB_RECALL_SLOT | REQ | |
| CB_RECALLABLE_OBJ_AVAIL | OPT | DDELG, pNFS (REQ) |
| CB_SEQUENCE | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
| CB_WANTS_CANCELLED | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
+-------------------------+------------------+----------------------+
+-------------------------+------------------+----------------------+
| Operation | REQ, REC, OPT, | Feature (REQ, REC, |
| | or MNI | or OPT) |
+-------------------------+------------------+----------------------+
| CB_GETATTR | OPT | FDELG (REQ) |
| CB_ILLEGAL | REQ | |
| CB_LAYOUTRECALL | OPT | pNFS (REQ) |
| CB_NOTIFY | OPT | DDELG (REQ) |
| CB_NOTIFY_DEVICEID | OPT | pNFS (OPT) |
| CB_NOTIFY_LOCK | OPT | |
| CB_OFFLOAD | OPT | COPYer (REQ), COPYra |
| | | (REQ) |
| CB_PUSH_DELEG | OPT | FDELG (OPT) |
| CB_RECALL | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
| CB_RECALL_ANY | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
| CB_RECALL_SLOT | REQ | |
| CB_RECALLABLE_OBJ_AVAIL | OPT | DDELG, pNFS (REQ) |
| CB_SEQUENCE | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
| CB_WANTS_CANCELLED | OPT | FDELG, DDELG, pNFS |
| | | (REQ) |
+-------------------------+------------------+----------------------+
Table 6: Callback Operations
表6：回调操作
<CODE BEGINS>
<代码开始>
/* new */
const EXCHGID4_FLAG_SUPP_FENCE_OPS = 0x00000004;
/* new */
const EXCHGID4_FLAG_SUPP_FENCE_OPS = 0x00000004;
<CODE ENDS>
<代码结束>
Unchanged
不变的
Enterprise applications require guarantees that an operation has either aborted or completed. NFSv4.1 provides this guarantee as long as the session is alive: simply send a SEQUENCE operation on the same slot with a new sequence number, and the successful return of SEQUENCE indicates that the previous operation has completed. However, if the session is lost, there is no way to know when any operations in progress have aborted or completed. In hindsight, the NFSv4.1 specification should have mandated that DESTROY_SESSION either abort or complete all outstanding operations.
企业应用程序需要保证操作已中止或完成。只要会话处于活动状态，NFSv4.1就会提供这种保证：只需在同一插槽上发送一个序列操作，并使用新的序列号，序列的成功返回表示上一个操作已经完成。但是，如果会话丢失，则无法知道正在进行的任何操作何时中止或完成。事后看来，NFSv4.1规范应该要求销毁会话中止或完成所有未完成的操作。
A client SHOULD request the EXCHGID4_FLAG_SUPP_FENCE_OPS capability when it sends an EXCHANGE_ID operation. The server SHOULD set this capability in the EXCHANGE_ID reply whether the client requests it or not. It is the server's return that determines whether this capability is in effect. When it is in effect, the following will occur:
客户端在发送交换ID操作时，应请求EXCHGID4_标志_支持围栏_操作功能。无论客户端是否请求，服务器都应在EXCHANGE\u ID回复中设置此功能。服务器的返回决定此功能是否有效。生效后，将发生以下情况：
o The server will not reply to any DESTROY_SESSION invoked with the client ID until all operations in progress are completed or aborted.
o 在完成或中止所有正在进行的操作之前，服务器不会回复使用客户端ID调用的任何DESTROY_会话。
o The server will not reply to subsequent EXCHANGE_ID operations invoked on the same client owner with a new verifier until all operations in progress on the client ID's session are completed or aborted.
o 在完成或中止客户端ID会话上正在进行的所有操作之前，服务器不会使用新的验证器答复在同一客户端所有者上调用的后续EXCHANGE_ID操作。
o In implementations where the NFS server is deployed as a cluster, it does support client ID trunking, and the EXCHGID4_FLAG_SUPP_FENCE_OPS capability is enabled, then a session ID created on one node of the storage cluster MUST be destroyable via DESTROY_SESSION. In addition, DESTROY_CLIENTID and an EXCHANGE_ID with a new verifier affect all sessions, regardless of what node the sessions were created on.
o 在将NFS服务器部署为群集的实施中，它确实支持客户端ID中继，并且启用了EXCHGID4_标志_支持_围栏_操作功能，则在存储群集的一个节点上创建的会话ID必须可以通过销毁_会话销毁。此外，销毁CLIENTID和带有新验证器的交换ID会影响所有会话，而不管会话是在哪个节点上创建的。
14.2. Operation 48: GETDEVICELIST - Get all device mappings for a file system
14.2. 操作48:GETDEVICELIST-获取文件系统的所有设备映射
<CODE BEGINS>
<代码开始>
struct GETDEVICELIST4args {
/* CURRENT_FH: object belonging to the file system */
layouttype4 gdla_layout_type;
struct GETDEVICELIST4args {
/* CURRENT_FH: object belonging to the file system */
layouttype4 gdla_layout_type;
/* number of device IDs to return */
count4 gdla_maxdevices;
/* number of device IDs to return */
count4 gdla_maxdevices;
nfs_cookie4 gdla_cookie;
verifier4 gdla_cookieverf;
};
nfs_cookie4 gdla_cookie;
verifier4 gdla_cookieverf;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct GETDEVICELIST4resok {
nfs_cookie4 gdlr_cookie;
verifier4 gdlr_cookieverf;
deviceid4 gdlr_deviceid_list<>;
bool gdlr_eof;
};
struct GETDEVICELIST4resok {
nfs_cookie4 gdlr_cookie;
verifier4 gdlr_cookieverf;
deviceid4 gdlr_deviceid_list<>;
bool gdlr_eof;
};
union GETDEVICELIST4res switch (nfsstat4 gdlr_status) {
case NFS4_OK:
GETDEVICELIST4resok gdlr_resok4;
default:
void;
};
union GETDEVICELIST4res switch (nfsstat4 gdlr_status) {
case NFS4_OK:
GETDEVICELIST4resok gdlr_resok4;
default:
void;
};
<CODE ENDS>
<代码结束>
The GETDEVICELIST operation was introduced in [RFC5661] specifically to request a list of devices at file system mount time from block layout type servers. However, the use of the GETDEVICELIST operation introduces a race condition versus notification about changes to pNFS device IDs as provided by CB_NOTIFY_DEVICEID. Implementation experience with block layout servers has shown that there is no need
[RFC5661]中引入了GETDEVICELIST操作，专门用于在文件系统装载时从块布局类型服务器请求设备列表。但是，使用GETDEVICELIST操作会引入竞争条件，而不是CB_NOTIFY_DEVICEID提供的关于pNFS设备ID更改的通知。块布局服务器的实施经验表明，没有必要
for GETDEVICELIST. Clients have to be able to request new devices using GETDEVICEINFO at any time in response to either a new deviceid in LAYOUTGET results or the CB_NOTIFY_DEVICEID callback operation.
对于GETDEVICELIST。客户端必须能够随时使用GETDEVICEINFO请求新设备，以响应LAYOUTGET results中的新设备ID或CB_NOTIFY_设备ID回调操作。
Clients and servers MUST NOT implement the GETDEVICELIST operation.
客户端和服务器不得实现GETDEVICELIST操作。
<CODE BEGINS>
<代码开始>
struct ALLOCATE4args {
/* CURRENT_FH: file */
stateid4 aa_stateid;
offset4 aa_offset;
length4 aa_length;
};
struct ALLOCATE4args {
/* CURRENT_FH: file */
stateid4 aa_stateid;
offset4 aa_offset;
length4 aa_length;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct ALLOCATE4res {
nfsstat4 ar_status;
};
struct ALLOCATE4res {
nfsstat4 ar_status;
};
<CODE ENDS>
<代码结束>
Whenever a client wishes to reserve space for a region in a file, it calls the ALLOCATE operation with the current filehandle set to the filehandle of the file in question, and with the start offset and length in bytes of the region set in aa_offset and aa_length, respectively.
每当客户端希望为文件中的某个区域保留空间时，它都会调用分配操作，将当前filehandle设置为相关文件的filehandle，并将区域的起始偏移量和长度（以字节为单位）分别设置为aa_offset和aa_length。
CURRENT_FH must be a regular file. If CURRENT_FH is not a regular file, the operation MUST fail and return NFS4ERR_WRONG_TYPE.
当前文件必须是常规文件。如果当前文件不是常规文件，则操作必须失败并返回NFS4ERR\U错误类型。
The aa_stateid MUST refer to a stateid that is valid for a WRITE operation and follows the rules for stateids in Sections 8.2.5 and 18.32.3 of [RFC5661].
aa_stateid必须引用对写入操作有效的stateid，并遵循[RFC5661]第8.2.5节和第18.32.3节中的stateid规则。
The server will ensure that backing blocks are reserved to the region specified by aa_offset and aa_length, and that no future writes into this region will return NFS4ERR_NOSPC. If the region lies partially or fully outside the current file size, the file size will be set to aa_offset + aa_length implicitly. If the server cannot guarantee this, it must return NFS4ERR_NOSPC.
服务器将确保备份块保留到aa_offset和aa_length指定的区域，并且将来写入该区域的任何数据都不会返回NFS4ERR_NOSPC。如果区域部分或完全位于当前文件大小之外，则文件大小将隐式设置为aa_offset+aa_length。如果服务器无法保证这一点，则必须返回NFS4ERR_NOSPC。
The ALLOCATE operation can also be used to extend the size of a file if the region specified by aa_offset and aa_length extends beyond the current file size. In that case, any data outside of the previous file size will return zeros when read before data is written to it.
如果aa_offset和aa_length指定的区域超出了当前文件大小，则还可以使用ALLOCATE操作来扩展文件大小。在这种情况下，任何超出先前文件大小的数据在写入数据之前读取时都将返回零。
It is not required that the server allocate the space to the file before returning success. The allocation can be deferred; however, it must be guaranteed that it will not fail for lack of space. The deferral does not result in an asynchronous reply.
在返回成功之前，服务器不需要为文件分配空间。分配可以推迟；但是，必须保证它不会因为空间不足而失败。延迟不会导致异步回复。
The ALLOCATE operation will result in the space_used and space_freed attributes being increased by the number of bytes reserved, unless they were previously reserved or written and not shared.
ALLOCATE操作将导致已使用的space_和已释放的space_属性增加保留的字节数，除非它们以前已保留或写入且未共享。
<CODE BEGINS>
<代码开始>
struct COPY4args {
/* SAVED_FH: source file */
/* CURRENT_FH: destination file */
stateid4 ca_src_stateid;
stateid4 ca_dst_stateid;
offset4 ca_src_offset;
offset4 ca_dst_offset;
length4 ca_count;
bool ca_consecutive;
bool ca_synchronous;
netloc4 ca_source_server<>;
};
struct COPY4args {
/* SAVED_FH: source file */
/* CURRENT_FH: destination file */
stateid4 ca_src_stateid;
stateid4 ca_dst_stateid;
offset4 ca_src_offset;
offset4 ca_dst_offset;
length4 ca_count;
bool ca_consecutive;
bool ca_synchronous;
netloc4 ca_source_server<>;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct write_response4 {
stateid4 wr_callback_id<1>;
length4 wr_count;
stable_how4 wr_committed;
verifier4 wr_writeverf;
};
struct write_response4 {
stateid4 wr_callback_id<1>;
length4 wr_count;
stable_how4 wr_committed;
verifier4 wr_writeverf;
};
struct copy_requirements4 {
bool cr_consecutive;
bool cr_synchronous;
};
struct copy_requirements4 {
bool cr_consecutive;
bool cr_synchronous;
};
struct COPY4resok {
write_response4 cr_response;
copy_requirements4 cr_requirements;
};
struct COPY4resok {
write_response4 cr_response;
copy_requirements4 cr_requirements;
};
union COPY4res switch (nfsstat4 cr_status) {
case NFS4_OK:
COPY4resok cr_resok4;
case NFS4ERR_OFFLOAD_NO_REQS:
copy_requirements4 cr_requirements;
default:
void;
};
union COPY4res switch (nfsstat4 cr_status) {
case NFS4_OK:
COPY4resok cr_resok4;
case NFS4ERR_OFFLOAD_NO_REQS:
copy_requirements4 cr_requirements;
default:
void;
};
<CODE ENDS>
<代码结束>
The COPY operation is used for both intra-server and inter-server copies. In both cases, the COPY is always sent from the client to the destination server of the file copy. The COPY operation requests that a range in the file specified by SAVED_FH be copied to a range in the file specified by CURRENT_FH.
复制操作用于服务器内和服务器间的复制。在这两种情况下，副本始终从客户端发送到文件副本的目标服务器。复制操作要求将保存的\u FH指定的文件中的范围复制到当前\u FH指定的文件中的范围。
Both SAVED_FH and CURRENT_FH must be regular files. If either SAVED_FH or CURRENT_FH is not a regular file, the operation MUST fail and return NFS4ERR_WRONG_TYPE.
保存的_FH和当前的_FH都必须是常规文件。如果保存的\u FH或当前的\u FH不是常规文件，则操作必须失败并返回NFS4ERR\u错误的\u类型。
SAVED_FH and CURRENT_FH must be different files. If SAVED_FH and CURRENT_FH refer to the same file, the operation MUST fail with NFS4ERR_INVAL.
保存的\u FH和当前的\u FH必须是不同的文件。如果保存的\u FH和当前的\u FH引用同一个文件，则操作必须失败，并带有NFS4ERR\u INVAL。
If the request is for an inter-server copy, the source-fh is a filehandle from the source server and the COMPOUND procedure is being executed on the destination server. In this case, the source-fh is a foreign filehandle on the server receiving the COPY request. If either PUTFH or SAVEFH checked the validity of the filehandle, the operation would likely fail and return NFS4ERR_STALE.
如果请求是服务器间副本，则源fh是来自源服务器的文件句柄，并且复合过程正在目标服务器上执行。在这种情况下，源fh是接收复制请求的服务器上的外部文件句柄。如果PUTFH或SAVEFH检查文件句柄的有效性，则操作可能会失败并返回NFS4ERR_STALE。
If a server supports the inter-server copy feature, a PUTFH followed by a SAVEFH MUST NOT return NFS4ERR_STALE for either operation. These restrictions do not pose substantial difficulties for servers. CURRENT_FH and SAVED_FH may be validated in the context of the operation referencing them and an NFS4ERR_STALE error returned for an invalid filehandle at that point.
如果服务器支持服务器间复制功能，则PUTFH后跟SAVEFH不能为任一操作返回NFS4ERR_STALE。这些限制不会给服务器带来实质性的困难。可以在引用当前和保存的文件句柄的操作上下文中验证当前和保存的文件句柄，并在此时为无效的文件句柄返回NFS4ERR\U STALE错误。
The ca_dst_stateid MUST refer to a stateid that is valid for a WRITE operation and follows the rules for stateids in Sections 8.2.5 and 18.32.3 of [RFC5661]. For an inter-server copy, the ca_src_stateid MUST be the cnr_stateid returned from the earlier COPY_NOTIFY operation, while for an intra-server copy ca_src_stateid MUST refer to a stateid that is valid for a READ operation and follows the rules for stateids in Sections 8.2.5 and 18.22.3 of [RFC5661]. If either stateid is invalid, then the operation MUST fail.
ca_dst_stateid必须引用对写入操作有效的stateid，并遵循[RFC5661]第8.2.5节和第18.32.3节中的stateid规则。对于服务器间副本，ca_src_stateid必须是从先前的copy_NOTIFY操作返回的cnr_stateid，而对于服务器内副本，ca_src_stateid必须引用对读取操作有效的stateid，并遵循[RFC5661]第8.2.5节和第18.22.3节中的stateid规则。如果任一stateid无效，则操作必须失败。
The ca_src_offset is the offset within the source file from which the data will be read, the ca_dst_offset is the offset within the destination file to which the data will be written, and the ca_count is the number of bytes that will be copied. An offset of 0 (zero) specifies the start of the file. A count of 0 (zero) requests that all bytes from ca_src_offset through EOF be copied to the destination. If concurrent modifications to the source file overlap with the source file region being copied, the data copied may include all, some, or none of the modifications. The client can use standard NFS operations (e.g., OPEN with OPEN4_SHARE_DENY_WRITE or mandatory byte-range locks) to protect against concurrent modifications if the client is concerned about this. If the source file's EOF is being modified in parallel with a COPY that specifies a count of 0 (zero) bytes, the amount of data copied is implementation dependent (clients may guard against this case by specifying a non-zero count value or preventing modification of the source file as mentioned above).
ca_src_offset是从中读取数据的源文件内的偏移量，ca_dst_offset是将数据写入的目标文件内的偏移量，ca_count是将被复制的字节数。偏移量为0（零）指定文件的开头。计数为0（零）的请求将从ca_src_offset到EOF的所有字节复制到目标。如果对源文件的并发修改与正在复制的源文件区域重叠，则复制的数据可能包括所有、部分或全部修改。客户机可以使用标准NFS操作（例如，使用OPEN4_SHARE_DENY_WRITE或强制字节范围锁打开）来防止并发修改（如果客户机对此感到担忧）。如果源文件的EOF与指定计数为0（零）字节的副本并行修改，则复制的数据量取决于实现（客户端可以通过指定非零计数值或防止如上所述修改源文件来防止这种情况）。
If the source offset or the source offset plus count is greater than the size of the source file, the operation MUST fail with NFS4ERR_INVAL. The destination offset or destination offset plus count may be greater than the size of the destination file. This allows the client to issue parallel copies to implement operations such as
如果源偏移量或源偏移量加上计数大于源文件的大小，则操作必须失败，并显示NFS4ERR_INVAL。目标偏移量或目标偏移量加上计数可能大于目标文件的大小。这允许客户端发布并行副本以实现以下操作：
<CODE BEGINS>
<代码开始>
% cat file1 file2 file3 file4 > dest
%cat文件1文件2文件3文件4>dest
<CODE ENDS>
<代码结束>
If the ca_source_server list is specified, then this is an inter-server COPY operation and the source file is on a remote server. The client is expected to have previously issued a successful COPY_NOTIFY request to the remote source server. The ca_source_server list MUST be the same as the COPY_NOTIFY response's cnr_source_server list. If the client includes the entries from the COPY_NOTIFY response's cnr_source_server list in the ca_source_server list, the source server can indicate a specific copy protocol for the destination server to use by returning a URL that specifies both a protocol service and server name. Server-to-server copy protocol considerations are described in Sections 4.6 and 4.9.1.
如果指定了ca_源服务器列表，则这是一个服务器间复制操作，源文件位于远程服务器上。预期客户端以前已向远程源服务器发出成功的复制通知请求。ca_源服务器列表必须与复制通知响应的cnr_源服务器列表相同。如果客户端在ca_source_服务器列表中包含COPY_NOTIFY响应的cnr_source_服务器列表中的条目，则源服务器可以通过返回指定协议服务和服务器名称的URL来指示目标服务器要使用的特定复制协议。第4.6节和第4.9.1节介绍了服务器到服务器复制协议注意事项。
If ca_consecutive is set, then the client has specified that the copy protocol selected MUST copy bytes in consecutive order from ca_src_offset to ca_count. If the destination server cannot meet this requirement, then it MUST return an error of NFS4ERR_OFFLOAD_NO_REQS and set cr_consecutive to be FALSE. Likewise, if ca_synchronous is set, then the client has required that the copy protocol selected MUST perform a synchronous copy. If the destination server cannot meet this requirement, then it MUST return an error of NFS4ERR_OFFLOAD_NO_REQS and set cr_synchronous to be FALSE.
如果设置了ca_Continuous，则客户端已指定所选的复制协议必须按从ca_src_偏移量到ca_计数的连续顺序复制字节。如果目标服务器无法满足此要求，则它必须返回一个错误NFS4ERR_OFFLOAD_NO_REQS，并将cr_continuoused设置为FALSE。同样，如果设置了ca_synchronous，则客户端要求所选的复制协议必须执行同步复制。如果目标服务器无法满足此要求，则必须返回NFS4ERR_OFFLOAD_NO_REQS错误，并将cr_synchronous设置为FALSE。
If both are set by the client, then the destination SHOULD try to determine if it can respond to both requirements at the same time. If it cannot make that determination, it must set to TRUE the one it can and set to FALSE the other. The client, upon getting an NFS4ERR_OFFLOAD_NO_REQS error, has to examine both cr_consecutive and cr_synchronous against the respective values of ca_consecutive and ca_synchronous to determine the possible requirement not met. It MUST be prepared for the destination server not being able to determine both requirements at the same time.
如果两者都是由客户机设置的，那么目的地应该尝试确定它是否可以同时响应这两个需求。如果它不能做出这样的决定，那么它必须将一个设置为TRUE，另一个设置为FALSE。客户在收到NFS4ERR_卸载_NO_REQS错误后，必须根据ca_Continuous和ca_synchronous的相应值检查cr_Continuous和cr_synchronous，以确定可能未满足的要求。必须为无法同时确定这两个需求的目标服务器做好准备。
Upon receiving the NFS4ERR_OFFLOAD_NO_REQS error, the client has to determine whether it wants to re-request the copy with a relaxed set of requirements or revert to manually copying the data. If it decides to manually copy the data and this is a remote copy, then the client is responsible for informing the source that the earlier COPY_NOTIFY is no longer valid by sending it an OFFLOAD_CANCEL.
在收到NFS4ERR_OFFLOAD_NO_REQS错误后，客户机必须确定是否要使用一组宽松的要求重新请求副本，或者恢复到手动复制数据。如果客户机决定手动复制数据，而这是一个远程复制，则客户机负责通过向其发送卸载取消通知来通知源先前的复制通知不再有效。
If the operation does not result in an immediate failure, the server will return NFS4_OK.
如果操作未导致立即故障，服务器将返回NFS4\u OK。
If the wr_callback_id is returned, this indicates that an asynchronous COPY operation was initiated and a CB_OFFLOAD callback will deliver the final results of the operation. The wr_callback_id stateid is termed a "copy stateid" in this context. The server is given the option of returning the results in a callback because the data may require a relatively long period of time to copy.
如果返回wr_callback_id，则表示启动了异步复制操作，CB_卸载回调将提供操作的最终结果。wr_callback_id stateid在此上下文中称为“copy stateid”。服务器可以选择在回调中返回结果，因为复制数据可能需要较长的时间。
If no wr_callback_id is returned, the operation completed synchronously and no callback will be issued by the server. The completion status of the operation is indicated by cr_status.
如果没有返回wr_callback_id，则操作将同步完成，服务器不会发出任何回调。操作的完成状态由cr_状态指示。
If the copy completes successfully, either synchronously or asynchronously, the data copied from the source file to the destination file MUST appear identical to the NFS client. However, the NFS server's on-disk representation of the data in the source file and destination file MAY differ. For example, the NFS server might encrypt, compress, deduplicate, or otherwise represent the on-disk data in the source and destination files differently.
如果复制成功完成（同步或异步），则从源文件复制到目标文件的数据必须与NFS客户端的数据相同。但是，NFS服务器对源文件和目标文件中的数据的磁盘表示形式可能不同。例如，NFS服务器可能对源文件和目标文件中的磁盘数据进行加密、压缩、重复数据消除或以其他方式表示。
If a failure does occur for a synchronous copy, wr_count will be set to the number of bytes copied to the destination file before the error occurred. If cr_consecutive is TRUE, then the bytes were copied in order. If the failure occurred for an asynchronous copy, then the client will have gotten the notification of the consecutive copy order when it got the copy stateid. It will be able to determine the bytes copied from the coa_bytes_copied in the CB_OFFLOAD argument.
如果同步复制发生故障，wr_count将设置为错误发生前复制到目标文件的字节数。如果cr_continued为TRUE，则按顺序复制字节。如果异步复制发生故障，则客户端在获得复制状态ID时将收到连续复制顺序的通知。它将能够确定从CB_卸载参数中复制的coa_字节_复制的字节数。
In either case, if cr_consecutive was not TRUE, there is no assurance as to exactly which bytes in the range were copied. The client MUST assume that there exists a mixture of the original contents of the range and the new bytes. If the COPY wrote past the end of the file on the destination, then the last byte written to will determine the new file size. The contents of any block not written to and past the original size of the file will be as if a normal WRITE extended the file.
在这两种情况下，如果cr_continuous不为TRUE，则无法确定复制了范围中的哪些字节。客户端必须假定存在范围的原始内容和新字节的混合。如果写入的副本超过了目标上文件的结尾，则写入的最后一个字节将确定新文件的大小。任何未写入并超过文件原始大小的块的内容都将像正常写入扩展文件一样。
15.3. Operation 61: COPY_NOTIFY - Notify a source server of a future copy
15.3. 操作61：复制通知-通知源服务器未来的复制
<CODE BEGINS>
<代码开始>
struct COPY_NOTIFY4args {
/* CURRENT_FH: source file */
stateid4 cna_src_stateid;
netloc4 cna_destination_server;
};
struct COPY_NOTIFY4args {
/* CURRENT_FH: source file */
stateid4 cna_src_stateid;
netloc4 cna_destination_server;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct COPY_NOTIFY4resok {
nfstime4 cnr_lease_time;
stateid4 cnr_stateid;
netloc4 cnr_source_server<>;
};
struct COPY_NOTIFY4resok {
nfstime4 cnr_lease_time;
stateid4 cnr_stateid;
netloc4 cnr_source_server<>;
};
union COPY_NOTIFY4res switch (nfsstat4 cnr_status) {
case NFS4_OK:
COPY_NOTIFY4resok resok4;
default:
void;
};
union COPY_NOTIFY4res switch (nfsstat4 cnr_status) {
case NFS4_OK:
COPY_NOTIFY4resok resok4;
default:
void;
};
<CODE ENDS>
<代码结束>
This operation is used for an inter-server copy. A client sends this operation in a COMPOUND request to the source server to authorize a destination server identified by cna_destination_server to read the file specified by CURRENT_FH on behalf of the given user.
此操作用于服务器间副本。客户端以复合请求的形式向源服务器发送此操作，以授权由cna_destination_server标识的目标服务器代表给定用户读取当前_FH指定的文件。
The cna_src_stateid MUST refer to either open or locking states provided earlier by the server. If it is invalid, then the operation MUST fail.
cna_src_stateid必须引用服务器先前提供的打开或锁定状态。如果无效，则操作必须失败。
The cna_destination_server MUST be specified using the netloc4 network location format. The server is not required to resolve the cna_destination_server address before completing this operation.
必须使用netloc4网络位置格式指定cna_目的地_服务器。在完成此操作之前，服务器无需解析cna_目的地_服务器地址。
If this operation succeeds, the source server will allow the cna_destination_server to copy the specified file on behalf of the given user as long as both of the following conditions are met:
如果此操作成功，只要满足以下两个条件，源服务器将允许cna_destination_服务器代表给定用户复制指定的文件：
o The destination server begins reading the source file before the cnr_lease_time expires. If the cnr_lease_time expires while the destination server is still reading the source file, the destination server is allowed to finish reading the file. If the cnr_lease_time expires before the destination server uses READ or READ_PLUS to begin the transfer, the source server can use NFS4ERR_PARTNER_NO_AUTH to inform the destination server that the cnr_lease_time has expired.
o 目标服务器在cnr_租约时间到期之前开始读取源文件。如果在目标服务器仍在读取源文件时cnr_lease_时间过期，则允许目标服务器完成读取该文件。如果在目标服务器使用READ或READ\u PLUS开始传输之前cnr\u lease\u时间过期，则源服务器可以使用NFS4ERR\u PARTNER\u NO\u AUTH通知目标服务器cnr\u lease\u时间已过期。
o The client has not issued an OFFLOAD_CANCEL for the same combination of user, filehandle, and destination server.
o 客户端尚未为用户、文件句柄和目标服务器的相同组合发出卸载\u取消。
The cnr_lease_time is chosen by the source server. A cnr_lease_time of 0 (zero) indicates an infinite lease. To avoid the need for synchronized clocks, copy lease times are granted by the server as a time delta. To renew the copy lease time, the client should resend the same copy notification request to the source server.
cnr_租赁时间由源服务器选择。cnr_租约时间为0（零）表示无限租约。为了避免需要同步时钟，服务器将复制租用时间作为时间增量授予。要续订副本租用时间，客户端应向源服务器重新发送相同的副本通知请求。
The cnr_stateid is a copy stateid that uniquely describes the state needed on the source server to track the proposed COPY. As defined in Section 8.2 of [RFC5661], a stateid is tied to the current filehandle, and if the same stateid is presented by two different clients, it may refer to different states. As the source does not know which netloc4 network location the destination might use to establish the COPY operation, it can use the cnr_stateid to identify that the destination is operating on behalf of the client. Thus, the source server MUST construct copy stateids such that they are distinct from all other stateids handed out to clients. These copy stateids MUST denote the same set of locks as each of the earlier delegation, locking, and open states for the client on the given file (see Section 4.3.1).
cnr_stateid是一个副本stateid，它唯一地描述源服务器上跟踪建议副本所需的状态。如[RFC5661]第8.2节所定义，stateid绑定到当前文件句柄，如果两个不同的客户端呈现相同的stateid，则它可能引用不同的状态。由于源不知道目标可能使用哪个netloc4网络位置来建立复制操作，因此它可以使用cnr_stateid来标识目标代表客户端运行。因此，源服务器必须构造副本stateID，以便它们与分发给客户端的所有其他stateID不同。这些复制状态ID必须表示与给定文件上客户端的每个早期委派、锁定和打开状态相同的锁集（请参阅第4.3.1节）。
A successful response will also contain a list of netloc4 network location formats called cnr_source_server, on which the source is willing to accept connections from the destination. These might not be reachable from the client and might be located on networks to which the client has no connection.
成功的响应还将包含一个名为cnr_source_server的netloc4网络位置格式列表，源愿意在其上接受来自目标的连接。这些可能无法从客户端访问，并且可能位于客户端没有连接的网络上。
This operation is unnecessary for an intra-server copy.
对于服务器内副本，此操作是不必要的。
<CODE BEGINS>
<代码开始>
struct DEALLOCATE4args {
/* CURRENT_FH: file */
stateid4 da_stateid;
offset4 da_offset;
length4 da_length;
};
struct DEALLOCATE4args {
/* CURRENT_FH: file */
stateid4 da_stateid;
offset4 da_offset;
length4 da_length;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct DEALLOCATE4res {
nfsstat4 dr_status;
};
struct DEALLOCATE4res {
nfsstat4 dr_status;
};
<CODE ENDS>
<代码结束>
Whenever a client wishes to unreserve space for a region in a file, it calls the DEALLOCATE operation with the current filehandle set to the filehandle of the file in question, and with the start offset and length in bytes of the region set in da_offset and da_length, respectively. If no space was allocated or reserved for all or parts of the region, the DEALLOCATE operation will have no effect for the region that already is in unreserved state. All further READs from the region passed to DEALLOCATE MUST return zeros until overwritten.
每当客户端希望为文件中的某个区域取消保留空间时，它都会调用解除分配操作，将当前文件句柄设置为相关文件的文件句柄，并将区域的起始偏移量和长度（以字节为单位）分别设置为da_offset和da_length。如果没有为区域的全部或部分分配或保留空间，则解除分配操作将对已处于未保留状态的区域无效。从传递给解除分配的区域中进一步读取的所有数据必须返回零，直到被覆盖。
CURRENT_FH must be a regular file. If CURRENT_FH is not a regular file, the operation MUST fail and return NFS4ERR_WRONG_TYPE.
当前文件必须是常规文件。如果当前文件不是常规文件，则操作必须失败并返回NFS4ERR\U错误类型。
The da_stateid MUST refer to a stateid that is valid for a WRITE operation and follows the rules for stateids in Sections 8.2.5 and 18.32.3 of [RFC5661].
da_stateid必须引用对写入操作有效的stateid，并遵循[RFC5661]第8.2.5节和第18.32.3节中的stateid规则。
Situations may arise where da_offset and/or da_offset + da_length will not be aligned to a boundary for which the server does allocations or deallocations. For most file systems, this is the block size of the file system. In such a case, the server can deallocate as many bytes as it can in the region. The blocks that cannot be deallocated MUST be zeroed.
可能会出现这样的情况：da_offset和/或da_offset+da_length将不与服务器进行分配或解除分配的边界对齐。对于大多数文件系统，这是文件系统的块大小。在这种情况下，服务器可以在该区域中释放尽可能多的字节。无法解除分配的块必须归零。
DEALLOCATE will result in the space_used attribute being decreased by the number of bytes that were deallocated. The space_freed attribute may or may not decrease, depending on the support and whether the blocks backing the specified range were shared or not. The size attribute will remain unchanged.
取消分配将导致“已使用的空间”属性减少已取消分配的字节数。“释放的空间”属性可能会减少，也可能不会减少，具体取决于支持指定范围的块是否共享。“大小”属性将保持不变。
15.5. Operation 63: IO_ADVISE - Send client I/O access pattern hints to the server
15.5. 操作63:IO_advice-向服务器发送客户端I/O访问模式提示
<CODE BEGINS>
<代码开始>
enum IO_ADVISE_type4 {
IO_ADVISE4_NORMAL = 0,
IO_ADVISE4_SEQUENTIAL = 1,
IO_ADVISE4_SEQUENTIAL_BACKWARDS = 2,
IO_ADVISE4_RANDOM = 3,
IO_ADVISE4_WILLNEED = 4,
IO_ADVISE4_WILLNEED_OPPORTUNISTIC = 5,
IO_ADVISE4_DONTNEED = 6,
IO_ADVISE4_NOREUSE = 7,
IO_ADVISE4_READ = 8,
IO_ADVISE4_WRITE = 9,
IO_ADVISE4_INIT_PROXIMITY = 10
};
enum IO_ADVISE_type4 {
IO_ADVISE4_NORMAL = 0,
IO_ADVISE4_SEQUENTIAL = 1,
IO_ADVISE4_SEQUENTIAL_BACKWARDS = 2,
IO_ADVISE4_RANDOM = 3,
IO_ADVISE4_WILLNEED = 4,
IO_ADVISE4_WILLNEED_OPPORTUNISTIC = 5,
IO_ADVISE4_DONTNEED = 6,
IO_ADVISE4_NOREUSE = 7,
IO_ADVISE4_READ = 8,
IO_ADVISE4_WRITE = 9,
IO_ADVISE4_INIT_PROXIMITY = 10
};
struct IO_ADVISE4args {
/* CURRENT_FH: file */
stateid4 iaa_stateid;
offset4 iaa_offset;
length4 iaa_count;
bitmap4 iaa_hints;
};
struct IO_ADVISE4args {
/* CURRENT_FH: file */
stateid4 iaa_stateid;
offset4 iaa_offset;
length4 iaa_count;
bitmap4 iaa_hints;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct IO_ADVISE4resok {
bitmap4 ior_hints;
};
struct IO_ADVISE4resok {
bitmap4 ior_hints;
};
union IO_ADVISE4res switch (nfsstat4 ior_status) {
case NFS4_OK:
IO_ADVISE4resok resok4;
default:
void;
};
union IO_ADVISE4res switch (nfsstat4 ior_status) {
case NFS4_OK:
IO_ADVISE4resok resok4;
default:
void;
};
<CODE ENDS>
<代码结束>
The IO_ADVISE operation sends an I/O access pattern hint to the server for the owner of the stateid for a given byte range specified by iar_offset and iar_count. The byte range specified by iaa_offset and iaa_count need not currently exist in the file, but the iaa_hints will apply to the byte range when it does exist. If iaa_count is 0, all data following iaa_offset is specified. The server MAY ignore the advice.
IO_advice操作向服务器发送一个I/O访问模式提示，提示stateid的所有者在iar_偏移量和iar_计数指定的给定字节范围内。iaa_offset和iaa_count指定的字节范围当前不需要存在于文件中，但iaa_提示将应用于确实存在的字节范围。如果iaa_计数为0，则指定iaa_偏移后的所有数据。服务器可能会忽略该建议。
The following are the allowed hints for a stateid holder:
以下是stateid持有者允许的提示：
IO_ADVISE4_NORMAL There is no advice to give. This is the default behavior.
IO_建议4_正常情况下，没有建议可提供。这是默认行为。
IO_ADVISE4_SEQUENTIAL Expects to access the specified data sequentially from lower offsets to higher offsets.
IO_Advised 4_SEQUENTIAL期望从较低偏移量到较高偏移量依次访问指定数据。
IO_ADVISE4_SEQUENTIAL_BACKWARDS Expects to access the specified data sequentially from higher offsets to lower offsets.
IO_Advise 4_SEQUENTIAL_Backward希望按顺序从较高偏移量到较低偏移量访问指定数据。
IO_ADVISE4_RANDOM Expects to access the specified data in a random order.
IO_Advise 4_RANDOM希望以随机顺序访问指定的数据。
IO_ADVISE4_WILLNEED Expects to access the specified data in the near future.
IO_Advised 4_WILLNEED希望在不久的将来访问指定的数据。
IO_ADVISE4_WILLNEED_OPPORTUNISTIC Expects to possibly access the data in the near future. This is a speculative hint, and therefore the server should prefetch data or indirect blocks only if it can be done at a marginal cost.
IO_Advised 4_将需要_Opportunity，希望在不久的将来访问数据。这是一个推测性的提示，因此只有在能够以边际成本完成的情况下，服务器才应该预取数据或间接块。
IO_ADVISE_DONTNEED Expects that it will not access the specified data in the near future.
IO_advice_DONTNEED预计它在不久的将来不会访问指定的数据。
IO_ADVISE_NOREUSE Expects to access the specified data once and then not reuse it thereafter.
IO_ADVISE_NOREUSE希望访问指定的数据一次，然后不再重复使用。
IO_ADVISE4_READ Expects to read the specified data in the near future.
IO_Advise 4_READ希望在不久的将来读取指定的数据。
IO_ADVISE4_WRITE Expects to write the specified data in the near future.
IO_Advise 4_WRITE希望在不久的将来写入指定的数据。
IO_ADVISE4_INIT_PROXIMITY Informs the server that the data in the byte range remains important to the client.
IO_advision4_INIT_proximition通知服务器字节范围内的数据对客户端仍然很重要。
Since IO_ADVISE is a hint, a server SHOULD NOT return an error and invalidate an entire COMPOUND request if one of the sent hints in iar_hints is not supported by the server. Also, the server MUST NOT return an error if the client sends contradictory hints to the server, e.g., IO_ADVISE4_SEQUENTIAL and IO_ADVISE4_RANDOM in a single IO_ADVISE operation. In these cases, the server MUST return success and an ior_hints value that indicates the hint it intends to implement. This may mean simply returning IO_ADVISE4_NORMAL.
由于IO_advice是一个提示，如果服务器不支持iar_提示中发送的提示之一，则服务器不应返回错误并使整个复合请求无效。此外，如果客户端向服务器发送相互矛盾的提示，例如，在单个IO_advision操作中IO_advision4_SEQUENTIAL和IO_advision4_RANDOM，则服务器不得返回错误。在这些情况下，服务器必须返回success和一个ior_hints值，该值指示它打算实现的提示。这可能意味着只需恢复IO_Advised 4_正常。
The ior_hints returned by the server is primarily for debugging purposes, since the server is under no obligation to carry out the hints that it describes in the ior_hints result. In addition, while the server may have intended to implement the hints returned in ior_hints, the server may need to change its handling of a given file -- for example, because of memory pressure, additional IO_ADVISE hints sent by other clients, or heuristically detected file access patterns.
服务器返回的ior_提示主要用于调试目的，因为服务器没有义务执行ior_提示结果中描述的提示。此外，虽然服务器可能打算实现ior_提示中返回的提示，但服务器可能需要更改其对给定文件的处理方式——例如，由于内存压力、其他客户端发送的其他IO_提示或启发式检测的文件访问模式。
The server MAY return different advice than what the client requested. Some examples include another client advising of a different I/O access pattern, another client employing a different I/O access pattern, or inability of the server to support the requested I/O access pattern.
服务器可能会返回与客户端请求不同的建议。一些示例包括建议不同I/O访问模式的另一客户端、采用不同I/O访问模式的另一客户端，或者服务器无法支持请求的I/O访问模式。
Each issuance of the IO_ADVISE operation overrides all previous issuances of IO_ADVISE for a given byte range. This effectively follows a strategy of "last hint wins" for a given stateid and byte range.
每次发出IO_advice操作都会覆盖给定字节范围内以前发出的所有IO_advice。对于给定的stateid和字节范围，这实际上遵循了“最后提示获胜”的策略。
Clients should assume that hints included in an IO_ADVISE operation will be forgotten once the file is closed.
客户端应假定IO_advice操作中包含的提示在文件关闭后将被遗忘。
The NFS client may choose to issue an IO_ADVISE operation to the server in several different instances.
NFS客户端可以选择在几个不同的实例中向服务器发出IO_advice操作。
The most obvious is in direct response to an application's execution of posix_fadvise(). In this case, IO_ADVISE4_WRITE and IO_ADVISE4_READ may be set, based upon the type of file access specified when the file was opened.
最明显的是直接响应应用程序执行posix_fadvise（）。在这种情况下，可以根据打开文件时指定的文件访问类型设置IO_ADVISE4_写入和IO_ADVISE4_读取。
The IO_ADVISE4_INIT_PROXIMITY hint is non-POSIX in origin and can be used to convey that the client has recently accessed the byte range in its own cache. That is, it has not accessed it on the server but has accessed it locally. When the server reaches resource exhaustion, knowing which data is more important allows the server to make better choices about which data to, for example, purge from a cache or move to secondary storage. It also informs the server as to which delegations are more important, because if delegations are working correctly, once delegated to a client and the client has read the content for that byte range, a server might never receive another READ request for that byte range.
IO_advision4_INIT_接近提示在源代码中是非POSIX的，可用于表示客户端最近访问了其自身缓存中的字节范围。也就是说，它没有在服务器上访问它，而是在本地访问它。当服务器资源耗尽时，知道哪些数据更重要，可以让服务器更好地选择要从缓存中清除哪些数据或将哪些数据移动到辅助存储。它还通知服务器哪些委派更重要，因为如果委派工作正常，一旦委派给客户机且客户机已读取该字节范围的内容，服务器可能永远不会收到该字节范围的另一个读取请求。
The IO_ADVISE4_INIT_PROXIMITY hint can also be used in a pNFS setting to let the client inform the metadata server as to the I/O statistics between the client and the storage devices. The metadata server is then free to use this information about client I/O to optimize the data storage location.
IO_advision4_INIT_邻近提示也可以在pNFS设置中使用，以让客户端将客户端和存储设备之间的I/O统计信息通知元数据服务器。然后，元数据服务器可以自由地使用有关客户端I/O的这些信息来优化数据存储位置。
This hint is also useful in the case of NFS clients that are network-booting from a server. If the first client to be booted sends this hint, then it keeps the cache warm for the remaining clients.
对于从服务器进行网络引导的NFS客户端，此提示也很有用。如果要引导的第一个客户机发送此提示，则它会为其余客户机保持缓存温度。
The IO_ADVISE considerations for pNFS are very similar to the COMMIT considerations for pNFS (see Section 13.7 of [RFC5661]). That is, as with COMMIT, some NFS server implementations prefer that IO_ADVISE be done on the storage device, and some prefer that it be done on the metadata server.
PNF的IO_ADVISE注意事项与PNF的提交注意事项非常相似（参见[RFC5661]第13.7节）。也就是说，与提交一样，一些NFS服务器实现更喜欢在存储设备上执行IO_advice，而一些NFS服务器实现更喜欢在元数据服务器上执行IO_advice。
For the file's layout type, NFSv4.2 includes an additional hint, NFL42_CARE_IO_ADVISE_THRU_MDS, which is valid only on metadata servers running NFSv4.2 or higher. ("NFL" stands for "NFS File Layout".) Any file's layout obtained from an NFSv4.1 metadata server MUST NOT have NFL42_UFLG_IO_ADVISE_THRU_MDS set. Any file's layout
对于文件的布局类型，NFSv4.2包含一个附加提示NFL42_CARE_IO_advice_THRU_MDS，该提示仅在运行NFSv4.2或更高版本的元数据服务器上有效。（“NFL”代表“NFS文件布局”。）从NFSv4.1元数据服务器获得的任何文件布局不得设置NFL42\u UFLG\u IO\u advice\u THRU\u MDS。任何文件的布局
obtained with an NFSv4.2 metadata server MAY have NFL42_UFLG_IO_ADVISE_THRU_MDS set. However, if the layout utilizes NFSv4.1 storage devices, the IO_ADVISE operation cannot be sent to them.
通过NFSv4.2元数据服务器获得的数据可能具有NFL42_UFLG_IO_advision_THRU_MDS集。但是，如果布局使用NFSv4.1存储设备，则无法向其发送IO_advice操作。
If NFL42_UFLG_IO_ADVISE_THRU_MDS is set, the client MUST send the IO_ADVISE operation to the metadata server in order for it to be honored by the storage device. Once the metadata server receives the IO_ADVISE operation, it will communicate the advice to each storage device.
如果设置了NFL42_UFLG_IO_advice_THRU_MDS，则客户端必须将IO_advice操作发送到元数据服务器，以便存储设备执行该操作。一旦元数据服务器接收到IO_advice操作，它将向每个存储设备传递该建议。
If NFL42_UFLG_IO_ADVISE_THRU_MDS is not set, then the client SHOULD send an IO_ADVISE operation to the appropriate storage device for the specified byte range. While the client MAY always send IO_ADVISE to the metadata server, if the server has not set NFL42_UFLG_IO_ADVISE_THRU_MDS, the client should expect that such an IO_ADVISE is futile. Note that a client SHOULD use the same set of arguments on each IO_ADVISE sent to a storage device for the same open file reference.
如果未设置NFL42_UFLG_IO_advice_THRU_MDS，则客户端应向指定字节范围内的相应存储设备发送IO_advice操作。虽然客户端可能总是向元数据服务器发送IO_建议，但如果服务器未通过MDS设置NFL42_UFLG_IO_建议，则客户端应该认为这样的IO_建议是无效的。请注意，对于相同的打开文件引用，客户端应在发送到存储设备的每个IO_通知上使用相同的参数集。
The server is not required to support different advice for different storage devices with the same open file reference.
对于具有相同打开文件引用的不同存储设备，服务器不需要支持不同的建议。
The IO_ADVISE operation MUST use the iar_offset and byte range as dictated by the presence or absence of NFL4_UFLG_DENSE (see Section 13.4.4 of [RFC5661]).
IO_advice操作必须使用iar_偏移量和字节范围，取决于是否存在NFL4_UFLG_密集（见[RFC5661]第13.4.4节）。
For example, if NFL4_UFLG_DENSE is present, then (1) a READ or WRITE to the storage device for iaa_offset 0 really means iaa_offset 10000 in the logical file and (2) an IO_ADVISE for iaa_offset 0 means iaa_offset 10000 in the logical file.
例如，如果存在NFL4_UFLG_DENSE，则（1）对存储设备的iaa_偏移量0的读或写实际上意味着逻辑文件中的iaa_偏移量10000，（2）iaa_偏移量0的IO_建议意味着逻辑文件中的iaa_偏移量10000。
For example, if NFL4_UFLG_DENSE is absent, then (1) a READ or WRITE to the storage device for iaa_offset 0 really means iaa_offset 0 in the logical file and (2) an IO_ADVISE for iaa_offset 0 means iaa_offset 0 in the logical file.
例如，如果不存在NFL4_UFLG_DENSE，则（1）对存储设备的iaa_偏移量0的读取或写入实际上意味着逻辑文件中的iaa_偏移量0，（2）iaa_偏移量0的IO_通知意味着逻辑文件中的iaa_偏移量0。
For example, if NFL4_UFLG_DENSE is present, the stripe unit is 1000 bytes and the stripe count is 10, and the dense storage device file is serving iar_offset 0. A READ or WRITE to the storage device for iaa_offsets 0, 1000, 2000, and 3000 really means iaa_offsets 10000, 20000, 30000, and 40000 (implying a stripe count of 10 and a stripe unit of 1000), and then an IO_ADVISE sent to the same storage device with an iaa_offset of 500 and an iaa_count of 3000 means that the IO_ADVISE applies to these byte ranges of the dense storage device file:
例如，如果存在NFL4_UFLG_DENSE，则条带单位为1000字节，条带计数为10，且密集存储设备文件的iar_偏移量为0。对存储设备的iaa_偏移量0、1000、2000和3000的读写实际上意味着iaa_偏移量10000、20000、30000和40000（意味着条带计数为10，条带单位为1000），然后，发送到同一存储设备且iaa_偏移量为500且iaa_计数为3000的IO_建议意味着IO_建议适用于密集存储设备文件的这些字节范围：
- 500 to 999 - 1000 to 1999 - 2000 to 2999 - 3000 to 3499
- 500至999-1000至1999-2000至2999-3000至3499
That is, the contiguous range 500 to 3499, as specified in IO_ADVISE.
也就是说，IO_ADVISE中规定的连续范围为500到3499。
It also applies to these byte ranges of the logical file:
它也适用于逻辑文件的这些字节范围：
- 10500 to 10999 (500 bytes) - 20000 to 20999 (1000 bytes) - 30000 to 30999 (1000 bytes) - 40000 to 40499 (500 bytes) (total 3000 bytes)
- 10500至10999（500字节）-20000至20999（1000字节）-30000至30999（1000字节）-40000至40499（500字节）（总计3000字节）
For example, if NFL4_UFLG_DENSE is absent, the stripe unit is 250 bytes, the stripe count is 4, and the sparse storage device file is serving iaa_offset 0. Then, a READ or WRITE to the storage device for iaa_offsets 0, 1000, 2000, and 3000 really means iaa_offsets 0, 1000, 2000, and 3000 in the logical file, keeping in mind that in the storage device file byte ranges 250 to 999, 1250 to 1999, 2250 to 2999, and 3250 to 3999 are not accessible. Then, an IO_ADVISE sent to the same storage device with an iaa_offset of 500 and an iaa_count of 3000 means that the IO_ADVISE applies to these byte ranges of the logical file and the sparse storage device file:
例如，如果不存在NFL4_UFLG_DENSE，则条带单元为250字节，条带计数为4，稀疏存储设备文件为iaa_偏移量0提供服务。然后，对存储设备的iaa_偏移量0、1000、2000和3000的读取或写入实际上意味着逻辑文件中的iaa_偏移量0、1000、2000和3000，请记住，在存储设备文件中，字节范围250到999、1250到1999、2250到2999以及3250到3999是不可访问的。然后，发送到iaa_偏移量为500且iaa_计数为3000的同一存储设备的IO_建议意味着IO_建议适用于逻辑文件和稀疏存储设备文件的这些字节范围：
- 500 to 999 (500 bytes) - no effect
- 1000 to 1249 (250 bytes) - effective
- 1250 to 1999 (750 bytes) - no effect
- 2000 to 2249 (250 bytes) - effective
- 2250 to 2999 (750 bytes) - no effect
- 3000 to 3249 (250 bytes) - effective
- 3250 to 3499 (250 bytes) - no effect
(subtotal 2250 bytes) - no effect
(subtotal 750 bytes) - effective
(grand total 3000 bytes) - no effect + effective
- 500 to 999 (500 bytes) - no effect
- 1000 to 1249 (250 bytes) - effective
- 1250 to 1999 (750 bytes) - no effect
- 2000 to 2249 (250 bytes) - effective
- 2250 to 2999 (750 bytes) - no effect
- 3000 to 3249 (250 bytes) - effective
- 3250 to 3499 (250 bytes) - no effect
(subtotal 2250 bytes) - no effect
(subtotal 750 bytes) - effective
(grand total 3000 bytes) - no effect + effective
If neither the NFL42_UFLG_IO_ADVISE_THRU_MDS flag nor the NFL4_UFLG_DENSE flag is set in the layout, then any IO_ADVISE request sent to the data server with a byte range that overlaps stripe units that the data server does not serve MUST NOT result in the status NFS4ERR_PNFS_IO_HOLE. Instead, the response SHOULD be successful, and if the server applies IO_ADVISE hints on any stripe units that overlap with the specified range, those hints SHOULD be indicated in the response.
如果布局中未设置NFL42_UFLG_IO_advice_THRU_MDS标志或NFL4_UFLG_densite标志，则发送到数据服务器的任何IO_advice请求（其字节范围与数据服务器不提供服务的条带单元重叠）不得导致状态NFS4ERR_PNFS_IO_。相反，响应应该是成功的，如果服务器对与指定范围重叠的任何条带单元应用IO_advice提示，则这些提示应该在响应中指示。
<CODE BEGINS>
<代码开始>
struct device_error4 {
deviceid4 de_deviceid;
nfsstat4 de_status;
nfs_opnum4 de_opnum;
};
struct device_error4 {
deviceid4 de_deviceid;
nfsstat4 de_status;
nfs_opnum4 de_opnum;
};
struct LAYOUTERROR4args {
/* CURRENT_FH: file */
offset4 lea_offset;
length4 lea_length;
stateid4 lea_stateid;
device_error4 lea_errors<>;
};
struct LAYOUTERROR4args {
/* CURRENT_FH: file */
offset4 lea_offset;
length4 lea_length;
stateid4 lea_stateid;
device_error4 lea_errors<>;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct LAYOUTERROR4res {
nfsstat4 ler_status;
};
struct LAYOUTERROR4res {
nfsstat4 ler_status;
};
<CODE ENDS>
<代码结束>
The client can use LAYOUTERROR to inform the metadata server about errors in its interaction with the layout (see Section 12 of [RFC5661]) represented by the current filehandle, client ID (derived from the session ID in the preceding SEQUENCE operation), byte range (lea_offset + lea_length), and lea_stateid.
客户机可以使用LAYOUTERROR通知元数据服务器其与布局交互中的错误（请参阅[RFC5661]的第12节），这些错误由当前文件句柄、客户机ID（源自前面序列操作中的会话ID）、字节范围（leau offset+leau length）和leau stateid表示。
Each individual device_error4 describes a single error associated with a storage device, which is identified via de_deviceid. If the layout type (see Section 12.2.7 of [RFC5661]) supports NFSv4 operations, then the operation that returned the error is identified via de_opnum. If the layout type does not support NFSv4 operations, then either (1) it MAY choose to map the operation onto one of the allowed operations that can be sent to a storage device with the file layout type (see Section 3.3) or (2) it can signal no support for operations by marking de_opnum with the ILLEGAL operation. Finally, the NFS error value (nfsstat4) encountered is provided via de_status and may consist of the following error codes:
每个单独的设备错误4描述了与存储设备相关的单个错误，该错误通过de_deviceid识别。如果布局类型（参见[RFC5661]第12.2.7节）支持NFSv4操作，则返回错误的操作通过de_opnum进行识别。如果布局类型不支持NFSv4操作，则（1）它可以选择将操作映射到允许的操作之一，该操作可以发送到具有文件布局类型的存储设备（参见第3.3节），或者（2）它可以通过使用非法操作标记de_opnum来表示不支持操作。最后，遇到的NFS错误值（nfsstat4）通过de_status提供，可能由以下错误代码组成：
NFS4ERR_NXIO: The client was unable to establish any communication with the storage device.
NFS4ERR_NXIO:客户端无法与存储设备建立任何通信。
NFS4ERR_*: The client was able to establish communication with the storage device and is returning one of the allowed error codes for the operation denoted by de_opnum.
NFS4ERR_u*：客户端能够与存储设备建立通信，并且正在返回由de_opnum表示的操作允许的错误代码之一。
Note that while the metadata server may return an error associated with the layout stateid or the open file, it MUST NOT return an error in the processing of the errors. If LAYOUTERROR is in a COMPOUND before LAYOUTRETURN, it MUST NOT introduce an error other than what LAYOUTRETURN would already encounter.
请注意，虽然元数据服务器可能返回与布局stateid或打开的文件相关联的错误，但在处理错误时不得返回错误。如果LAYOUTERROR位于LAYOUTRETURN之前的化合物中，则除了LAYOUTRETURN已经遇到的错误外，它不得引入其他错误。
There are two broad classes of errors: transient and persistent. The client SHOULD strive to only use this new mechanism to report persistent errors. It MUST be able to deal with transient issues by itself. Also, while the client might consider an issue to be persistent, it MUST be prepared for the metadata server to consider such issues to be transient. A prime example of this is if the metadata server fences off a client from either a stateid or a filehandle. The client will get an error from the storage device and might relay either NFS4ERR_ACCESS or NFS4ERR_BAD_STATEID back to the metadata server, with the belief that this is a hard error. If the metadata server is informed by the client that there is an error, it can safely ignore that. For the metadata server, the mission is accomplished in that the client has returned a layout that the metadata server had most likely recalled.
有两大类错误：暂时性错误和持续性错误。客户机应该努力只使用这种新机制来报告持续性错误。它必须能够自己处理暂时的问题。此外，虽然客户端可能认为问题是持久的，但必须准备好元数据服务器考虑这些问题是暂时的。这方面的一个主要示例是元数据服务器将客户机与stateid或filehandle隔离开来。客户端将从存储设备获得错误，并且可能会将NFS4ERR_访问或NFS4ERR_BAD_STATEID中继回元数据服务器，并认为这是一个硬错误。如果客户端通知元数据服务器有错误，它可以安全地忽略该错误。对于元数据服务器，任务的完成是因为客户端返回了元数据服务器最有可能调用的布局。
The client might also need to inform the metadata server that it cannot reach one or more of the storage devices. While the metadata server can detect the connectivity of both of these paths:
客户端可能还需要通知元数据服务器它无法访问一个或多个存储设备。虽然元数据服务器可以检测这两条路径的连接：
o metadata server to storage device
o 元数据服务器到存储设备
o metadata server to client
o 元数据服务器到客户端
it cannot determine if the client and storage device path is working. As with the case of the storage device passing errors to the client, it must be prepared for the metadata server to consider such outages as being transitory.
它无法确定客户端和存储设备路径是否正常工作。与存储设备向客户端传递错误的情况一样，必须准备好元数据服务器将这种中断视为暂时性的。
Clients are expected to tolerate transient storage device errors, and hence clients SHOULD NOT use the LAYOUTERROR error handling for device access problems that may be transient. The methods by which a client decides whether a device access problem is transient or persistent are implementation specific but may include retrying I/Os to a data server under appropriate conditions.
客户机应能容忍暂时性存储设备错误，因此，对于可能是暂时性的设备访问问题，客户机不应使用LAYOUTERROR错误处理。客户端决定设备访问问题是暂时的还是持久的方法是特定于实现的，但可能包括在适当条件下重试数据服务器的I/O。
When an I/O to a storage device fails, the client SHOULD retry the failed I/O via the metadata server. In this situation, before retrying the I/O, the client SHOULD return the layout, or the affected portion thereof, and SHOULD indicate which storage device or devices was problematic. The client needs to do this when the storage device is being unresponsive in order to fence off any failed write attempts and ensure that they do not end up overwriting any later data being written through the metadata server. If the client does not do this, the metadata server MAY issue a layout recall callback in order to perform the retried I/O.
当存储设备的I/O失败时，客户端应通过元数据服务器重试失败的I/O。在这种情况下，在重试I/O之前，客户机应返回布局或其受影响的部分，并应指示哪个或哪些存储设备有问题。当存储设备无响应时，客户端需要执行此操作，以阻止任何失败的写入尝试，并确保它们不会覆盖稍后通过元数据服务器写入的任何数据。如果客户端不这样做，元数据服务器可能会发出布局回调以执行重试的I/O。
The client needs to be cognizant that since this error handling is optional in the metadata server, the metadata server may silently ignore this functionality. Also, as the metadata server may consider some issues the client reports to be expected, the client might find it difficult to detect a metadata server that has not implemented error handling via LAYOUTERROR.
客户机需要认识到，由于此错误处理在元数据服务器中是可选的，因此元数据服务器可能会自动忽略此功能。此外，由于元数据服务器可以考虑客户端期望报告的一些问题，客户端可能会发现难以检测到通过LayouTou恐怖没有实现错误处理的元数据服务器。
If a metadata server is aware that a storage device is proving problematic to a client, the metadata server SHOULD NOT include that storage device in any pNFS layouts sent to that client. If the metadata server is aware that a storage device is affecting many clients, then the metadata server SHOULD NOT include that storage device in any pNFS layouts sent out. If a client asks for a new layout for the file from the metadata server, it MUST be prepared for the metadata server to return that storage device in the layout. The metadata server might not have any choice in using the storage device, i.e., there might only be one possible layout for the system.
如果元数据服务器知道存储设备对客户端有问题，则元数据服务器不应将该存储设备包括在发送给该客户端的任何pNFS布局中。如果元数据服务器知道某个存储设备正在影响多个客户端，则元数据服务器不应在发送的任何pNFS布局中包含该存储设备。如果客户端从元数据服务器请求文件的新布局，则必须为元数据服务器返回布局中的存储设备做好准备。元数据服务器在使用存储设备时可能没有任何选择，即系统可能只有一种可能的布局。
Also, in the case of existing files, the metadata server might have no choice regarding which storage devices to hand out to clients.
此外，对于现有文件，元数据服务器可能无法选择将哪些存储设备分发给客户端。
The metadata server is not required to indefinitely retain per-client storage device error information. The metadata server is also not required to automatically reinstate the use of a previously problematic storage device; administrative intervention may be required instead.
元数据服务器不需要无限期地保留每个客户端存储设备的错误信息。元数据服务器也不需要自动恢复使用以前有问题的存储设备；可能需要行政干预。
<CODE BEGINS>
<代码开始>
struct layoutupdate4 {
layouttype4 lou_type;
opaque lou_body<>;
};
struct layoutupdate4 {
layouttype4 lou_type;
opaque lou_body<>;
};
struct io_info4 {
uint64_t ii_count;
uint64_t ii_bytes;
};
struct io_info4 {
uint64_t ii_count;
uint64_t ii_bytes;
};
struct LAYOUTSTATS4args {
/* CURRENT_FH: file */
offset4 lsa_offset;
length4 lsa_length;
stateid4 lsa_stateid;
io_info4 lsa_read;
io_info4 lsa_write;
deviceid4 lsa_deviceid;
layoutupdate4 lsa_layoutupdate;
};
struct LAYOUTSTATS4args {
/* CURRENT_FH: file */
offset4 lsa_offset;
length4 lsa_length;
stateid4 lsa_stateid;
io_info4 lsa_read;
io_info4 lsa_write;
deviceid4 lsa_deviceid;
layoutupdate4 lsa_layoutupdate;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct LAYOUTSTATS4res {
nfsstat4 lsr_status;
};
struct LAYOUTSTATS4res {
nfsstat4 lsr_status;
};
<CODE ENDS>
<代码结束>
The client can use LAYOUTSTATS to inform the metadata server about its interaction with the layout (see Section 12 of [RFC5661]) represented by the current filehandle, client ID (derived from the session ID in the preceding SEQUENCE operation), byte range (lsa_offset and lsa_length), and lsa_stateid. lsa_read and lsa_write allow non-layout-type-specific statistics to be reported. lsa_deviceid allows the client to specify to which storage device the statistics apply. The remaining information the client is presenting is specific to the layout type and presented in the lsa_layoutupdate field. Each layout type MUST define the contents of lsa_layoutupdate in their respective specifications.
客户机可以使用LAYOUTSTATS通知元数据服务器其与布局的交互（请参阅[RFC5661]的第12节），布局由当前文件句柄、客户机ID（源自前面序列操作中的会话ID）、字节范围（lsa_偏移量和lsa_长度）和lsa_状态ID表示。lsa_读取和lsa_写入允许报告非布局类型特定的统计信息。lsa_deviceid允许客户端指定统计信息应用于哪个存储设备。客户端显示的其余信息特定于布局类型，并显示在lsa_layoutupdate字段中。每个布局类型必须在各自的规范中定义lsa_layoutupdate的内容。
LAYOUTSTATS can be combined with IO_ADVISE (see Section 15.5) to augment the decision-making process of how the metadata server handles a file. That is, IO_ADVISE lets the server know that a byte range has a certain characteristic, but not necessarily the intensity of that characteristic.
LAYOUTSTATS可以与IO_ADVISE（参见第15.5节）结合使用，以增强元数据服务器如何处理文件的决策过程。也就是说，IO_advice让服务器知道字节范围具有某种特征，但不一定是该特征的强度。
The statistics are cumulative, i.e., multiple LAYOUTSTATS updates can be in flight at the same time. The metadata server can examine the packet's timestamp to order the different calls. The first LAYOUTSTATS sent by the client SHOULD be from the opening of the file. The choice of how often to update the metadata server is made by the client.
统计数据是累积的，即多个LAYOUTSTATS更新可以同时进行。元数据服务器可以检查数据包的时间戳以对不同的调用进行排序。客户端发送的第一个LAYOUTSTATS应该是从文件打开时开始的。更新元数据服务器的频率由客户端选择。
Note that while the metadata server may return an error associated with the layout stateid or the open file, it MUST NOT return an error in the processing of the statistics.
请注意，虽然元数据服务器可能返回与布局stateid或打开的文件相关联的错误，但在处理统计信息时不得返回错误。
<CODE BEGINS>
<代码开始>
struct OFFLOAD_CANCEL4args {
/* CURRENT_FH: file to cancel */
stateid4 oca_stateid;
};
struct OFFLOAD_CANCEL4args {
/* CURRENT_FH: file to cancel */
stateid4 oca_stateid;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct OFFLOAD_CANCEL4res {
nfsstat4 ocr_status;
};
struct OFFLOAD_CANCEL4res {
nfsstat4 ocr_status;
};
<CODE ENDS>
<代码结束>
OFFLOAD_CANCEL is used by the client to terminate an asynchronous operation, which is identified by both CURRENT_FH and the oca_stateid. That is, there can be multiple OFFLOAD_CANCEL operations acting on the file, and the stateid will identify to the server exactly which one is to be stopped. Currently, there are only two operations that can decide to be asynchronous: COPY and WRITE_SAME.
卸载\u取消由客户端用于终止异步操作，该操作由当前\u FH和oca\u stateid标识。也就是说，可以对文件执行多个卸载\u取消操作，stateid将向服务器准确标识要停止的操作。目前，只有两个操作可以决定是异步的：复制和写入相同。
In the context of server-to-server copy, the client can send OFFLOAD_CANCEL to either the source or destination server, albeit with a different stateid. The client uses OFFLOAD_CANCEL to inform the destination to stop the active transfer and uses the stateid it got back from the COPY operation. The client uses OFFLOAD_CANCEL and the stateid it used in the COPY_NOTIFY to inform the source to not allow any more copying from the destination.
在服务器到服务器复制的上下文中，客户端可以向源服务器或目标服务器发送卸载取消，尽管使用不同的stateid。客户端使用OFFLOAD_CANCEL通知目标停止活动传输，并使用从复制操作返回的stateid。客户端使用卸载\u取消和它在复制\u通知中使用的stateid通知源不允许从目标进行任何复制。
OFFLOAD_CANCEL is also useful in situations in which the source server granted a very long or infinite lease on the destination server's ability to read the source file and all COPY operations on the source file have been completed.
在源服务器授予目标服务器读取源文件的能力很长或无限期租约，并且源文件上的所有复制操作都已完成的情况下，卸载\u取消也很有用。
15.9. Operation 67: OFFLOAD_STATUS - Poll for the status of an asynchronous operation
15.9. 操作67：卸载_状态-轮询异步操作的状态
<CODE BEGINS>
<代码开始>
struct OFFLOAD_STATUS4args {
/* CURRENT_FH: destination file */
stateid4 osa_stateid;
};
struct OFFLOAD_STATUS4args {
/* CURRENT_FH: destination file */
stateid4 osa_stateid;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct OFFLOAD_STATUS4resok {
length4 osr_count;
nfsstat4 osr_complete<1>;
};
struct OFFLOAD_STATUS4resok {
length4 osr_count;
nfsstat4 osr_complete<1>;
};
union OFFLOAD_STATUS4res switch (nfsstat4 osr_status) {
case NFS4_OK:
OFFLOAD_STATUS4resok osr_resok4;
default:
void;
};
union OFFLOAD_STATUS4res switch (nfsstat4 osr_status) {
case NFS4_OK:
OFFLOAD_STATUS4resok osr_resok4;
default:
void;
};
<CODE ENDS>
<代码结束>
OFFLOAD_STATUS can be used by the client to query the progress of an asynchronous operation, which is identified by both CURRENT_FH and the osa_stateid. If this operation is successful, the number of bytes processed is returned to the client in the osr_count field.
卸载状态可由客户端用于查询异步操作的进度，该操作由当前卸载状态和osa卸载状态标识标识。如果此操作成功，处理的字节数将在osr_计数字段中返回给客户端。
If the optional osr_complete field is present, the asynchronous operation has completed. In this case, the status value indicates the result of the asynchronous operation. In all cases, the server will also deliver the final results of the asynchronous operation in a CB_OFFLOAD operation.
如果存在可选的osr_complete字段，则异步操作已完成。在这种情况下，状态值指示异步操作的结果。在所有情况下，服务器还将在CB_卸载操作中提供异步操作的最终结果。
The failure of this operation does not indicate the result of the asynchronous operation in any way.
此操作的失败不会以任何方式指示异步操作的结果。
<CODE BEGINS>
<代码开始>
struct READ_PLUS4args {
/* CURRENT_FH: file */
stateid4 rpa_stateid;
offset4 rpa_offset;
count4 rpa_count;
};
struct READ_PLUS4args {
/* CURRENT_FH: file */
stateid4 rpa_stateid;
offset4 rpa_offset;
count4 rpa_count;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
enum data_content4 {
NFS4_CONTENT_DATA = 0,
NFS4_CONTENT_HOLE = 1
};
enum data_content4 {
NFS4_CONTENT_DATA = 0,
NFS4_CONTENT_HOLE = 1
};
struct data_info4 {
offset4 di_offset;
length4 di_length;
};
struct data_info4 {
offset4 di_offset;
length4 di_length;
};
struct data4 {
offset4 d_offset;
opaque d_data<>;
};
struct data4 {
offset4 d_offset;
opaque d_data<>;
};
union read_plus_content switch (data_content4 rpc_content) {
case NFS4_CONTENT_DATA:
data4 rpc_data;
case NFS4_CONTENT_HOLE:
data_info4 rpc_hole;
default:
void;
};
union read_plus_content switch (data_content4 rpc_content) {
case NFS4_CONTENT_DATA:
data4 rpc_data;
case NFS4_CONTENT_HOLE:
data_info4 rpc_hole;
default:
void;
};
/*
* Allow a return of an array of contents.
*/
struct read_plus_res4 {
bool rpr_eof;
read_plus_content rpr_contents<>;
};
/*
* Allow a return of an array of contents.
*/
struct read_plus_res4 {
bool rpr_eof;
read_plus_content rpr_contents<>;
};
union READ_PLUS4res switch (nfsstat4 rp_status) {
case NFS4_OK:
read_plus_res4 rp_resok4;
default:
void;
};
union READ_PLUS4res switch (nfsstat4 rp_status) {
case NFS4_OK:
read_plus_res4 rp_resok4;
default:
void;
};
<CODE ENDS>
<代码结束>
The READ_PLUS operation is based upon the NFSv4.1 READ operation (see Section 18.22 of [RFC5661]) and similarly reads data from the regular file identified by the current filehandle.
READ_PLUS操作基于NFSv4.1读取操作（参见[RFC5661]第18.22节），并类似地从当前文件句柄标识的常规文件中读取数据。
The client provides an rpa_offset of where the READ_PLUS is to start and an rpa_count of how many bytes are to be read. An rpa_offset of zero means that data will be read starting at the beginning of the file. If rpa_offset is greater than or equal to the size of the file, the status NFS4_OK is returned with di_length (the data length) set to zero and eof set to TRUE.
客户机提供了一个rpa_偏移量，该偏移量表示READ_PLUS的开始位置，以及一个rpa_计数，该计数表示要读取的字节数。rpa_偏移量为零表示将从文件开头开始读取数据。如果rpa_偏移量大于或等于文件大小，则返回状态NFS4_OK，di_长度（数据长度）设置为零，eof设置为真。
The READ_PLUS result is comprised of an array of rpr_contents, each of which describes a data_content4 type of data. For NFSv4.2, the allowed values are data and hole. A server MUST support both the data type and the hole if it uses READ_PLUS. If it does not want to support a hole, it MUST use READ. The array contents MUST be contiguous in the file.
READ_PLUS结果由一个rpr_内容数组组成，每个rpr_内容描述一种数据类型。对于NFSv4.2，允许的值为数据和孔。如果使用READ_PLUS，服务器必须同时支持数据类型和孔。如果不希望支撑孔，则必须使用READ。数组内容在文件中必须是连续的。
Holes SHOULD be returned in their entirety -- clients must be prepared to get more information than they requested. Both the start and the end of the hole may exceed what was requested. If data to be returned is comprised entirely of zeros, then the server SHOULD return that data as a hole instead.
洞应该全部返回——客户必须准备好获得比他们要求的更多的信息。孔的起点和终点都可能超出要求。如果要返回的数据完全由零组成，那么服务器应该将该数据作为孔返回。
The server may elect to return adjacent elements of the same type. For example, if the server has a range of data comprised entirely of zeros and then a hole, it might want to return two adjacent holes to the client.
服务器可以选择返回相同类型的相邻元素。例如，如果服务器的数据范围完全由零和一个孔组成，那么它可能希望将两个相邻的孔返回给客户端。
If the client specifies an rpa_count value of zero, the READ_PLUS succeeds and returns zero bytes of data. In all situations, the server may choose to return fewer bytes than specified by the client. The client needs to check for this condition and handle the condition appropriately.
如果客户机指定rpa_计数值为零，则READ_PLUS将成功并返回零字节的数据。在所有情况下，服务器都可以选择返回比客户端指定的字节更少的字节。客户需要检查该情况并适当处理该情况。
If the client specifies data that is entirely contained within a hole of the file (i.e., both rpa_offset and rpa_offset + rpa_count are within the hole), then the di_offset and di_length returned MAY be for the entire hole. If the owner has a locked byte range covering rpa_offset and rpa_count entirely, the di_offset and di_length MUST NOT be extended outside the locked byte range. This result is considered valid until the file is changed (detected via the change attribute). The server MUST provide the same semantics for the hole as if the client read the region and received zeros; the implied hole's contents lifetime MUST be exactly the same as any other read data.
如果客户端指定的数据完全包含在文件的某个孔内（即，rpa_偏移量和rpa_偏移量+rpa_计数都在该孔内），则返回的di_偏移量和di_长度可能是整个孔的。如果所有者的锁定字节范围完全覆盖rpa_偏移量和rpa_计数，则di_偏移量和di_长度不得扩展到锁定字节范围之外。在文件更改（通过“更改”属性检测）之前，此结果视为有效。服务器必须为孔提供相同的语义，就像客户端读取区域并接收到零一样；隐含孔的内容生存期必须与任何其他读取数据完全相同。
If the client specifies data by an rpa_offset that begins in a non-hole of the file but extends into a hole (the rpa_offset + rpa_count is in the hole), the server should return an array comprised of both data and a hole. The client MUST be prepared for the server to return a short read describing just the data. The client will then issue another READ_PLUS for the remaining bytes, to which the server will respond with information about the hole in the file.
如果客户端通过rpa_偏移量指定数据，该偏移量从文件的非孔开始，但延伸到孔中（rpa_偏移量+rpa_计数在孔中），则服务器应返回一个由数据和孔组成的数组。客户端必须准备好让服务器返回一个只描述数据的简短读取。然后，客户机将为剩余字节发出另一个READ_PLUS，服务器将用文件中的漏洞信息响应。
Except when special stateids are used, the stateid value for a READ_PLUS request represents a value returned from a previous byte-range lock or share reservation request or the stateid associated with a delegation. The stateid identifies the associated owners, if any, and is used by the server to verify that the associated locks are still valid (e.g., have not been revoked).
除非使用特殊的stateid，否则READ_PLUS请求的stateid值表示从以前的字节范围锁定或共享保留请求返回的值，或者表示与委派关联的stateid。stateid标识关联的所有者（如果有），并由服务器用于验证关联的锁是否仍然有效（例如，尚未撤销）。
If the read ended at the end of the file (formally, in a correctly formed READ_PLUS operation, if rpa_offset + rpa_count is equal to the size of the file) or the READ_PLUS operation extends beyond the size of the file (if rpa_offset + rpa_count is greater than the size of the file), eof is returned as TRUE; otherwise, it is FALSE. A successful READ_PLUS of an empty file will always return eof as TRUE.
如果读取在文件末尾结束（正式地说，在格式正确的read_PLUS操作中，如果rpa_偏移量+rpa_计数等于文件的大小），或者read_PLUS操作超出了文件的大小（如果rpa_偏移量+rpa_计数大于文件的大小），则eof返回为TRUE；否则，这是错误的。成功读取空文件将始终将eof返回为TRUE。
If the current filehandle is not an ordinary file, an error will be returned to the client. In the case that the current filehandle represents an object of type NF4DIR, NFS4ERR_ISDIR is returned. If the current filehandle designates a symbolic link, NFS4ERR_SYMLINK is returned. In all other cases, NFS4ERR_WRONG_TYPE is returned.
如果当前文件句柄不是普通文件，则会向客户端返回错误。如果当前文件句柄表示NF4DIR类型的对象，则返回NFS4ERR_ISDIR。如果当前文件句柄指定符号链接，则返回NFS4ERR_SYMLINK。在所有其他情况下，将返回NFS4ERR_-Error_类型。
For a READ_PLUS with a stateid value of all bits equal to zero, the server MAY allow the READ_PLUS to be serviced subject to mandatory byte-range locks or the current share deny modes for the file. For a READ_PLUS with a stateid value of all bits equal to one, the server MAY allow READ_PLUS operations to bypass locking checks at the server.
对于stateid值为所有位等于零的READ_PLUS，服务器可允许在强制字节范围锁定或文件当前共享拒绝模式下为READ_PLUS提供服务。对于stateid值为所有位等于1的READ_PLUS，服务器可能允许READ_PLUS操作绕过服务器上的锁定检查。
On success, the current filehandle retains its value.
成功后，当前文件句柄将保留其值。
It was decided not to add a means for the client to inform the server as to which arms of READ_PLUS it would support. In a later minor version, it may become necessary for the introduction of a new operation that would allow the client to inform the server as to whether it supported the new arms of the union of data types available in READ_PLUS.
决定不为客户机添加一种方法来通知服务器它将支持哪个READ_PLUS分支。在以后的次要版本中，可能需要引入一个新操作，该操作允许客户端通知服务器它是否支持READ_PLUS中可用的数据类型联合的新分支。
In general, the IMPLEMENTATION notes for READ in Section 18.22.4 of [RFC5661] also apply to READ_PLUS.
通常，[RFC5661]第18.22.4节中的READ实施说明也适用于READ_PLUS。
With pNFS, the semantics of using READ_PLUS remains the same. Any data server MAY return a hole result for a READ_PLUS request that it receives. When a data server chooses to return such a result, it has the option of returning information for the data stored on that data server (as defined by the data layout), but it MUST NOT return results for a byte range that includes data managed by another data server.
对于pNFS，使用READ_PLUS的语义保持不变。任何数据服务器都可以为接收到的READ_PLUS请求返回一个洞结果。当数据服务器选择返回此类结果时，它可以选择返回存储在该数据服务器上的数据的信息（由数据布局定义），但不能返回包含另一数据服务器管理的数据的字节范围的结果。
If mandatory locking is enforced, then the data server must also ensure that only information that is within the owner's locked byte range is returned.
如果强制锁定，则数据服务器还必须确保仅返回所有者锁定字节范围内的信息。
The following table describes a sparse file. For each byte range, the file contains either non-zero data or a hole. In addition, the server in this example will only create a hole if it is greater than 32K.
下表介绍了稀疏文件。对于每个字节范围，文件包含非零数据或孔。此外，本例中的服务器仅在大于32K时才会创建孔。
+-------------+----------+
| Byte Range | Contents |
+-------------+----------+
| 0-15999 | Hole |
| 16K-31999 | Non-Zero |
| 32K-255999 | Hole |
| 256K-287999 | Non-Zero |
| 288K-353999 | Hole |
| 354K-417999 | Non-Zero |
+-------------+----------+
+-------------+----------+
| Byte Range | Contents |
+-------------+----------+
| 0-15999 | Hole |
| 16K-31999 | Non-Zero |
| 32K-255999 | Hole |
| 256K-287999 | Non-Zero |
| 288K-353999 | Hole |
| 354K-417999 | Non-Zero |
+-------------+----------+
Table 7: Sparse File
表7：稀疏文件
Under the given circumstances, if a client was to read from the file with a maximum read size of 64K, the following will be the results for the given READ_PLUS calls. This assumes that the client has already opened the file, acquired a valid stateid ("s" in the example), and just needs to issue READ_PLUS requests.
在给定的情况下，如果客户端要以64K的最大读取大小从文件中读取，则以下是给定read_PLUS调用的结果。这假设客户机已经打开了文件，获得了有效的stateid（示例中为“s”），只需要发出READ_PLUS请求。
1. READ_PLUS(s, 0, 64K) --> NFS_OK, eof = FALSE, <data[0,32K], hole[32K,224K]>. Since the first hole is less than the server's minimum hole size, the first 32K of the file is returned as data and the remaining 32K is returned as a hole that actually extends to 256K.
1. READ_PLUS（s，064k）->NFS_OK，eof=FALSE，<data[0,32K]，hole[32K，224K]>。由于第一个洞小于服务器的最小洞大小，因此文件的前32K作为数据返回，其余32K作为实际扩展到256K的洞返回。
2. READ_PLUS(s, 32K, 64K) --> NFS_OK, eof = FALSE, <hole[32K,224K]>. The requested range was all zeros, and the current hole begins at offset 32K and is 224K in length. Note that the client should not have followed up the previous READ_PLUS request with this one, as the hole information from the previous call extended past what the client was requesting.
2. 读加（s，32K，64K）->NFS\u OK，eof=FALSE，<hole[32K，224K]>。请求的范围为全零，当前孔从偏移量32K开始，长度为224K。请注意，客户机不应该使用此请求跟进上一个READ_PLUS请求，因为来自上一个调用的孔信息超出了客户机的请求。
3. READ_PLUS(s, 256K, 64K) --> NFS_OK, eof = FALSE, <data[256K, 288K], hole[288K, 354K]>. Returns an array of the 32K data and the hole, which extends to 354K.
3. READ_PLUS（s，256K，64K）->NFS_OK，eof=FALSE，<data[256K，288K]，hole[288K，354K]>。返回32K数据和孔的数组，扩展到354K。
4. READ_PLUS(s, 354K, 64K) --> NFS_OK, eof = TRUE, <data[354K, 418K]>. Returns the final 64K of data and informs the client that there is no more data in the file.
4. READ_PLUS（s，354K，64K）->NFS_正常，eof=TRUE，<data[354K，418K]>。返回最后的64K数据，并通知客户端文件中没有更多数据。
<CODE BEGINS>
<代码开始>
enum data_content4 {
NFS4_CONTENT_DATA = 0,
NFS4_CONTENT_HOLE = 1
};
enum data_content4 {
NFS4_CONTENT_DATA = 0,
NFS4_CONTENT_HOLE = 1
};
struct SEEK4args {
/* CURRENT_FH: file */
stateid4 sa_stateid;
offset4 sa_offset;
data_content4 sa_what;
};
struct SEEK4args {
/* CURRENT_FH: file */
stateid4 sa_stateid;
offset4 sa_offset;
data_content4 sa_what;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct seek_res4 {
bool sr_eof;
offset4 sr_offset;
};
struct seek_res4 {
bool sr_eof;
offset4 sr_offset;
};
union SEEK4res switch (nfsstat4 sa_status) {
case NFS4_OK:
seek_res4 resok4;
default:
void;
};
union SEEK4res switch (nfsstat4 sa_status) {
case NFS4_OK:
seek_res4 resok4;
default:
void;
};
<CODE ENDS>
<代码结束>
SEEK is an operation that allows a client to determine the location of the next data_content4 in a file. It allows an implementation of the emerging extension to the lseek(2) function to allow clients to determine the next hole whilst in data or the next data whilst in a hole.
SEEK是一种允许客户端确定文件中下一个数据内容4的位置的操作。它允许实现lseek（2）功能的新兴扩展，以允许客户端在数据中确定下一个孔或在孔中确定下一个数据。
From the given sa_offset, find the next data_content4 of type sa_what in the file. If the server cannot find a corresponding sa_what, then the status will still be NFS4_OK, but sr_eof would be TRUE. If the server can find the sa_what, then the sr_offset is the start of that content. If the sa_offset is beyond the end of the file, then SEEK MUST return NFS4ERR_NXIO.
从给定的sa_偏移量中，找到文件中类型为sa_what的下一个数据_content4。如果服务器找不到相应的sa_what，则状态仍然为NFS4_OK，但sr_eof为TRUE。如果服务器可以找到sau-what，那么sr-u偏移量就是该内容的开始。如果sa_偏移量超出文件末尾，则SEEK必须返回NFS4ERR_NXIO。
All files MUST have a virtual hole at the end of the file. That is, if a file system does not support sparse files, then a COMPOUND with {SEEK 0 NFS4_CONTENT_HOLE;} would return a result of {SEEK 1 X;}, where "X" was the size of the file.
所有文件的末尾都必须有一个虚拟孔。也就是说，如果文件系统不支持稀疏文件，那么带有{SEEK 0 NFS4_CONTENT_HOLE；}的复合词将返回{SEEK 1 X；}的结果，其中“X”是文件的大小。
SEEK must follow the same rules for stateids as READ_PLUS (Section 15.10.3).
SEEK必须遵循与READ_PLUS相同的StateID规则（第15.10.3节）。
<CODE BEGINS>
<代码开始>
enum stable_how4 {
UNSTABLE4 = 0,
DATA_SYNC4 = 1,
FILE_SYNC4 = 2
};
enum stable_how4 {
UNSTABLE4 = 0,
DATA_SYNC4 = 1,
FILE_SYNC4 = 2
};
struct app_data_block4 {
offset4 adb_offset;
length4 adb_block_size;
length4 adb_block_count;
length4 adb_reloff_blocknum;
count4 adb_block_num;
length4 adb_reloff_pattern;
opaque adb_pattern<>;
};
struct app_data_block4 {
offset4 adb_offset;
length4 adb_block_size;
length4 adb_block_count;
length4 adb_reloff_blocknum;
count4 adb_block_num;
length4 adb_reloff_pattern;
opaque adb_pattern<>;
};
struct WRITE_SAME4args {
/* CURRENT_FH: file */
stateid4 wsa_stateid;
stable_how4 wsa_stable;
app_data_block4 wsa_adb;
};
struct WRITE_SAME4args {
/* CURRENT_FH: file */
stateid4 wsa_stateid;
stable_how4 wsa_stable;
app_data_block4 wsa_adb;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct write_response4 {
stateid4 wr_callback_id<1>;
length4 wr_count;
stable_how4 wr_committed;
verifier4 wr_writeverf;
};
struct write_response4 {
stateid4 wr_callback_id<1>;
length4 wr_count;
stable_how4 wr_committed;
verifier4 wr_writeverf;
};
union WRITE_SAME4res switch (nfsstat4 wsr_status) {
case NFS4_OK:
write_response4 resok4;
default:
void;
};
union WRITE_SAME4res switch (nfsstat4 wsr_status) {
case NFS4_OK:
write_response4 resok4;
default:
void;
};
<CODE ENDS>
<代码结束>
The WRITE_SAME operation writes an application data block to the regular file identified by the current filehandle (see WRITE SAME (10) in [T10-SBC2]). The target file is specified by the current filehandle. The data to be written is specified by an app_data_block4 structure (Section 8.1.1). The client specifies with the wsa_stable parameter the method of how the data is to be processed by the server. It is treated like the stable parameter in the NFSv4.1 WRITE operation (see Section 18.32.3 of [RFC5661]).
WRITE_SAME操作将应用程序数据块写入由当前文件句柄标识的常规文件（参见[T10-SBC2]中的WRITE SAME（10））。目标文件由当前文件句柄指定。待写入的数据由app_data_block4结构规定（第8.1.1节）。客户机使用wsa_stable参数指定服务器如何处理数据的方法。它被视为NFSv4.1写入操作中的稳定参数（参见[RFC5661]第18.32.3节）。
A successful WRITE_SAME will construct a reply for wr_count, wr_committed, and wr_writeverf as per the NFSv4.1 WRITE operation results. If wr_callback_id is set, it indicates an asynchronous reply (see Section 15.12.3.1).
成功的写入将根据NFSv4.1写入操作结果为wr_count、wr_committed和wr_writerf构造一个应答。如果设置了wr_callback_id，则表示异步应答（见第15.12.3.1节）。
As it is an OPTIONAL operation, WRITE_SAME has to support NFS4ERR_NOTSUPP. As it is an extension of WRITE, it has to support all of the errors returned by WRITE. If the client supports WRITE_SAME, it MUST support CB_OFFLOAD.
由于这是一个可选操作，WRITE_SAME必须支持NFS4ERR_NOTSUPP。由于它是WRITE的扩展，因此必须支持WRITE返回的所有错误。如果客户端支持WRITE_-SAME，那么它必须支持CB_卸载。
If the server supports ADBs, then it MUST support the WRITE_SAME operation. The server has no concept of the structure imposed by the application. It is only when the application writes to a section of the file does order get imposed. In order to detect corruption even before the application utilizes the file, the application will want to initialize a range of ADBs using WRITE_SAME.
如果服务器支持ADB，则必须支持相同的写操作。服务器对应用程序强加的结构没有概念。只有当应用程序写入文件的某个部分时，才会强制执行命令。为了在应用程序使用文件之前检测损坏，应用程序将希望使用WRITE_SAME初始化一系列ADB。
When the client invokes the WRITE_SAME operation, it wants to record the block structure described by the app_data_block4 into the file.
当客户端调用WRITE_-SAME操作时，它希望将app_data_block4描述的块结构记录到文件中。
When the server receives the WRITE_SAME operation, it MUST populate adb_block_count ADBs in the file, starting at adb_offset. The block size will be given by adb_block_size. The ADBN (if provided) will start at adb_reloff_blocknum, and each block will be monotonically numbered, starting from adb_block_num in the first block. The pattern (if provided) will be at adb_reloff_pattern of each block and will be provided in adb_pattern.
当服务器接收到相同的写操作时，它必须从adb\U偏移量开始在文件中填充adb\U block\U count adb。块大小将由adb_块大小给出。ADBN（如果提供）将从adb_reloff_blocknum开始，每个块将从第一个块中的adb_block_num开始单调编号。模式（如果提供）将以每个区块的adb_reloff_模式提供，并以adb_模式提供。
The server SHOULD return an asynchronous result if it can determine that the operation will be long-running (see Section 15.12.3.1). Once either the WRITE_SAME finishes synchronously or the server uses CB_OFFLOAD to inform the client of the asynchronous completion of the WRITE_SAME, the server MUST return the ADBs to clients as data.
如果服务器能够确定操作将长期运行，则应返回异步结果（请参阅第15.12.3.1节）。一旦写入同步完成，或者服务器使用CB\U卸载通知客户端异步完成写入，服务器必须将ADB作为数据返回给客户端。
ADB initialization may cause a server to decide to service the operation asynchronously. If it decides to do so, it sets the stateid in wr_callback_id to be that of the wsa_stateid. If it does not set the wr_callback_id, then the result is synchronous.
ADB初始化可能导致服务器决定以异步方式为操作提供服务。如果它决定这样做，它会将wr_callback_id中的stateid设置为wsa_stateid。如果未设置wr_callback_id，则结果是同步的。
When the client determines that the reply will be given asynchronously, it should not assume anything about the contents of what it wrote until it is informed by the server that the operation is complete. It can use OFFLOAD_STATUS (Section 15.9) to monitor the operation and OFFLOAD_CANCEL (Section 15.8) to cancel the operation. An example of an asynchronous WRITE_SAME is shown in Figure 6. Note that, as with the COPY operation, WRITE_SAME must provide a stateid for tracking the asynchronous operation.
当客户机确定将以异步方式给出回复时，在服务器通知它操作已完成之前，它不应假定它所写内容的任何内容。可使用卸载状态（第15.9节）监控操作，卸载取消（第15.8节）取消操作。图6显示了一个异步写入的例子。注意，与复制操作一样，WRITE_SAME必须提供用于跟踪异步操作的stateid。
Client Server
+ +
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the file
| |
|--- WRITE_SAME ---------------------->| Client initializes
|<------------------------------------/| an ADB
| |
| |
|--- OFFLOAD_STATUS ------------------>| Client may poll
|<------------------------------------/| for status
| |
| . | Multiple OFFLOAD_STATUS
| . | operations may be sent.
| . |
| |
|<-- CB_OFFLOAD -----------------------| Server reports results
|\------------------------------------>|
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the file
| |
| |
Client Server
+ +
| |
|--- OPEN ---------------------------->| Client opens
|<------------------------------------/| the file
| |
|--- WRITE_SAME ---------------------->| Client initializes
|<------------------------------------/| an ADB
| |
| |
|--- OFFLOAD_STATUS ------------------>| Client may poll
|<------------------------------------/| for status
| |
| . | Multiple OFFLOAD_STATUS
| . | operations may be sent.
| . |
| |
|<-- CB_OFFLOAD -----------------------| Server reports results
|\------------------------------------>|
| |
|--- CLOSE --------------------------->| Client closes
|<------------------------------------/| the file
| |
| |
Figure 6: An Asynchronous WRITE_SAME
图6：一个异步写单元
When CB_OFFLOAD informs the client of the successful WRITE_SAME, the write_response4 embedded in the operation will provide the necessary information that a synchronous WRITE_SAME would have provided.
当CB_卸载通知客户端成功写入时，嵌入操作中的写入响应4将提供同步写入所提供的必要信息。
Regardless of whether the operation is asynchronous or synchronous, it MUST still support the COMMIT operation semantics as outlined in Section 18.3 of [RFC5661]. That is, COMMIT works on one or more WRITE operations, and the WRITE_SAME operation can appear as several WRITE operations to the server. The client can use locking operations to control the behavior on the server with respect to long-running asynchronous WRITE_SAME operations.
无论操作是异步的还是同步的，它都必须支持[RFC5661]第18.3节中概述的提交操作语义。也就是说，COMMIT可用于一个或多个写操作，同一个写操作可以显示为对服务器的多个写操作。客户端可以使用锁定操作来控制服务器上长期运行的异步写操作的行为。
WRITE_SAME will clone adb_block_count copies of the given ADB in consecutive order in the file, starting at adb_offset. An error can occur after writing the Nth ADB to the file. WRITE_SAME MUST appear to populate the range of the file as if the client used WRITE to transfer the instantiated ADBs. That is, the contents of the range will be easy for the client to determine in the case of a partially complete WRITE_SAME.
WRITE_SAME将从adb_偏移量开始，在文件中按连续顺序克隆给定adb的adb_block_计数副本。将第n个ADB写入文件后可能会发生错误。WRITE_SAME必须显示为填充文件范围，就像客户端使用WRITE传输实例化的ADB一样。也就是说，在部分完成写入的情况下，客户机很容易确定范围的内容。
<CODE BEGINS>
<代码开始>
struct CLONE4args {
/* SAVED_FH: source file */
/* CURRENT_FH: destination file */
stateid4 cl_src_stateid;
stateid4 cl_dst_stateid;
offset4 cl_src_offset;
offset4 cl_dst_offset;
length4 cl_count;
};
struct CLONE4args {
/* SAVED_FH: source file */
/* CURRENT_FH: destination file */
stateid4 cl_src_stateid;
stateid4 cl_dst_stateid;
offset4 cl_src_offset;
offset4 cl_dst_offset;
length4 cl_count;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct CLONE4res {
nfsstat4 cl_status;
};
struct CLONE4res {
nfsstat4 cl_status;
};
<CODE ENDS>
<代码结束>
The CLONE operation is used to clone file content from a source file specified by the SAVED_FH value into a destination file specified by CURRENT_FH without actually copying the data, e.g., by using a copy-on-write mechanism.
克隆操作用于将文件内容从保存的_FH值指定的源文件克隆到当前_FH指定的目标文件，而无需实际复制数据，例如，通过使用写时复制机制。
Both SAVED_FH and CURRENT_FH must be regular files. If either SAVED_FH or CURRENT_FH is not a regular file, the operation MUST fail and return NFS4ERR_WRONG_TYPE.
保存的_FH和当前的_FH都必须是常规文件。如果保存的\u FH或当前的\u FH不是常规文件，则操作必须失败并返回NFS4ERR\u错误的\u类型。
The ca_dst_stateid MUST refer to a stateid that is valid for a WRITE operation and follows the rules for stateids in Sections 8.2.5 and 18.32.3 of [RFC5661]. The ca_src_stateid MUST refer to a stateid that is valid for a READ operation and follows the rules for stateids in Sections 8.2.5 and 18.22.3 of [RFC5661]. If either stateid is invalid, then the operation MUST fail.
ca_dst_stateid必须引用对写入操作有效的stateid，并遵循[RFC5661]第8.2.5节和第18.32.3节中的stateid规则。ca_src_stateid必须引用对读取操作有效的stateid，并遵循[RFC5661]第8.2.5节和第18.22.3节中的stateid规则。如果任一stateid无效，则操作必须失败。
The cl_src_offset is the starting offset within the source file from which the data to be cloned will be obtained, and the cl_dst_offset is the starting offset of the target region into which the cloned data will be placed. An offset of 0 (zero) indicates the start of the respective file. The number of bytes to be cloned is obtained from cl_count, except that a cl_count of 0 (zero) indicates that the number of bytes to be cloned is the count of bytes between cl_src_offset and the EOF of the source file. Both cl_src_offset and cl_dst_offset must be aligned to the clone block size (Section 12.2.1). The number of bytes to be cloned must be a multiple of the clone block size, except in the case in which cl_src_offset plus the number of bytes to be cloned is equal to the source file size.
cl_src_偏移量是源文件内的起始偏移量，将从中获取要克隆的数据，cl_dst_偏移量是将克隆数据放置到其中的目标区域的起始偏移量。偏移量为0（零）表示相应文件的开始。要克隆的字节数从cl_计数中获得，但cl_计数为0（零）表示要克隆的字节数是cl_src_偏移量和源文件EOF之间的字节数。cl_src_偏移和cl_dst_偏移必须与克隆块大小对齐（第12.2.1节）。要克隆的字节数必须是克隆块大小的倍数，但cl_src_offset加上要克隆的字节数等于源文件大小的情况除外。
If the source offset or the source offset plus count is greater than the size of the source file, the operation MUST fail with NFS4ERR_INVAL. The destination offset or destination offset plus count may be greater than the size of the destination file.
如果源偏移量或源偏移量加上计数大于源文件的大小，则操作必须失败，并显示NFS4ERR_INVAL。目标偏移量或目标偏移量加上计数可能大于目标文件的大小。
If SAVED_FH and CURRENT_FH refer to the same file and the source and target ranges overlap, the operation MUST fail with NFS4ERR_INVAL.
如果保存的_FH和当前的_FH引用同一个文件，并且源和目标范围重叠，则操作必须失败，NFS4ERR_INVAL。
If the target area of the CLONE operation ends beyond the end of the destination file, the offset at the end of the target area will determine the new size of the destination file. The contents of any block not part of the target area will be the same as if the file size were extended by a WRITE.
如果克隆操作的目标区域结束于目标文件的结尾之外，则目标区域结尾处的偏移量将确定目标文件的新大小。任何不属于目标区域的块的内容将与文件大小通过写入扩展时的内容相同。
If the area to be cloned is not a multiple of the clone block size and the size of the destination file is past the end of the target area, the area between the end of the target area and the next multiple of the clone block size will be zeroed.
如果要克隆的区域不是克隆块大小的倍数，并且目标文件的大小超过目标区域的末尾，则目标区域的末尾和克隆块大小的下一倍数之间的区域将归零。
The CLONE operation is atomic in that other operations may not see any intermediate states between the state of the two files before the operation and after the operation. READs of the destination file will never see some blocks of the target area cloned without all of them being cloned. WRITEs of the source area will either have no effect on the data of the target file or be fully reflected in the target area of the destination file.
克隆操作是原子操作，因为其他操作可能看不到操作前后两个文件状态之间的任何中间状态。如果不克隆目标区域中的某些块，则读取目标文件时将永远不会看到这些块被克隆。源区域的写入将不会对目标文件的数据产生影响，或者完全反映在目标文件的目标区域中。
The completion status of the operation is indicated by cr_status.
操作的完成状态由cr_状态指示。
16.1. Operation 15: CB_OFFLOAD - Report the results of an asynchronous operation
16.1. 操作15:CB_卸载-报告异步操作的结果
<CODE BEGINS>
<代码开始>
struct write_response4 {
stateid4 wr_callback_id<1>;
length4 wr_count;
stable_how4 wr_committed;
verifier4 wr_writeverf;
};
struct write_response4 {
stateid4 wr_callback_id<1>;
length4 wr_count;
stable_how4 wr_committed;
verifier4 wr_writeverf;
};
union offload_info4 switch (nfsstat4 coa_status) {
case NFS4_OK:
write_response4 coa_resok4;
default:
length4 coa_bytes_copied;
};
union offload_info4 switch (nfsstat4 coa_status) {
case NFS4_OK:
write_response4 coa_resok4;
default:
length4 coa_bytes_copied;
};
struct CB_OFFLOAD4args {
nfs_fh4 coa_fh;
stateid4 coa_stateid;
offload_info4 coa_offload_info;
};
struct CB_OFFLOAD4args {
nfs_fh4 coa_fh;
stateid4 coa_stateid;
offload_info4 coa_offload_info;
};
<CODE ENDS>
<代码结束>
<CODE BEGINS>
<代码开始>
struct CB_OFFLOAD4res {
nfsstat4 cor_status;
};
struct CB_OFFLOAD4res {
nfsstat4 cor_status;
};
<CODE ENDS>
<代码结束>
CB_OFFLOAD is used to report to the client the results of an asynchronous operation, e.g., server-side COPY or WRITE_SAME. The coa_fh and coa_stateid identify the transaction, and the coa_status indicates success or failure. The coa_resok4.wr_callback_id MUST NOT be set. If the transaction failed, then the coa_bytes_copied contains the number of bytes copied before the failure occurred. The coa_bytes_copied value indicates the number of bytes copied but not which specific bytes have been copied.
CB_卸载用于向客户端报告异步操作的结果，例如，服务器端复制或写入相同操作的结果。coa_fh和coa_stateid标识交易，coa_状态表示成功或失败。不得设置coa_resok4.wr_回调_id。如果事务失败，则复制的coa_字节数包含失败发生前复制的字节数。coa_bytes_copied值表示复制的字节数，但不表示复制了哪些特定字节。
If the client supports any of the following operations:
如果客户端支持以下任何操作：
COPY: for both intra-server and inter-server asynchronous copies
复制：用于服务器内和服务器间异步复制
WRITE_SAME: for ADB initialization
写入相同：用于ADB初始化
then the client is REQUIRED to support the CB_OFFLOAD operation.
然后需要客户机支持CB_卸载操作。
There is a potential race between the reply to the original transaction on the forechannel and the CB_OFFLOAD callback on the backchannel. Section 2.10.6.3 of [RFC5661] describes how to handle this type of issue.
在forechannel上对原始事务的回复和backchannel上的CB_卸载回调之间可能存在竞争。[RFC5661]第2.10.6.3节描述了如何处理此类问题。
Upon success, the coa_resok4.wr_count presents for each operation:
成功后，每次操作的coa_resok4.wr_计数显示：
COPY: the total number of bytes copied
复制：复制的总字节数
WRITE_SAME: the same information that a synchronous WRITE_SAME would provide
WRITE_SAME：同步WRITE_SAME将提供的相同信息
NFSv4.2 has all of the security concerns present in NFSv4.1 (see Section 21 of [RFC5661]), as well as those present in the server-side copy (see Section 4.9) and in Labeled NFS (see Section 9.6).
NFSv4.2具有NFSv4.1（参见[RFC5661]第21节）中存在的所有安全问题，以及服务器端副本（参见第4.9节）和标记NFS（参见第9.6节）中存在的安全问题。
The IANA considerations for Labeled NFS are addressed in [RFC7569].
[RFC7569]中介绍了标记NFS的IANA注意事项。
[posix_fadvise] The Open Group, "Section 'posix_fadvise()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2016 Edition (HTML Version), ISBN 1937218812, September 2016, <http://www.opengroup.org/>.
[posix_fadvise]开放组，“开放组基本规范第7期系统接口的‘posix_fadvise（）’部分”，IEEE Std 1003.120016版（HTML版），ISBN 19372188112016年9月<http://www.opengroup.org/>.
[posix_fallocate] The Open Group, "Section 'posix_fallocate()' of System Interfaces of The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2016 Edition (HTML Version), ISBN 1937218812, September 2016, <http://www.opengroup.org/>.
[posix_fallocate]开放组，“开放组基本规范第7期系统接口的“posix_fallocate（）”部分”，IEEE Std 1003.120016版（HTML版），ISBN 19372188112016年9月<http://www.opengroup.org/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[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, <http://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月<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, <http://www.rfc-editor.org/info/rfc5662>.
[RFC5662]Shepler，S.，Ed.，Eisler，M.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4次要版本1外部数据表示标准（XDR）说明”，RFC 5662，DOI 10.17487/RFC5662，2010年1月<http://www.rfc-editor.org/info/rfc5662>.
[RFC7569] Quigley, D., Lu, J., and T. Haynes, "Registry Specification for Mandatory Access Control (MAC) Security Label Formats", RFC 7569, DOI 10.17487/RFC7569, July 2015, <http://www.rfc-editor.org/info/rfc7569>.
[RFC7569]Quigley，D.，Lu，J.，和T.Haynes，“强制访问控制（MAC）安全标签格式的注册表规范”，RFC 7569，DOI 10.17487/RFC7569，2015年7月<http://www.rfc-editor.org/info/rfc7569>.
[RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", RFC 7861, DOI 10.17487/RFC7861, November 2016, <http://www.rfc-editor.org/info/rfc7861>.
[RFC7861]Adamson，A.和N.Williams，“远程过程调用（RPC）安全版本3”，RFC 7861，DOI 10.17487/RFC7861，2016年11月<http://www.rfc-editor.org/info/rfc7861>.
[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, <http://www.rfc-editor.org/info/rfc7863>.
[RFC7863]Haynes，T.，“网络文件系统（NFS）版本4次要版本2外部数据表示标准（XDR）说明”，RFC 7863，DOI 10.17487/RFC7863，2016年11月<http://www.rfc-editor.org/info/rfc7863>.
[Ashdown08] Ashdown, L., "Chapter 15: Validating Database Files and Backups", Oracle Database Backup and Recovery User's Guide 11g Release 1 (11.1), August 2008, <http://download.oracle.com/docs/cd/B28359_01/backup.111/ b28270/rcmvalid.htm>.
[Ashdown08]Ashdown，L.，“第15章：验证数据库文件和备份”，《Oracle数据库备份和恢复用户指南》第11g版第1版（11.1），2008年8月<http://download.oracle.com/docs/cd/B28359_01/backup.111/ b28270/rcmvalid.htm>。
[Baira08] Bairavasundaram, L., Goodson, G., Schroeder, B., Arpaci-Dusseau, A., and R. Arpaci-Dusseau, "An Analysis of Data Corruption in the Storage Stack", Proceedings of the 6th USENIX Symposium on File and Storage Technologies (FAST '08), 2008, <http://www.usenix.org/events/fast08/tech/full_papers/ bairavasundaram/bairavasundaram.pdf>.
[Baira08]Bairavasundaram，L.，Goodson，G.，Schroeder，B.，Arpaci Dusseau，A.，和R.Arpaci Dusseau，“存储堆栈中数据损坏的分析”，第六届USENIX文件和存储技术研讨会论文集（FAST'08），2008年<http://www.usenix.org/events/fast08/tech/full_papers/ bairavasundaram/bairavasundaram.pdf>。
[IESG08] IESG, "IESG Processing of RFC Errata for the IETF Stream", July 2008, <https://www.ietf.org/iesg/statement/ errata-processing.html>.
[IESG08]IESG，“IESG处理IETF流的RFC勘误表”，2008年7月<https://www.ietf.org/iesg/statement/ 勘误表处理.html>。
[LB96] LaPadula, L. and D. Bell, "MITRE Technical Report 2547, Volume II", Journal of Computer Security, Volume 4, Issue 2-3, 239-263, IOS Press, Amsterdam, The Netherlands, January 1996.
[LB96]LaPadula，L.和D.Bell，“MITRE技术报告2547，第二卷”，《计算机安全杂志》，第4卷，第2-3期，239-263页，IOS出版社，荷兰阿姆斯特丹，1996年1月。
[McDougall07] McDougall, R. and J. Mauro, "Section 11.4.3: Detecting Memory Corruption", Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture, 2nd Edition, 2007.
[McDougall07]McDougall，R.和J.Mauro，“第11.4.3节：检测内存损坏”，Solaris内部：Solaris 10和OpenSolaris内核体系结构，第二版，2007年。
[NFSv4-Versioning] Noveck, D., "Rules for NFSv4 Extensions and Minor Versions", Work in Progress, draft-ietf-nfsv4-versioning-07, October 2016.
[NFSv4版本控制]Noveck，D.，“NFSv4扩展和次要版本的规则”，正在进行的工作，草稿-ietf-NFSv4-Versioning-07，2016年10月。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <http://www.rfc-editor.org/info/rfc959>.
[RFC959]Postel，J.和J.Reynolds，“文件传输协议”，STD 9，RFC 959，DOI 10.17487/RFC0959，1985年10月<http://www.rfc-editor.org/info/rfc959>.
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, DOI 10.17487/RFC1108, November 1991, <http://www.rfc-editor.org/info/rfc1108>.
[RFC1108]Kent，S.，“美国国防部互联网协议的安全选项”，RFC 1108，DOI 10.17487/RFC1108，1991年11月<http://www.rfc-editor.org/info/rfc1108>.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, DOI 10.17487/RFC2401, November 1998, <http://www.rfc-editor.org/info/rfc2401>.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，DOI 10.17487/RFC2401，1998年11月<http://www.rfc-editor.org/info/rfc2401>.
[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>.
[RFC4506]艾斯勒，M.，编辑，“XDR：外部数据表示标准”，STD 67，RFC 4506，DOI 10.17487/RFC4506，2006年5月<http://www.rfc-editor.org/info/rfc4506>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC5663] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS (pNFS) Block/Volume Layout", RFC 5663, DOI 10.17487/RFC5663, January 2010, <http://www.rfc-editor.org/info/rfc5663>.
[RFC5663]Black，D.，Fridella，S.，和J.Glasgow，“并行NFS（pNFS）块/卷布局”，RFC 5663，DOI 10.17487/RFC5663，2010年1月<http://www.rfc-editor.org/info/rfc5663>.
[RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, DOI 10.17487/RFC7204, April 2014, <http://www.rfc-editor.org/info/rfc7204>.
[RFC7204]Haynes，T.，“标记NFS的要求”，RFC 7204，DOI 10.17487/RFC7204，2014年4月<http://www.rfc-editor.org/info/rfc7204>.
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7530] Haynes, T., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7530]Haynes，T.，Ed.，和D.Noveck，Ed.，“网络文件系统（NFS）版本4协议”，RFC 7530，DOI 10.17487/RFC7530，2015年3月<http://www.rfc-editor.org/info/rfc7530>.
[Strohm11] Strohm, R., "Chapter 2: Data Blocks, Extents, and Segments", Oracle Database Concepts 11g Release 1 (11.1), January 2011, <http://download.oracle.com/docs/cd/B28359_01/server.111/ b28318/logical.htm>.
[Strohm11]Strohm，R.，“第2章：数据块、数据块和数据段”，Oracle数据库概念11g第1版（11.1），2011年1月<http://download.oracle.com/docs/cd/B28359_01/server.111/ b28318/logical.htm>。
[T10-SBC2] Elliott, R., Ed., "ANSI INCITS 405-2005, Information Technology - SCSI Block Commands - 2 (SBC-2)", November 2004, <ftp://www.t10.org/t10/document.05/05-344r0.pdf>.
[T10-SBC2]Elliott，R.，Ed.“ANSI INCITS 405-2005，信息技术-SCSI块命令-2（SBC-2）”，2004年11月<ftp://www.t10.org/t10/document.05/05-344r0.pdf>.
Acknowledgments
致谢
Tom Haynes would like to thank NetApp, Inc. for its funding of his time on this project.
Tom Haynes感谢NetApp，Inc.为此项目提供资金。
For the topic "sharing change attribute implementation characteristics with NFSv4 clients", the original document was by Trond Myklebust.
关于主题“与NFSv4客户端共享更改属性实现特征”，原始文档由Trond Myklebast编写。
For the NFS server-side copy, the original document was by James Lentini, Mike Eisler, Deepak Kenchammana, Anshul Madan, and Rahul Iyer. Tom Talpey co-authored an unpublished version of that document. It was also reviewed by a number of individuals: Pranoop Erasani, Tom Haynes, Arthur Lent, Trond Myklebust, Dave Noveck, Theresa Lingutla-Raj, Manjunath Shankararao, Satyam Vaghani, and Nico Williams. Anna Schumaker's early prototyping experience helped us avoid some traps. Also, both Olga Kornievskaia and Andy Adamson brought implementation experience to the use of copy stateids in the inter-server copy. Jorge Mora was able to optimize the handling of errors for the result of COPY.
对于NFS服务器端副本，原始文档由James Lentini、Mike Eisler、Deepak Kenchammana、Anshul Madan和Rahul Iyer编写。汤姆·塔尔佩（Tom Talpey）是该文件未出版版本的合著者。许多人也对该报告进行了审查：普拉努普·埃拉萨尼、汤姆·海恩斯、阿瑟·伦特、特隆·米克尔布斯特、戴夫·诺维克、特里萨·林格拉·拉吉、曼朱纳·尚卡拉奥、萨蒂扬·瓦加尼和尼科·威廉姆斯。Anna Schumaker的早期原型设计经验帮助我们避免了一些陷阱。此外，Olga Kornievskaia和Andy Adamson在服务器间副本中使用副本StateID时都带来了实现经验。豪尔赫·莫拉能够优化复制结果的错误处理。
For the NFS space reservation operations, the original document was by Mike Eisler, James Lentini, Manjunath Shankararao, and Rahul Iyer.
对于NFS空间保留操作，原始文档由Mike Eisler、James Lentini、Manjunath Shankararao和Rahul Iyer编写。
For the sparse file support, the original document was by Dean Hildebrand and Marc Eshel. Valuable input and advice was received from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and Richard Scheffenegger.
对于稀疏文件支持，原始文档由Dean Hildebrand和Marc Eshel编写。索林·费比什、布鲁斯·菲尔兹、本尼·哈利维、特隆·米克尔布斯特和理查德·谢弗内格提供了宝贵的意见和建议。
For the application I/O hints, the original document was by Dean Hildebrand, Mike Eisler, Trond Myklebust, and Sam Falkner. Some early reviewers included Benny Halevy and Pranoop Erasani.
对于应用程序I/O提示，原始文档由Dean Hildebrand、Mike Eisler、Trond Myklebast和Sam Falkner编写。一些早期的评论者包括Benny Halevy和Pranop Erasani。
For Labeled NFS, the original document was by David Quigley, James Morris, Jarrett Lu, and Tom Haynes. Peter Staubach, Trond Myklebust, Stephen Smalley, Sorin Faibish, Nico Williams, and David Black also contributed in the final push to get this accepted.
对于带标签的NFS，原始文档由David Quigley、James Morris、Jarrett Lu和Tom Haynes编写。彼得·斯塔巴赫、特隆德·米克勒布斯特、斯蒂芬·斯莫利、索林·费比什、尼科·威廉姆斯和大卫·布莱克也在最终推动这一目标被接受的过程中做出了贡献。
Christoph Hellwig was very helpful in getting the WRITE_SAME semantics to model more of what T10 was doing for WRITE SAME (10) [T10-SBC2]. And he led the push to get space reservations to more closely model the posix_fallocate() operation.
Christoph Hellwig非常有助于让WRITE_-SAME语义对T10为WRITE-SAME（10）所做的更多建模[T10-SBC2]。他还领导了一项推动空间预订的工作，以更紧密地模拟posix_fallocate（）操作。
Andy Adamson picked up the RPCSEC_GSSv3 work, which enabled both Labeled NFS and server-side copy to provide more secure options.
安迪·亚当森（Andy Adamson）拿起了RPCSEC_GSSv3的工作，它使带标签的NFS和服务器端拷贝都能够提供更安全的选项。
Christoph Hellwig provided the update to GETDEVICELIST.
Christoph Hellwig向GETDEVICELIST提供了更新。
Jorge Mora provided a very detailed review and caught some important issues with the tables.
豪尔赫·莫拉（Jorge Mora）提供了一份非常详细的审查报告，并抓住了表格中的一些重要问题。
During the review process, Talia Reyes-Ortiz helped the sessions run smoothly. While many people contributed here and there, the core reviewers were Andy Adamson, Pranoop Erasani, Bruce Fields, Chuck Lever, Trond Myklebust, David Noveck, Peter Staubach, and Mike Kupfer.
在审查过程中，塔利亚·雷耶斯·奥尔蒂斯帮助会议顺利进行。虽然有很多人在这里或那里作出了贡献，但核心评论员是安迪·亚当森、普拉努普·埃拉萨尼、布鲁斯·菲尔兹、查克·利弗、特隆·米克尔布斯特、大卫·诺维克、彼得·斯塔巴赫和迈克·库普弗。
Elwyn Davies was the General Area Reviewer for this document, and his insights as to the relationship of this document and both [RFC5661] and [RFC7530] were very much appreciated!
Elwyn Davies是本文件的一般区域评审员，非常感谢他对本文件与[RFC5661]和[RFC7530]之间关系的见解！
Author's Address
作者地址
Thomas Haynes Primary Data, Inc. 4300 El Camino Real Ste 100 Los Altos, CA 94022 United States of America
Thomas Haynes Primary Data，Inc.4300 El Camino Real Ste 100 Los Altos，加利福尼亚州，美利坚合众国94022
Phone: +1 408 215 1519
Email: thomas.haynes@primarydata.com
Phone: +1 408 215 1519
Email: thomas.haynes@primarydata.com