Network Working Group S. Shepler
Request for Comments: 3010 B. Callaghan
Obsoletes: 1813, 1094 D. Robinson
Category: Standards Track R. Thurlow
Sun Microsystems Inc.
C. Beame
Hummingbird Ltd.
M. Eisler
Zambeel, Inc.
D. Noveck
Network Appliance, Inc.
December 2000
NFS version 4 Protocol
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and 3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.
NFS（ネットワークファイルシステム）バージョン4は、NFSプロトコルバージョン2 [RFC1094]及び3 [RFC1813]に遺産を負っている分散ファイルシステムプロトコルです。ファイルのロックとマウントプロトコルのサポートを統合しながら、以前のバージョンとは異なり、NFSバージョン4プロトコルは、従来のファイルアクセスをサポートしています。また、強力なセキュリティ（およびその交渉）、化合物の操作、クライアントのキャッシュ、および国際化のためのサポートが追加されました。もちろん、注意はNFSバージョン4は、インターネット環境でも動作させるに適用されています。
Key Words
キーワード
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Overview of NFS Version 4 Features . . . . . . . . . . . . 6
1.1.1. RPC and Security . . . . . . . . . . . . . . . . . . . . 6
1.1.2. Procedure and Operation Structure . . . . . . . . . . . 7
1.1.3. File System Model . . . . . . . . . . . . . . . . . . . 8
1.1.3.1. Filehandle Types . . . . . . . . . . . . . . . . . . . 8
1.1.3.2. Attribute Types . . . . . . . . . . . . . . . . . . . 8
1.1.3.3. File System Replication and Migration . . . . . . . . 9
1.1.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . . . 9
1.1.5. File locking . . . . . . . . . . . . . . . . . . . . . . 9
1.1.6. Client Caching and Delegation . . . . . . . . . . . . . 10
1.2. General Definitions . . . . . . . . . . . . . . . . . . . 11
2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . 12
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . . 12
2.2. Structured Data Types . . . . . . . . . . . . . . . . . . 14
3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . 18
3.1. Ports and Transports . . . . . . . . . . . . . . . . . . . 18
3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . . 18
3.2.1. Security mechanisms for NFS version 4 . . . . . . . . . 19
3.2.1.1. Kerberos V5 as security triple . . . . . . . . . . . . 19
3.2.1.2. LIPKEY as a security triple . . . . . . . . . . . . . 19
3.2.1.3. SPKM-3 as a security triple . . . . . . . . . . . . . 20
3.3. Security Negotiation . . . . . . . . . . . . . . . . . . . 21
3.3.1. Security Error . . . . . . . . . . . . . . . . . . . . . 21
3.3.2. SECINFO . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4. Callback RPC Authentication . . . . . . . . . . . . . . . 22
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . . 24
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . . . 24
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . . . 24
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . . 25
4.2.1. General Properties of a Filehandle . . . . . . . . . . . 25
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . . . 26
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . . . 26
4.2.4. One Method of Constructing a Volatile Filehandle . . . . 28
4.3. Client Recovery from Filehandle Expiration . . . . . . . . 28
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Mandatory Attributes . . . . . . . . . . . . . . . . . . . 30
5.2. Recommended Attributes . . . . . . . . . . . . . . . . . . 30
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . . 31
5.4. Mandatory Attributes - Definitions . . . . . . . . . . . . 31
5.5. Recommended Attributes - Definitions . . . . . . . . . . . 33
5.6. Interpreting owner and owner_group . . . . . . . . . . . . 38
5.7. Character Case Attributes . . . . . . . . . . . . . . . . 39
5.8. Quota Attributes . . . . . . . . . . . . . . . . . . . . . 39
5.9. Access Control Lists . . . . . . . . . . . . . . . . . . . 40
5.9.1. ACE type . . . . . . . . . . . . . . . . . . . . . . . . 41
5.9.2. ACE flag . . . . . . . . . . . . . . . . . . . . . . . . 41
5.9.3. ACE Access Mask . . . . . . . . . . . . . . . . . . . . 43
5.9.4. ACE who . . . . . . . . . . . . . . . . . . . . . . . . 44
6. File System Migration and Replication . . . . . . . . . . . 44
6.1. Replication . . . . . . . . . . . . . . . . . . . . . . . 45
6.2. Migration . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3. Interpretation of the fs_locations Attribute . . . . . . . 46
6.4. Filehandle Recovery for Migration or Replication . . . . . 47
7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . 47
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . . 47
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . . 48
7.3. Server Pseudo File System . . . . . . . . . . . . . . . . 48
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . . 49
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . . 49
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . . 49
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . . 49
7.8. Security Policy and Name Space Presentation . . . . . . . 50
8. File Locking and Share Reservations . . . . . . . . . . . . 50
8.1. Locking . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . . . 51
8.1.2. Server Release of Clientid . . . . . . . . . . . . . . . 53
8.1.3. nfs_lockowner and stateid Definition . . . . . . . . . . 54
8.1.4. Use of the stateid . . . . . . . . . . . . . . . . . . . 55
8.1.5. Sequencing of Lock Requests . . . . . . . . . . . . . . 56
8.1.6. Recovery from Replayed Requests . . . . . . . . . . . . 56
8.1.7. Releasing nfs_lockowner State . . . . . . . . . . . . . 57
8.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . . 57
8.3. Blocking Locks . . . . . . . . . . . . . . . . . . . . . . 58
8.4. Lease Renewal . . . . . . . . . . . . . . . . . . . . . . 58
8.5. Crash Recovery . . . . . . . . . . . . . . . . . . . . . . 59
8.5.1. Client Failure and Recovery . . . . . . . . . . . . . . 59
8.5.2. Server Failure and Recovery . . . . . . . . . . . . . . 60
8.5.3. Network Partitions and Recovery . . . . . . . . . . . . 62
8.6. Recovery from a Lock Request Timeout or Abort . . . . . . 63
8.7. Server Revocation of Locks . . . . . . . . . . . . . . . . 63
8.8. Share Reservations . . . . . . . . . . . . . . . . . . . . 65
8.9. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . . 65
8.10. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 66
8.11. Short and Long Leases . . . . . . . . . . . . . . . . . . 66
8.12. Clocks and Calculating Lease Expiration . . . . . . . . . 67
8.13. Migration, Replication and State . . . . . . . . . . . . 67
8.13.1. Migration and State . . . . . . . . . . . . . . . . . . 67
8.13.2. Replication and State . . . . . . . . . . . . . . . . . 68
8.13.3. Notification of Migrated Lease . . . . . . . . . . . . 69
9. Client-Side Caching . . . . . . . . . . . . . . . . . . . . 69
9.1. Performance Challenges for Client-Side Caching . . . . . . 70
9.2. Delegation and Callbacks . . . . . . . . . . . . . . . . . 71
9.2.1. Delegation Recovery . . . . . . . . . . . . . . . . . . 72
9.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . . 74
9.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . . . 74
9.3.2. Data Caching and File Locking . . . . . . . . . . . . . 75
9.3.3. Data Caching and Mandatory File Locking . . . . . . . . 77
9.3.4. Data Caching and File Identity . . . . . . . . . . . . . 77
9.4. Open Delegation . . . . . . . . . . . . . . . . . . . . . 78
9.4.1. Open Delegation and Data Caching . . . . . . . . . . . . 80
9.4.2. Open Delegation and File Locks . . . . . . . . . . . . . 82
9.4.3. Recall of Open Delegation . . . . . . . . . . . . . . . 82
9.4.4. Delegation Revocation . . . . . . . . . . . . . . . . . 84
9.5. Data Caching and Revocation . . . . . . . . . . . . . . . 84
9.5.1. Revocation Recovery for Write Open Delegation . . . . . 85
9.6. Attribute Caching . . . . . . . . . . . . . . . . . . . . 85
9.7. Name Caching . . . . . . . . . . . . . . . . . . . . . . . 86
9.8. Directory Caching . . . . . . . . . . . . . . . . . . . . 87
10. Minor Versioning . . . . . . . . . . . . . . . . . . . . . 88
11. Internationalization . . . . . . . . . . . . . . . . . . . 91
11.1. Universal Versus Local Character Sets . . . . . . . . . . 91
11.2. Overview of Universal Character Set Standards . . . . . . 92
11.3. Difficulties with UCS-4, UCS-2, Unicode . . . . . . . . . 93
11.4. UTF-8 and its solutions . . . . . . . . . . . . . . . . . 94
11.5. Normalization . . . . . . . . . . . . . . . . . . . . . . 94
12. Error Definitions . . . . . . . . . . . . . . . . . . . . . 95
13. NFS Version 4 Requests . . . . . . . . . . . . . . . . . . 99
13.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 100
13.2. Evaluation of a Compound Request . . . . . . . . . . . . 100
13.3. Synchronous Modifying Operations . . . . . . . . . . . . 101
13.4. Operation Values . . . . . . . . . . . . . . . . . . . . 102
14. NFS Version 4 Procedures . . . . . . . . . . . . . . . . . 102
14.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 102
14.2. Procedure 1: COMPOUND - Compound Operations . . . . . . . 102
14.2.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 105
14.2.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 108
14.2.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . 109
14.2.4. Operation 6: CREATE - Create a Non-Regular File Object. 112
14.2.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . 114
14.2.6. Operation 8: DELEGRETURN - Return Delegation . . . . . 115
14.2.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 115
14.2.8. Operation 10: GETFH - Get Current Filehandle . . . . . 117
14.2.9. Operation 11: LINK - Create Link to a File . . . . . . 118
14.2.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . 119
14.2.11. Operation 13: LOCKT - Test For Lock . . . . . . . . . 121
14.2.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . 122
14.2.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . 123
14.2.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . 126
14.2.15. Operation 17: NVERIFY - Verify Difference in
Attributes . . . . . . . . . . . . . . . . . . . . . . 127
14.2.16. Operation 18: OPEN - Open a Regular File . . . . . . . 128
14.2.17. Operation 19: OPENATTR - Open Named Attribute
Directory . . . . . . . . . . . . . . . . . . . . . . 137
14.2.18. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . 138
14.2.19. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access 140
14.2.20. Operation 22: PUTFH - Set Current Filehandle . . . . . 141
14.2.21. Operation 23: PUTPUBFH - Set Public Filehandle . . . . 142
14.2.22. Operation 24: PUTROOTFH - Set Root Filehandle . . . . 143
14.2.23. Operation 25: READ - Read from File . . . . . . . . . 144
14.2.24. Operation 26: READDIR - Read Directory . . . . . . . . 146
14.2.25. Operation 27: READLINK - Read Symbolic Link . . . . . 150
14.2.26. Operation 28: REMOVE - Remove Filesystem Object . . . 151
14.2.27. Operation 29: RENAME - Rename Directory Entry . . . . 153
14.2.28. Operation 30: RENEW - Renew a Lease . . . . . . . . . 155
14.2.29. Operation 31: RESTOREFH - Restore Saved Filehandle . . 156
14.2.30. Operation 32: SAVEFH - Save Current Filehandle . . . . 157
14.2.31. Operation 33: SECINFO - Obtain Available Security . . 158
14.2.32. Operation 34: SETATTR - Set Attributes . . . . . . . . 160
14.2.33. Operation 35: SETCLIENTID - Negotiate Clientid . . . . 162
14.2.34. Operation 36: SETCLIENTID_CONFIRM - Confirm Clientid . 163
14.2.35. Operation 37: VERIFY - Verify Same Attributes . . . . 164
14.2.36. Operation 38: WRITE - Write to File . . . . . . . . . 166
15. NFS Version 4 Callback Procedures . . . . . . . . . . . . . 170
15.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . . 170
15.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 171
15.2.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . 172
15.2.2. Operation 4: CB_RECALL - Recall an Open Delegation . . 173
16. Security Considerations . . . . . . . . . . . . . . . . . . 174
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . 174
17.1. Named Attribute Definition . . . . . . . . . . . . . . . 174
18. RPC definition file . . . . . . . . . . . . . . . . . . . . 175
19. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 206
20. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . 210
20.1. Editor's Address . . . . . . . . . . . . . . . . . . . . 210
20.2. Authors' Addresses . . . . . . . . . . . . . . . . . . . 210
20.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . 211
21. Full Copyright Statement . . . . . . . . . . . . . . . . . 212
The NFS version 4 protocol is a further revision of the NFS protocol defined already by versions 2 [RFC1094] and 3 [RFC1813]. It retains the essential characteristics of previous versions: design for easy recovery, independent of transport protocols, operating systems and filesystems, simplicity, and good performance. The NFS version 4 revision has the following goals: o Improved access and good performance on the Internet.
NFSバージョン4プロトコル、バージョン2 [RFC1094]及び3 [RFC1813]で既に定義されたNFSプロトコルのさらなるリビジョンです。簡単に回復のための設計、トランスポートプロトコル、オペレーティングシステムとファイルシステムの独立した、シンプルさ、および良好なパフォーマンス：これは、以前のバージョンの本質的な特徴を保持します。インターネット上でアクセスの改善と優れたパフォーマンスO：NFSバージョン4改訂は、次の目標を持っています。
The protocol is designed to transit firewalls easily, perform well where latency is high and bandwidth is low, and scale to very large numbers of clients per server.
プロトコルは、レイテンシが高く、帯域幅が低い場合も実行し、簡単にトランジットのファイアウォールに設計されており、サーバーあたりのクライアントの規模に非常に大きな数字です。
o Strong security with negotiation built into the protocol.
O交渉を持つ強力なセキュリティプロトコルに組み込まれています。
The protocol builds on the work of the ONCRPC working group in supporting the RPCSEC_GSS protocol. Additionally, the NFS version 4 protocol provides a mechanism to allow clients and servers the ability to negotiate security and require clients and servers to support a minimal set of security schemes.
プロトコルは、RPCSEC_GSSプロトコルをサポートするONCRPCワーキンググループの作業に基づいています。また、NFSバージョン4プロトコルは、クライアントとサーバにセキュリティをネゴシエートし、セキュリティ方式の最小セットをサポートするために、クライアントとサーバーを必要とする機能を許可するためのメカニズムを提供します。
o Good cross-platform interoperability.
Oグッドクロスプラットフォームの相互運用性。
The protocol features a file system model that provides a useful, common set of features that does not unduly favor one file system or operating system over another.
プロトコルは不当に別の上に1つのファイル・システムまたはオペレーティング・システムを支持していない機能の便利な、共通セットを提供し、ファイルシステムのモデルを提供しています。
o Designed for protocol extensions.
Oプロトコルの拡張のために設計されています。
The protocol is designed to accept standard extensions that do not compromise backward compatibility.
プロトコルは、下位互換性を損なわない標準の拡張を受け入れるように設計されています。
To provide a reasonable context for the reader, the major features of NFS version 4 protocol will be reviewed in brief. This will be done to provide an appropriate context for both the reader who is familiar with the previous versions of the NFS protocol and the reader that is new to the NFS protocols. For the reader new to the NFS protocols, there is still a fundamental knowledge that is expected. The reader should be familiar with the XDR and RPC protocols as described in [RFC1831] and [RFC1832]. A basic knowledge of file systems and distributed file systems is expected as well.
読者のための合理的なコンテキストを提供するために、NFSバージョン4プロトコルの主な機能は、簡単に審査されます。これは、NFSプロトコルとNFSプロトコルに新しく追加され、リーダの以前のバージョンに精通している読者の両方のために適切なコンテキストを提供するために行われます。 NFSプロトコルへの新しい読者のために、期待されている基本的な知識がまだあります。 [RFC1831]及び[RFC1832]に記載されているように、リーダはXDRとRPCプロトコルに精通しなければなりません。ファイルシステムと分散ファイルシステムの基本的な知識も同様に期待されています。
As with previous versions of NFS, the External Data Representation (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFS version 4 protocol are those defined in [RFC1831] and [RFC1832]. To meet end to end security requirements, the RPCSEC_GSS framework [RFC2203] will be used to extend the basic RPC security. With the use of RPCSEC_GSS, various mechanisms can be provided to offer authentication, integrity, and privacy to the NFS version 4 protocol. Kerberos V5 will be used as described in [RFC1964] to provide one security framework. The LIPKEY GSS-API mechanism described in
NFSの以前のバージョンと同様に、NFSバージョン4プロトコルのために使用される外部データ表現（XDR）とリモートプロシージャコール（RPC）メカニズムは、[RFC1831]及び[RFC1832]で定義されたものです。セキュリティ要件をエンドツーエンドを満たすために、RPCSEC_GSSフレームワーク[RFC2203]は、基本的なRPCセキュリティを拡張するために使用されます。 RPCSEC_GSSを使用すると、さまざまなメカニズムはNFSバージョン4プロトコルに認証、整合性、およびプライバシーを提供するために提供することができます。 [RFC1964]に記載されているようにケルベロスV5は、一つのセキュリティフレームワークを提供するために使用されます。で説明LIPKEY GSS-APIメカニズム
[RFC2847] will be used to provide for the use of user password and server public key by the NFS version 4 protocol. With the use of RPCSEC_GSS, other mechanisms may also be specified and used for NFS version 4 security.
[RFC2847]は、ユーザパスワードとNFSバージョン4プロトコルによってサーバ公開鍵の使用を提供するために使用されるであろう。 RPCSEC_GSSを使用して、他のメカニズムも指定することができ、NFSバージョン4セキュリティのために使用されます。
To enable in-band security negotiation, the NFS version 4 protocol has added a new operation which provides the client a method of querying the server about its policies regarding which security mechanisms must be used for access to the server's file system resources. With this, the client can securely match the security mechanism that meets the policies specified at both the client and server.
インバンドセキュリティネゴシエーションを有効にするには、NFSバージョン4プロトコルは、クライアントにセキュリティメカニズムは、サーバーのファイル・システム・リソースへのアクセスに使用する必要がありますについての方針についてのサーバーを照会する方法を提供し、新しい操作を追加しました。これにより、クライアントが安全に、クライアントとサーバの両方で指定したポリシーを満たしているセキュリティ・メカニズムを一致させることができます。
A significant departure from the previous versions of the NFS protocol is the introduction of the COMPOUND procedure. For the NFS version 4 protocol, there are two RPC procedures, NULL and COMPOUND. The COMPOUND procedure is defined in terms of operations and these operations correspond more closely to the traditional NFS procedures. With the use of the COMPOUND procedure, the client is able to build simple or complex requests. These COMPOUND requests allow for a reduction in the number of RPCs needed for logical file system operations. For example, without previous contact with a server a client will be able to read data from a file in one request by combining LOOKUP, OPEN, and READ operations in a single COMPOUND RPC. With previous versions of the NFS protocol, this type of single request was not possible.
NFSプロトコルの旧バージョンからの有意な逸脱は、化合物処置の導入です。 NFSバージョン4プロトコル、二つRPC手順、NULLおよび化合物があります。 COMPOUND手順は動作の観点から定義され、これらの動作は、従来のNFSの手順をより密接に対応します。 COMPOUND手順を使用すると、クライアントは、単純または複雑な要求を構築することができます。これらの化合物の要求は、論理ファイルシステム操作のために必要なRPCの数の減少を可能とします。たとえば、サーバーとの以前の接触せずに、クライアントは、単一の化合物のRPCでLOOKUP、OPEN、およびREAD操作を組み合わせることにより、一つのリクエストでファイルからデータを読み取ることができるようになります。 NFSプロトコルの以前のバージョンでは、単一の要求のこのタイプは不可能でした。
The model used for COMPOUND is very simple. There is no logical OR or ANDing of operations. The operations combined within a COMPOUND request are evaluated in order by the server. Once an operation returns a failing result, the evaluation ends and the results of all evaluated operations are returned to the client.
化合物に対して使用されるモデルは非常に単純です。操作の論理的ORまたはAND演算はありません。複合要求内で組み合わせる操作はサーバ順に評価されます。操作が失敗し、結果を返した後、評価が終了し、全ての評価の操作の結果がクライアントに返されます。
The NFS version 4 protocol continues to have the client refer to a file or directory at the server by a "filehandle". The COMPOUND procedure has a method of passing a filehandle from one operation to another within the sequence of operations. There is a concept of a "current filehandle" and "saved filehandle". Most operations use the "current filehandle" as the file system object to operate upon. The "saved filehandle" is used as temporary filehandle storage within a COMPOUND procedure as well as an additional operand for certain operations.
NFSバージョン4プロトコルは、クライアントが「ファイルハンドル」により、サーバーにあるファイルまたはディレクトリを参照する必要があり続けています。 COMPOUND手順は動作のシーケンス内の別の操作からファイルハンドルを渡す方法を有します。 「現在のファイルハンドル」と「保存されたファイルハンドル」の概念があります。ほとんどの操作は、時に動作するファイル・システム・オブジェクトとして「現在のファイルハンドル」を使用します。 「保存されたファイルハンドルは、」COMPOUND手順内の一時ファイルハンドルの保存だけでなく、特定の操作のための追加のオペランドとして使用されています。
The general file system model used for the NFS version 4 protocol is the same as previous versions. The server file system is hierarchical with the regular files contained within being treated as opaque byte streams. In a slight departure, file and directory names are encoded with UTF-8 to deal with the basics of internationalization.
NFSバージョン4プロトコルに使用される一般的なファイルシステム・モデルは、以前のバージョンと同じです。サーバーのファイルシステムは、不透明なバイトストリームとして処理されている内に含まれ、通常のファイルと階層的です。若干の出発では、ファイル名やディレクトリ名は、国際化の基礎に対処するためにUTF-8でエンコードされています。
The NFS version 4 protocol does not require a separate protocol to provide for the initial mapping between path name and filehandle. Instead of using the older MOUNT protocol for this mapping, the server provides a ROOT filehandle that represents the logical root or top of the file system tree provided by the server. The server provides multiple file systems by gluing them together with pseudo file systems. These pseudo file systems provide for potential gaps in the path names between real file systems.
NFSバージョン4プロトコルは、パス名とファイルハンドルとの間の最初のマッピングを提供するために、別のプロトコルを必要としません。このマッピングの古いMOUNTプロトコルを使用する代わりに、サーバは、サーバが提供するファイル・システム・ツリーの論理ルート又はトップを表すROOTファイルハンドルを提供します。サーバーは、擬似ファイルシステムでそれらを一緒に接着することにより、複数のファイルシステムを提供します。これらの疑似ファイルシステムは、実際のファイルシステム間のパス名の潜在的なギャップを提供します。
In previous versions of the NFS protocol, the filehandle provided by the server was guaranteed to be valid or persistent for the lifetime of the file system object to which it referred. For some server implementations, this persistence requirement has been difficult to meet. For the NFS version 4 protocol, this requirement has been relaxed by introducing another type of filehandle, volatile. With persistent and volatile filehandle types, the server implementation can match the abilities of the file system at the server along with the operating environment. The client will have knowledge of the type of filehandle being provided by the server and can be prepared to deal with the semantics of each.
NFSプロトコルの旧バージョンでは、サーバによって提供されるファイルハンドルは、それが呼ばれるファイル・システム・オブジェクトの寿命のために有効または永続的であることが保証されました。いくつかのサーバ実装では、この永続性要件は満たすことが困難でした。 NFSバージョン4プロトコルのために、この要求はファイルハンドル、揮発性の他の種類を導入することによって緩和されています。持続的かつ揮発性ファイルハンドルタイプでは、サーバの実装は、動作環境と一緒にサーバーでのファイルシステムの能力を一致させることができます。クライアントは、サーバによって提供されているファイルハンドルのタイプについての知識を持つことになりますし、それぞれのセマンティクスを扱うように調製することができます。
The NFS version 4 protocol introduces three classes of file system or file attributes. Like the additional filehandle type, the classification of file attributes has been done to ease server implementations along with extending the overall functionality of the NFS protocol. This attribute model is structured to be extensible such that new attributes can be introduced in minor revisions of the protocol without requiring significant rework.
NFSバージョン4プロトコルは、ファイルシステムやファイル属性の3つのクラスが導入されました。追加のファイルハンドルタイプと同様に、ファイル属性の分類は、NFSプロトコルの全体的な機能を拡張するとともに、サーバの実装を容易にするために行われてきました。この属性モデルは、新たな属性が大幅に手直しを必要とせずに、プロトコルのマイナーリビジョンで導入することができるように拡張できるように構成されています。
The three classifications are: mandatory, recommended and named attributes. This is a significant departure from the previous attribute model used in the NFS protocol. Previously, the attributes for the file system and file objects were a fixed set of mainly Unix attributes. If the server or client did not support a particular attribute, it would have to simulate the attribute the best it could.
3つの分類があります：必須、推奨と命名された属性。これは、NFSプロトコルで使用される前の属性モデルから大幅に逸脱しています。以前は、ファイルシステムとファイルオブジェクトの属性は、主にUNIXの属性の固定セットでした。サーバーまたはクライアントが特定の属性をサポートしていなかった場合、それは属性にそれはできる最善をシミュレートする必要があります。
Mandatory attributes are the minimal set of file or file system attributes that must be provided by the server and must be properly represented by the server. Recommended attributes represent different file system types and operating environments. The recommended attributes will allow for better interoperability and the inclusion of more operating environments. The mandatory and recommended attribute sets are traditional file or file system attributes. The third type of attribute is the named attribute. A named attribute is an opaque byte stream that is associated with a directory or file and referred to by a string name. Named attributes are meant to be used by client applications as a method to associate application specific data with a regular file or directory.
必須の属性は、サーバによって提供されなければならないと、正しくサーバーで表現しなければならないファイルやファイルシステム属性の最小セットです。推奨属性は異なるファイルシステムの種類と動作環境を表しています。お勧めの属性は、より良い相互運用性とより多くの動作環境を含めることができるようになります。必須および推奨される属性セットは、従来のファイルまたはファイルシステム属性です。属性の第三のタイプは、名前付き属性です。名前の属性は、ディレクトリやファイルに関連付けられており、文字列名で呼ばれる不透明なバイトストリームです。名前付き属性は、通常のファイルまたはディレクトリとアプリケーション固有のデータを関連付けるための方法として、クライアントアプリケーションによって使用されることを意味しています。
One significant addition to the recommended set of file attributes is the Access Control List (ACL) attribute. This attribute provides for directory and file access control beyond the model used in previous versions of the NFS protocol. The ACL definition allows for specification of user and group level access control.
ファイル属性の推奨設定する1つの重要な追加は、アクセス制御リスト（ACL）の属性です。この属性は、NFSプロトコルの以前のバージョンで使用されたモデルを越えたディレクトリとファイルのアクセス制御を提供します。 ACL定義は、ユーザおよびグループレベルのアクセス制御の仕様を可能にします。
With the use of a special file attribute, the ability to migrate or replicate server file systems is enabled within the protocol. The file system locations attribute provides a method for the client to probe the server about the location of a file system. In the event of a migration of a file system, the client will receive an error when operating on the file system and it can then query as to the new file system location. Similar steps are used for replication, the client is able to query the server for the multiple available locations of a particular file system. From this information, the client can use its own policies to access the appropriate file system location.
特殊なファイル属性を使用すると、サーバーのファイル・システムを移行または複製する能力は、プロトコル内で有効になっています。システム・ロケーション属性ファイルは、ファイルシステムの場所についてのサーバーを調査するためのクライアントのための方法を提供します。ファイルシステム上で動作しているときに、ファイルシステムの移行が発生した場合、クライアントは、エラーを受け取ることになりますし、それは、新しいファイルシステムの場所へと問い合わせることができます。同様の手順は、レプリケーションに使用され、クライアントが特定のファイル・システムの複数の利用可能な場所については、サーバに照会することができます。この情報から、クライアントは、適切なファイルシステムの場所にアクセスするために、独自のポリシーを使用することができます。
The NFS version 4 protocol introduces OPEN and CLOSE operations. The OPEN operation provides a single point where file lookup, creation, and share semantics can be combined. The CLOSE operation also provides for the release of state accumulated by OPEN.
NFSバージョン4プロトコルは、開閉操作を導入します。 OPEN操作は、ファイルの検索、作成、および共有のセマンティクスを組み合わせることができ、単一のポイントを提供します。 CLOSE動作もOPENによって蓄積された状態の放出を提供します。
With the NFS version 4 protocol, the support for byte range file locking is part of the NFS protocol. The file locking support is structured so that an RPC callback mechanism is not required. This is a departure from the previous versions of the NFS file locking protocol, Network Lock Manager (NLM). The state associated with file locks is maintained at the server under a lease-based model. The server defines a single lease period for all state held by a NFS client. If the client does not renew its lease within the defined period, all state associated with the client's lease may be released by the server. The client may renew its lease with use of the RENEW operation or implicitly by use of other operations (primarily READ).
NFSバージョン4プロトコルと、バイト範囲ファイルのロックのためのサポートは、NFSプロトコルの一部です。 RPCコールバック機構が必要とされないようにファイルロックのサポートが構成されています。これは、NFSファイルロックプロトコル、ネットワークロックマネージャ（NLM）の以前のバージョンからの脱却です。ファイルロックに関連付けられた状態は、リースベースのモデルの下でサーバに維持されます。サーバーは、NFSクライアントによって保持されているすべての状態のための単一のリース期間を定義します。クライアントが定義された期間内にそのリースを更新しない場合は、クライアントのリースに関連するすべての状態がサーバーによって解放されてもよいです。クライアントは、（主にREAD）RENEW操作を使用してまたは暗黙的に他の操作を使用することにより、そのリースを更新することができます。
The file, attribute, and directory caching for the NFS version 4 protocol is similar to previous versions. Attributes and directory information are cached for a duration determined by the client. At the end of a predefined timeout, the client will query the server to see if the related file system object has been updated.
NFSバージョン4プロトコル用のファイル、属性、およびディレクトリのキャッシングは、以前のバージョンと同様です。属性と、ディレクトリ情報は、クライアントによって決定期間中にキャッシュされます。事前に定義されたタイムアウトの終わりには、クライアントは、関連するファイル・システム・オブジェクトが更新されているかどうかを確認するためにサーバーを照会します。
For file data, the client checks its cache validity when the file is opened. A query is sent to the server to determine if the file has been changed. Based on this information, the client determines if the data cache for the file should kept or released. Also, when the file is closed, any modified data is written to the server.
ファイルを開いたときに、ファイルデータの場合、クライアントは、そのキャッシュの有効性をチェックします。クエリは、ファイルが変更されているかどうかを判断するためにサーバーに送信されます。ファイルのためのデータ・キャッシュを保持または解放する必要がある場合、この情報に基づいて、クライアントが決定します。ファイルを閉じたときにも、任意の変更されたデータがサーバーに書き込まれます。
If an application wants to serialize access to file data, file locking of the file data ranges in question should be used.
アプリケーションがファイルデータへのアクセスをシリアル化したい場合は、問題のファイルのデータ範囲のファイルのロックを使用する必要があります。
The major addition to NFS version 4 in the area of caching is the ability of the server to delegate certain responsibilities to the client. When the server grants a delegation for a file to a client, the client is guaranteed certain semantics with respect to the sharing of that file with other clients. At OPEN, the server may provide the client either a read or write delegation for the file. If the client is granted a read delegation, it is assured that no other client has the ability to write to the file for the duration of the delegation. If the client is granted a write delegation, the client is assured that no other client has read or write access to the file.
キャッシングの領域でのNFSバージョン4への主要な追加は、クライアントに一定の責任を委譲するには、サーバーの能力です。サーバーがクライアントへのファイルの委任を許可した場合、クライアントは他のクライアントとそのファイルの共有に対して一定のセマンティクスを保証されています。 OPENで、サーバはクライアントのいずれかの読み取りを提供することができるか、ファイルのための委任を書きます。クライアントが読み委任を許可された場合は、他のクライアントが委任期間中のファイルへの書き込み機能を持っていないことが保証されます。クライアントが書き込みの委任を許可された場合、クライアントは、他のクライアントは読まないか、ファイルへの書き込みアクセスをしていることが保証されます。
Delegations can be recalled by the server. If another client requests access to the file in such a way that the access conflicts with the granted delegation, the server is able to notify the initial client and recall the delegation. This requires that a callback path exist between the server and client. If this callback path does not exist, then delegations can not be granted. The essence of a delegation is that it allows the client to locally service operations such as OPEN, CLOSE, LOCK, LOCKU, READ, WRITE without immediate interaction with the server.
代表団は、サーバによって呼び出すことができます。別のクライアント要求が許可された代表団とのアクセスが競合するような方法でファイルにアクセスした場合、サーバーは最初のクライアントに通知し、委任をリコールすることができます。これは、コールバックパスは、サーバとクライアントの間に存在することが必要です。このコールバックパスが存在しない場合は、代表団は付与されません。代表団の本質は、それは、そのようなOPEN、CLOSE、LOCK、LOCKU、READ、などローカルサービス操作にクライアントがサーバーとの直接の相互作用なしWRITE可能とすることです。
The following definitions are provided for the purpose of providing an appropriate context for the reader.
以下の定義は、読者のために適切なコンテキストを提供する目的のために提供されます。
Client The "client" is the entity that accesses the NFS server's resources. The client may be an application which contains the logic to access the NFS server directly. The client may also be the traditional operating system client remote file system services for a set of applications.
「クライアント」クライアントがNFSサーバーのリソースにアクセスするエンティティです。クライアントは直接NFSサーバーにアクセスするためのロジックが含まれているアプリケーションであってもよいです。また、クライアントはアプリケーションのセットのための伝統的なオペレーティングシステムクライアントリモートファイルシステムサービスであってもよいです。
In the case of file locking the client is the entity that
maintains a set of locks on behalf of one or more
applications. This client is responsible for crash or
failure recovery for those locks it manages.
Note that multiple clients may share the same transport and multiple clients may exist on the same network node.
複数のクライアントが同一のトランスポートを共有してもよいし、複数のクライアントが同一のネットワーク・ノードに存在してもよいことに留意されたいです。
Clientid A 64-bit quantity used as a unique, short-hand reference to a client supplied Verifier and ID. The server is responsible for supplying the Clientid.
検証およびIDを供給し、クライアントに固有の、ショートハンド基準として使用される64ビット量をCLIENTID。サーバーは、CLIENTIDを供給するための責任があります。
Lease An interval of time defined by the server for which the client is irrevocably granted a lock. At the end of a lease period the lock may be revoked if the lease has not been extended. The lock must be revoked if a conflicting lock has been granted after the lease interval.
クライアントは、取消不能の形でロックを許可されているサーバーで定義された時間の間隔をリース。リースが拡張されていない場合は、リース期間の終了時にロックが取り消すことができます。競合ロックがリース期間の後に付与されている場合はロックが取り消されなければなりません。
All leases granted by a server have the same fixed
interval. Note that the fixed interval was chosen to
alleviate the expense a server would have in maintaining
state about variable length leases across server failures.
Lock The term "lock" is used to refer to both record (byte-range) locks as well as file (share) locks unless specifically stated otherwise.
特に断りのない限り、用語「ロック」の両方のレコード（バイト範囲）ロックだけでなく、ファイル（共有）を参照するために使用されるロックはロックされます。
Server The "Server" is the entity responsible for coordinating client access to a set of file systems.
サーバー「サーバー」とは、ファイルシステムのセットへのクライアントアクセスの調整を担当するエンティティです。
Stable Storage NFS version 4 servers must be able to recover without data loss from multiple power failures (including cascading power failures, that is, several power failures in quick succession), operating system failures, and hardware failure of components other than the storage medium itself (for example, disk, nonvolatile RAM).
安定記憶NFSバージョン4台のサーバは、複数の電源障害からデータを損失することなく回復することができなければならない（カスケード停電を含む、すなわち、いくつかの立て続けに電源障害）、オペレーティング・システムの障害、及び記憶媒体自体以外の成分のハードウェア障害（例えば、ディスク、不揮発性RAM）。
Some examples of stable storage that are allowable for an
NFS server include:
1. Media commit of data, that is, the modified data has been successfully written to the disk media, for example, the disk platter.
1.メディアはつまり、データのコミット、変更されたデータが正常に、例えば、ディスクメディアにディスクプラッタを書かされています。
2. An immediate reply disk drive with battery-backed on-drive intermediate storage or uninterruptible power system (UPS).
2.バッテリバックアップオン駆動中間貯蔵または無停電電源装置（UPS）との即時応答ディスクドライブ。
3. Server commit of data with battery-backed intermediate storage and recovery software.
3.サーバーは、バッテリバックアップ中間貯蔵及び回復ソフトウェアとデータのコミット。
4. Cache commit with uninterruptible power system (UPS) and recovery software.
4.キャッシュは、無停電電源装置（UPS）と回復ソフトウェアをコミットします。
Stateid A 64-bit quantity returned by a server that uniquely defines the locking state granted by the server for a specific lock owner for a specific file.
一意に特定のファイルのための特定のロック所有者のためにサーバによって許可ロック状態を定義し、サーバによって返された64ビット量のstateid。
Stateids composed of all bits 0 or all bits 1 have special
meaning and are reserved values.
Verifier A 64-bit quantity generated by the client that the server can use to determine if the client has restarted and lost all previous lock state.
サーバは、クライアントが再起動し、すべての以前のロック状態を喪失したかどうかを判定するために使用できるクライアントによって生成された検証者Aの64ビット量。
The syntax and semantics to describe the data types of the NFS version 4 protocol are defined in the XDR [RFC1832] and RPC [RFC1831] documents. The next sections build upon the XDR data types to define types and structures specific to this protocol.
NFSバージョン4プロトコルのデータ・タイプを記述するための構文およびセマンティクスはXDR [RFC1832]及びRPC [RFC1831]ドキュメントで定義されています。次のセクションでは、このプロトコルに特定の種類や構造を定義するにはXDRのデータ型に基づいて構築します。
Data Type Definition
_____________________________________________________________________
int32_t typedef int int32_t;
uint32_t typedef unsigned int uint32_t;
unsigned int型のuint32_tのtypedefのuint32_t。
int64_t typedef hyper int64_t;
int64_tのハイパーint64_tのtypedefは、
uint64_t typedef unsigned hyper uint64_t; attrlist4 typedef opaque attrlist4<>; Used for file/directory attributes
符号なしのハイパーuint64_tをのtypedef uint64_tを。不透明attrlist4のtypedef attrlist4 <>。ファイル/ディレクトリの属性に使用
bitmap4 typedef uint32_t bitmap4<>; Used in attribute array encoding.
bitmap4のtypedefのuint32_t bitmap4 <>。属性配列のエンコードに使用されます。
changeid4 typedef uint64_t changeid4; Used in definition of change_info
changeid4のtypedef uint64_tをchangeid4。 change_infoの定義で使用
clientid4 typedef uint64_t clientid4; Shorthand reference to client identification
clientid4のtypedef uint64_tをclientid4。クライアント識別に速記参照
component4 typedef utf8string component4; Represents path name components
component4のtypedef UTF8STRING component4。パス名の構成要素を表します
count4 typedef uint32_t count4; Various count parameters (READ, WRITE, COMMIT)
count4のtypedefのuint32_t count4。様々なカウントパラメータ（COMMIT、WRITE、READ）
length4 typedef uint64_t length4; Describes LOCK lengths
LENGTH4のtypedef uint64_tをLENGTH4。 LOCKの長さを記述します
linktext4 typedef utf8string linktext4; Symbolic link contents
linktext4のtypedef UTF8STRING linktext4。シンボリックリンクの内容
mode4 typedef uint32_t mode4; Mode attribute data type
MODE4のtypedefのuint32_t MODE4。モード属性データ型
nfs_cookie4 typedef uint64_t nfs_cookie4; Opaque cookie value for READDIR
nfs_cookie4のtypedef uint64_tをnfs_cookie4。 READDIRのための不透明なクッキーの値
nfs_fh4 typedef opaque nfs_fh4<NFS4_FHSIZE>; Filehandle definition; NFS4_FHSIZE is defined as 128
nfs_fh4不透明nfs_fh4のtypedef <NFS4_FHSIZE>。ファイルハンドルの定義; NFS4_FHSIZEは、128のように定義されます
nfs_ftype4 enum nfs_ftype4; Various defined file types
nfs_ftype4列挙型nfs_ftype4。様々な定義されているファイルの種類
nfsstat4 enum nfsstat4; Return value for operations
nfsstat4列挙型nfsstat4。操作の戻り値
offset4 typedef uint64_t offset4; Various offset designations (READ, WRITE, LOCK, COMMIT)
OFFSET4のtypedef uint64_tをOFFSET4。種々の（READ、WRITE、LOCK、COMMIT）指定オフセット
pathname4 typedef component4 pathname4<>; Represents path name for LOOKUP, OPEN and others
pathname4のtypedef component4 pathname4 <>。 LOOKUP、OPEN、その他のパス名を表します
qop4 typedef uint32_t qop4; Quality of protection designation in SECINFO
qop4のtypedefのuint32_t qop4。 SECINFOで保護指定の品質
sec_oid4 typedef opaque sec_oid4<>; Security Object Identifier The sec_oid4 data type is not really opaque. Instead contains an ASN.1 OBJECT IDENTIFIER as used by GSS-API in the mech_type argument to GSS_Init_sec_context. See [RFC2078] for details.
不透明sec_oid4のtypedef sec_oid4 <>。セキュリティオブジェクト識別子はsec_oid4データ型は本当に不透明ではありません。もしGSS_Init_sec_contextへたmech_type引数にGSS-APIで使用されるようにする代わりにASN.1オブジェクト識別子が含まれています。詳細については、[RFC2078]を参照してください。
seqid4 typedef uint32_t seqid4; Sequence identifier used for file locking
seqid4のtypedefのuint32_t seqid4。ファイルのロックに使用するシーケンス識別子
stateid4 typedef uint64_t stateid4; State identifier used for file locking and delegation
stateid4のtypedef uint64_tをstateid4。ファイルのロックと委任のために使用されている状態の識別子
utf8string typedef opaque utf8string<>; UTF-8 encoding for strings
typedefの不透明UTF8STRINGをUTF8STRING <>。文字列のUTF-8エンコーディング
verifier4 typedef opaque verifier4[NFS4_VERIFIER_SIZE]; Verifier used for various operations (COMMIT, CREATE, OPEN, READDIR, SETCLIENTID, WRITE) NFS4_VERIFIER_SIZE is defined as 8
verifier4 [NFS4_VERIFIER_SIZE] verifier4のtypedef不透明。検証者が各種操作に使用される（COMMIT、CREATE、OPEN、READDIR、SETCLIENTID、WRITE）NFS4_VERIFIER_SIZE 8のように定義されます
nfstime4
struct nfstime4 {
int64_t seconds;
uint32_t nseconds;
}
The nfstime4 structure gives the number of seconds and nanoseconds since midnight or 0 hour January 1, 1970 Coordinated Universal Time (UTC). Values greater than zero for the seconds field denote dates after the 0 hour January 1, 1970. Values less than zero for the seconds field denote dates before the 0 hour January 1, 1970. In both cases, the nseconds field is to be added to the seconds field for the final time representation. For example, if the time to be represented is one-half second before 0 hour January 1, 1970, the seconds field would have a value of negative one (-1) and the nseconds fields would have a value of one-half second (500000000). Values greater than 999,999,999 for nseconds are considered invalid.
nfstime4構造は深夜または0時間1970年1月1日協定世界時（UTC）からの秒とナノ秒数を示します。秒フィールドにゼロ以上の値が0時間の1月1日以降の日付を表し、秒フィールドのためのゼロ未満1970の値は両方のケースで0時間1970年1月1日より前の日付を表し、nsecondsフィールドが追加されます最終時間表現のための秒フィールド。例えば、表現される時間は、半分が第二0時間1970年1月1日前に、秒フィールドが負の1（-1）の値を有するであろうとnsecondsフィールドが（第2の半分の値を有するであろうあれば5億）。 nseconds用999999999より大きい値は無効とみなされます。
This data type is used to pass time and date information. A server converts to and from its local representation of time when processing time values, preserving as much accuracy as possible. If the precision of timestamps stored for a file system object is less than defined, loss of precision can occur. An adjunct time maintenance protocol is recommended to reduce client and server time skew.
このデータ型は、日付と時刻の情報を渡すために使用されます。時間値を処理するとき、サーバはできるだけ正確さを維持し、時間のローカル表現へと変換します。ファイル・システム・オブジェクトのための記憶されたタイムスタンプの精度が規定未満であれば、精度の損失が発生する可能性があります。補助時間のメンテナンスプロトコルは、クライアントとサーバーの時間のずれを低減することを推奨します。
time_how4
time_how4
enum time_how4 {
SET_TO_SERVER_TIME4 = 0,
SET_TO_CLIENT_TIME4 = 1
};
settime4
settime4
union settime4 switch (time_how4 set_it) {
case SET_TO_CLIENT_TIME4:
nfstime4 time;
default:
void;
};
The above definitions are used as the attribute definitions to set time values. If set_it is SET_TO_SERVER_TIME4, then the server uses its local representation of time for the time value.
上記の定義は、時間の値を設定する属性の定義として使用されています。 set_itがSET_TO_SERVER_TIME4ある場合、サーバーは、時間値のための時間のローカルな表現を使用しています。
specdata4
specdata4
struct specdata4 {
uint32_t specdata1;
uint32_t specdata2;
};
This data type represents additional information for the device file types NF4CHR and NF4BLK.
このデータ型は、デバイスファイルの種類NF4CHRとNF4BLKの追加情報を表します。
fsid4
fsid4
struct fsid4 {
uint64_t major;
uint64_t minor;
};
This type is the file system identifier that is used as a mandatory attribute.
このタイプは、必須の属性として使用されているファイルシステム識別子です。
fs_location4
fs_location4
struct fs_location4 {
utf8string server<>;
pathname4 rootpath;
};
fs_locations4
fs_locations4
struct fs_locations4 {
pathname4 fs_root;
fs_location4 locations<>;
};
The fs_location4 and fs_locations4 data types are used for the fs_locations recommended attribute which is used for migration and replication support.
fs_location4とfs_locations4データ型は、移行およびレプリケーション・サポートのために使用されているfs_位置推奨属性のために使用されています。
fattr4
fattr4
struct fattr4 {
bitmap4 attrmask;
attrlist4 attr_vals;
};
The fattr4 structure is used to represent file and directory attributes.
fattr4構造は、ファイルやディレクトリの属性を表すために使用されます。
The bitmap is a counted array of 32 bit integers used to contain bit values. The position of the integer in the array that contains bit n can be computed from the expression (n / 32) and its bit within that integer is (n mod 32).
ビットマップは、ビット値を含むために使用される32ビット整数のカウント配列です。ビットnを含む配列の整数の位置は、式（N / 32）から計算することができ、その整数の中のビットは（N MOD 32）。
0 1
+-----------+-----------+-----------+--
| count | 31 .. 0 | 63 .. 32 |
+-----------+-----------+-----------+--
change_info4
変化_info4
struct change_info4 {
bool atomic;
changeid4 before;
changeid4 after;
};
This structure is used with the CREATE, LINK, REMOVE, RENAME operations to let the client the know value of the change attribute for the directory in which the target file system object resides.
この構造は、REMOVEクライアントにターゲット・ファイル・システム・オブジェクトが存在するディレクトリの変更属性の既知の値を許可する操作の名前を変更し、CREATE LINKで使用されています。
clientaddr4
clientaddr4
struct clientaddr4 {
/* see struct rpcb in RFC 1833 */
string r_netid<>; /* network id */
string r_addr<>; /* universal address */
};
The clientaddr4 structure is used as part of the SETCLIENT operation to either specify the address of the client that is using a clientid or as part of the call back registration.
clientaddr4構造はのClientIDまたはコールバック登録の一部としてを使用しているクライアントのアドレスを指定するには、いずれかSETCLIENT操作の一部として使用されています。
cb_client4
cb_client4
struct cb_client4 {
unsigned int cb_program;
clientaddr4 cb_location;
};
This structure is used by the client to inform the server of its call back address; includes the program number and client address.
この構造は、そのコールバックアドレスのサーバーに通知するために、クライアントにより使用されます。プログラム番号とクライアントのアドレスが含まれています。
nfs_client_id4
nfs_client_id4
struct nfs_client_id4 {
verifier4 verifier;
opaque id<>;
};
This structure is part of the arguments to the SETCLIENTID operation.
この構造はSETCLIENTID操作の引数の一部です。
nfs_lockowner4
nfs_lockowner4
struct nfs_lockowner4 {
clientid4 clientid;
opaque owner<>;
};
This structure is used to identify the owner of a OPEN share or file lock.
この構造は、OPEN共有またはファイルロックの所有者を識別するために使用されます。
The NFS version 4 protocol is a Remote Procedure Call (RPC) application that uses RPC version 2 and the corresponding eXternal Data Representation (XDR) as defined in [RFC1831] and [RFC1832]. The RPCSEC_GSS security flavor as defined in [RFC2203] MUST be used as the mechanism to deliver stronger security for the NFS version 4 protocol.
[RFC1831]及び[RFC1832]で定義されるようにNFSバージョン4プロトコルはリモート・プロシージャ・コールRPCバージョン2を使用して（RPC）アプリケーションと対応する外部データ表現（XDR）です。 [RFC2203]で定義されるようにRPCSEC_GSSセキュリティ風味は、NFSバージョン4プロトコルのための強力なセキュリティを提供するためのメカニズムとして使用されなければなりません。
Historically, NFS version 2 and version 3 servers have resided on port 2049. The registered port 2049 [RFC1700] for the NFS protocol should be the default configuration. Using the registered port for NFS services means the NFS client will not need to use the RPC binding protocols as described in [RFC1833]; this will allow NFS to transit firewalls.
歴史的に、NFSバージョン2とバージョン3のサーバーは、NFSプロトコルの登録ポート2049 [RFC1700]はデフォルトの設定である必要があり、ポート2049上に置かれています。 NFSサービスのために登録されているポートを使用すると、NFSクライアントは[RFC1833]で説明したようにプロトコルをバインドRPCを使用する必要がないことを意味します。これはトランジットファイアウォールにNFSをできるようになります。
The transport used by the RPC service for the NFS version 4 protocol MUST provide congestion control comparable to that defined for TCP in [RFC2581]. If the operating environment implements TCP, the NFS version 4 protocol SHOULD be supported over TCP. The NFS client and server may use other transports if they support congestion control as defined above and in those cases a mechanism may be provided to override TCP usage in favor of another transport.
NFSバージョン4プロトコルのRPCサービスによって使用されるトランスポートは、[RFC2581]にTCP用に定義されたものに匹敵する輻輳制御を提供しなければなりません。動作環境は、TCPを実装している場合、NFSバージョン4プロトコルはTCP上でサポートされる必要があります。彼らは輻輳制御をサポートしている場合仕組み上、これらの例で定義されたNFSクライアントとサーバは、他のトランスポートを使用することができ、他の交通機関の賛成でTCPの使用を無効にするために設けられてもよいです。
If TCP is used as the transport, the client and server SHOULD use persistent connections. This will prevent the weakening of TCP's congestion control via short lived connections and will improve performance for the WAN environment by eliminating the need for SYN handshakes.
TCPはトランスポートとして使用されている場合は、クライアントとサーバは、持続的な接続を使用すべきです。これは短命接続を介してTCPの輻輳制御の弱体化を防ぐことができますし、SYNハンドシェイクの必要性を排除することにより、WAN環境のパフォーマンスが向上します。
Note that for various timers, the client and server should avoid inadvertent synchronization of those timers. For further discussion of the general issue refer to [Floyd].
各種タイマのために、クライアントとサーバは、これらのタイマの不注意な同期を避ける必要があることに注意してください。一般的な問題のさらなる議論について[フロイド]を参照してください。
Traditional RPC implementations have included AUTH_NONE, AUTH_SYS, AUTH_DH, and AUTH_KRB4 as security flavors. With [RFC2203] an additional security flavor of RPCSEC_GSS has been introduced which uses the functionality of GSS-API [RFC2078]. This allows for the use of varying security mechanisms by the RPC layer without the additional implementation overhead of adding RPC security flavors. For NFS version 4, the RPCSEC_GSS security flavor MUST be used to enable the mandatory security mechanism. Other flavors, such as, AUTH_NONE, AUTH_SYS, and AUTH_DH MAY be implemented as well.
従来のRPCの実装は、セキュリティのフレーバーとしてAUTH_NONE、AUTH_SYS、AUTH_DH、およびAUTH_KRB4が含まれています。 [RFC2203]でRPCSEC_GSSの追加のセキュリティ風味はGSS-API [RFC2078]の機能を使用していますが導入されました。これは、RPCセキュリティ風味を加える追加の実施オーバーヘッドなしRPC層によって変化するセキュリティメカニズムの使用を可能にします。 NFSバージョン4は、RPCSEC_GSSセキュリティ風味が必須のセキュリティ・メカニズムを有効にするために使用されなければなりません。このようAUTH_NONE、AUTH_SYS、AUTH_DHと、などの他のフレーバーは、同様に実施することができます。
The use of RPCSEC_GSS requires selection of: mechanism, quality of protection, and service (authentication, integrity, privacy). The remainder of this document will refer to these three parameters of the RPCSEC_GSS security as the security triple.
メカニズム、保護の品質、及びサービス（認証、完全性、プライバシー）：RPCSEC_GSSを使用すると、選択が必要です。このドキュメントの残りの部分はトリプルセキュリティなどRPCSEC_GSSセキュリティのこれらの三つのパラメータを参照します。
The Kerberos V5 GSS-API mechanism as described in [RFC1964] MUST be implemented and provide the following security triples.
[RFC1964]に記載されているようにケルベロスV5 GSS-API機構が実装され、以下のセキュリティトリプルを提供しなければなりません。
column descriptions:
列の説明：
1 == number of pseudo flavor 2 == name of pseudo flavor 3 == mechanism's OID 4 == mechanism's algorithm(s) 5 == RPCSEC_GSS service
疑似風味3 ==機構のOID 4 ==機構のアルゴリズム（複数可）5 == RPCSEC_GSSサービスの疑似風味2 ==名前の1つの==数
1 2 3 4 5
-----------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_privacy
for integrity,
and 56 bit DES
for privacy.
Note that the pseudo flavor is presented here as a mapping aid to the implementor. Because this NFS protocol includes a method to negotiate security and it understands the GSS-API mechanism, the pseudo flavor is not needed. The pseudo flavor is needed for NFS version 3 since the security negotiation is done via the MOUNT protocol.
疑似風味が実装へのマッピングの補助として、ここで提示されることに注意してください。このNFSプロトコルはセキュリティを交渉する方法を含み、それはGSS-APIメカニズムを理解しているので、疑似風味は必要ありません。セキュリティネゴシエーションがMOUNTプロトコルを介して行われるので、疑似風味は、NFSバージョン3のために必要とされています。
For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please see [RFC2623].
RPCSEC_GSSとKerberos V5のNFS」使用の議論に関しては、[RFC2623]を参照してください。
The LIPKEY GSS-API mechanism as described in [RFC2847] MUST be implemented and provide the following security triples. The definition of the columns matches the previous subsection "Kerberos V5 as security triple"
[RFC2847]に記載されているようにLIPKEY GSS-API機構が実装され、以下のセキュリティトリプルを提供しなければなりません。列の定義は、「セキュリティのトリプルとしてKerberos V5」前節と一致します
1 2 3 4 5
-----------------------------------------------------------------------
390006 lipkey 1.3.6.1.5.5.9 negotiated rpc_gss_svc_none
390007 lipkey-i 1.3.6.1.5.5.9 negotiated rpc_gss_svc_integrity
390008 lipkey-p 1.3.6.1.5.5.9 negotiated rpc_gss_svc_privacy
The mechanism algorithm is listed as "negotiated". This is because LIPKEY is layered on SPKM-3 and in SPKM-3 [RFC2847] the confidentiality and integrity algorithms are negotiated. Since SPKM-3 specifies HMAC-MD5 for integrity as MANDATORY, 128 bit cast5CBC for confidentiality for privacy as MANDATORY, and further specifies that HMAC-MD5 and cast5CBC MUST be listed first before weaker algorithms, specifying "negotiated" in column 4 does not impair interoperability. In the event an SPKM-3 peer does not support the mandatory algorithms, the other peer is free to accept or reject the GSS-API context creation.
機構アルゴリズムは「交渉さ」と表示されています。 LIPKEYがSPKM-3に積層され、SPKM-3 [RFC2847]に機密性と完全性アルゴリズムがネゴシエートされるためです。 SPKM-3は、必須として、プライバシーのために機密性のために必須、128ビットcast5CBCとして整合性のためにHMAC-MD5を指定し、HMAC-MD5とcast5CBCが弱くアルゴリズムの前に最初にリストされなければならないことをさらに指定し、第4欄の「ネゴシエート」を指定すると損なわないため相互運用性。イベントではSPKM-3ピアが必須のアルゴリズムをサポートしていない、他のピアは、GSS-APIのコンテキストの作成を受け入れるか拒否して自由です。
Because SPKM-3 negotiates the algorithms, subsequent calls to LIPKEY's GSS_Wrap() and GSS_GetMIC() by RPCSEC_GSS will use a quality of protection value of 0 (zero). See section 5.2 of [RFC2025] for an explanation.
SPKM-3アルゴリズム、0（ゼロ）の保護値の品質を使用するRPCSEC_GSSによってLIPKEY者にGSS_Wrap（）とGSS_GetMIC（）への後続の呼び出しをネゴシエートするからです。説明については、[RFC2025]のセクション5.2を参照してください。
LIPKEY uses SPKM-3 to create a secure channel in which to pass a user name and password from the client to the user. Once the user name and password have been accepted by the server, calls to the LIPKEY context are redirected to the SPKM-3 context. See [RFC2847] for more details.
LIPKEYは、ユーザーにクライアントからユーザー名とパスワードを渡すためにした安全なチャネルを作成するために、SPKM-3を使用しています。ユーザー名とパスワードがサーバーによって承認された後、SPKM-3のコンテキストにリダイレクトされLIPKEYコンテキストに呼び出します。詳細については、[RFC2847]を参照してください。
The SPKM-3 GSS-API mechanism as described in [RFC2847] MUST be implemented and provide the following security triples. The definition of the columns matches the previous subsection "Kerberos V5 as security triple".
[RFC2847]に記載されているようにSPKM-3 GSS-API機構が実装され、以下のセキュリティトリプルを提供しなければなりません。列の定義は、「セキュリティのトリプルとしてKerberos V5」前節と一致します。
1 2 3 4 5
-----------------------------------------------------------------------
390009 spkm3 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_none
390010 spkm3i 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_integrity
390011 spkm3p 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_privacy
For a discussion as to why the mechanism algorithm is listed as "negotiated", see the previous section "LIPKEY as a security triple."
機構アルゴリズムは「交渉さ」と表示されている理由として議論については、「トリプルセキュリティとしてLIPKEY。」前のセクションを参照してください
Because SPKM-3 negotiates the algorithms, subsequent calls to SPKM-3's GSS_Wrap() and GSS_GetMIC() by RPCSEC_GSS will use a quality of protection value of 0 (zero). See section 5.2 of [RFC2025] for an explanation.
SPKM-3は、アルゴリズムをネゴシエートするので、後続の呼び出しは、0（ゼロ）の保護値の品質を使用するRPCSEC_GSSによって者にGSS_Wrap（）とGSS_GetMIC（）-3をSPKMします。説明については、[RFC2025]のセクション5.2を参照してください。
Even though LIPKEY is layered over SPKM-3, SPKM-3 is specified as a mandatory set of triples to handle the situations where the initiator (the client) is anonymous or where the initiator has its own certificate. If the initiator is anonymous, there will not be a user name and password to send to the target (the server). If the initiator has its own certificate, then using passwords is superfluous.
LIPKEYがSPKM-3上に積層されていても、SPKM-3は、イニシエータ（クライアント）が匿名であるか、またはイニシエータは、自身の証明書を有する場合の状況を処理するためにトリプルの必須のセットとして指定されています。イニシエータが匿名である場合は、ユーザー名とパスワードがターゲット（サーバー）に送信することができません。イニシエータは、独自の証明書を持っている場合は、パスワードを使用することは不必要です。
With the NFS version 4 server potentially offering multiple security mechanisms, the client needs a method to determine or negotiate which mechanism is to be used for its communication with the server. The NFS server may have multiple points within its file system name space that are available for use by NFS clients. In turn the NFS server may be configured such that each of these entry points may have different or multiple security mechanisms in use.
NFSバージョン4サーバは、潜在的に複数のセキュリティメカニズムを提供して、クライアントは、サーバとの通信に使用すべきメカニズム決定または交渉する方法を必要とします。 NFSサーバは、NFSクライアントで使用するために用意されていて、ファイルシステムの名前空間内で複数のポイントを有することができます。次に、NFSサーバは、これらのエントリ・ポイントの各々が使用中で異なる又は複数のセキュリティメカニズムを有することができるように構成されてもよいです。
The security negotiation between client and server must be done with a secure channel to eliminate the possibility of a third party intercepting the negotiation sequence and forcing the client and server to choose a lower level of security than required or desired.
クライアントとサーバ間のセキュリティネゴシエーションは、交渉のシーケンスを傍受し、必要または所望されるよりもセキュリティの低いレベルを選択し、クライアントとサーバーを強制的に第三者の可能性を排除するために安全なチャネルで行う必要があります。
Based on the assumption that each NFS version 4 client and server must support a minimum set of security (i.e. LIPKEY, SPKM-3, and Kerberos-V5 all under RPCSEC_GSS), the NFS client will start its communication with the server with one of the minimal security triples. During communication with the server, the client may receive an NFS error of NFS4ERR_WRONGSEC. This error allows the server to notify the client that the security triple currently being used is not appropriate for access to the server's file system resources. The client is then responsible for determining what security triples are available at the server and choose one which is appropriate for the client.
各NFSバージョン4クライアントとサーバが、セキュリティの最小セット（すなわちLIPKEY、SPKM-3、およびすべてのRPCSEC_GSSの下でのKerberos-V5）をサポートしなければならないという仮定に基づいて、NFSクライアントは、のいずれかでサーバーとの通信を開始します最低限のセキュリティトリプル。サーバーとの通信中に、クライアントはNFS4ERR_WRONGSECのNFSエラーが発生することがあります。このエラーは、サーバーがトリプル現在使用しているセキュリティが、サーバーのファイル・システム・リソースへのアクセスのために適切ではないことをクライアントに通知することができます。クライアントは、セキュリティトリプルはサーバーで利用可能であり、クライアントに適切なものを選ぶかを決定する責任があります。
The new SECINFO operation will allow the client to determine, on a per filehandle basis, what security triple is to be used for server access. In general, the client will not have to use the SECINFO procedure except during initial communication with the server or when the client crosses policy boundaries at the server. It is possible that the server's policies change during the client's interaction therefore forcing the client to negotiate a new security triple.
新しいSECINFO操作はトリプルサーバーへのアクセスに使用するどのようなセキュリティ、ファイルハンドルごとに、クライアントが決定することができます。一般的には、クライアントは、クライアントがサーバにポリシーの境界を横断するサーバーまたはとの最初の通信中以外SECINFOプロシージャを使用する必要はありません。サーバーのポリシーがゆえトリプル新しいセキュリティを交渉するクライアントを強制的に、クライアントの相互作用の中に変化している可能性があります。
The callback RPC (described later) must mutually authenticate the NFS server to the principal that acquired the clientid (also described later), using the same security flavor the original SETCLIENTID operation used. Because LIPKEY is layered over SPKM-3, it is permissible for the server to use SPKM-3 and not LIPKEY for the callback even if the client used LIPKEY for SETCLIENTID.
コールバックRPC（後述）は、互いに同じセキュリティ風味を使用した元のSETCLIENTID操作を使用して、（これも後述）のClientIDを取得主にNFSサーバを認証する必要があります。 LIPKEYがSPKM-3の上に積層されているので、サーバは、クライアントがSETCLIENTIDためLIPKEYを使用しても、コールバックのSPKM-3及びませんLIPKEYを使用することが許されます。
For AUTH_NONE, there are no principals, so this is a non-issue.
AUTH_NONEのために、そこにはプリンシパルではないので、これは非問題です。
For AUTH_SYS, the server simply uses the AUTH_SYS credential that the user used when it set up the delegation.
AUTH_SYSの場合、サーバーは、単にそれが委任を設定するとき、ユーザーが使用AUTH_SYS資格情報を使用しています。
For AUTH_DH, one commonly used convention is that the server uses the credential corresponding to this AUTH_DH principal:
AUTH_DHについて、1つの一般的に使用される規則は、サーバがこのAUTH_DHプリンシパルに対応する資格情報を使用していることです。
unix.host@domain
うにｘ。ほｓｔ＠どまいん
where host and domain are variables corresponding to the name of server host and directory services domain in which it lives such as a Network Information System domain or a DNS domain.
どこのホストとドメインには、それは、そのようなネットワーク情報システムのドメインまたはDNSドメインとして住んでいるサーバーのホストとディレクトリサービスのドメイン名に対応する変数です。
Regardless of what security mechanism under RPCSEC_GSS is being used, the NFS server, MUST identify itself in GSS-API via a GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE names are of the form:
かかわらずRPCSEC_GSSの下のセキュリティメカニズムが使用されているものの、NFSサーバは、GSS_C_NT_HOSTBASED_SERVICE名のタイプを経由してGSS-API自体を特定しなければなりません。 GSS_C_NT_HOSTBASED_SERVICE名の形式は次のとおりです。
service@hostname
サービス@ホスト名
For NFS, the "service" element is
NFSの場合は、「サービス」の要素があります
nfs
同じ
Implementations of security mechanisms will convert nfs@hostname to various different forms. For Kerberos V5 and LIPKEY, the following form is RECOMMENDED:
セキュリティ・メカニズムの実装は、種々の異なる形態にホスト名@ NFSを変換します。ケルベロスV5とLIPKEYに関しては、以下のフォームをお勧めします。
nfs/hostname
NFS /ホスト名
For Kerberos V5, nfs/hostname would be a server principal in the Kerberos Key Distribution Center database. For LIPKEY, this would be the username passed to the target (the NFS version 4 client that receives the callback).
ケルベロスV5の場合は、NFS /ホスト名は、Kerberosキー配布センター・データベースのサーバープリンシパルになります。 LIPKEYに関しては、これはターゲット（コールバックを受けるNFSバージョン4クライアント）に渡されたユーザー名になります。
It should be noted that LIPKEY may not work for callbacks, since the LIPKEY client uses a user id/password. If the NFS client receiving the callback can authenticate the NFS server's user name/password pair, and if the user that the NFS server is authenticating to has a public key certificate, then it works.
LIPKEYクライアントは、ユーザーID /パスワードを使用しているのでLIPKEYは、コールバックのために動作しないことに留意すべきです。コールバックを受けるNFSクライアントは、NFSサーバーのユーザー名/パスワードのペアを認証することができ、およびNFSサーバはに認証されたユーザーは、公開鍵証明書を持っている場合、それが動作するかどうか。
In situations where NFS client uses LIPKEY and uses a per-host principal for the SETCLIENTID operation, instead of using LIPKEY for SETCLIENTID, it is RECOMMENDED that SPKM-3 with mutual authentication be used. This effectively means that the client will use a certificate to authenticate and identify the initiator to the target on the NFS server. Using SPKM-3 and not LIPKEY has the following advantages:
NFSクライアントは、代わりにSETCLIENTIDためLIPKEYを使用する、LIPKEYを使用し、SETCLIENTID操作ごとのホストプリンシパルを使用する状況では、SPKM-3相互認証を使用することが推奨されます。これは事実上、クライアントがNFSサーバー上のターゲットにイニシエータを認証し、識別するために証明書を使用することを意味します。 SPKM-3及びませんLIPKEYを使用すると、次のような利点があります。
o When the server does a callback, it must authenticate to the principal used in the SETCLIENTID. Even if LIPKEY is used, because LIPKEY is layered over SPKM-3, the NFS client will need to have a certificate that corresponds to the principal used in the SETCLIENTID operation. From an administrative perspective, having a user name, password, and certificate for both the client and server is redundant.
サーバーがコールバックを行う場合には、O、それがSETCLIENTIDに使用される主に認証する必要があります。 LIPKEYを用いてもLIPKEYがSPKM-3上に積層されているため、NFSクライアントはSETCLIENTID操作に使用される主に対応する証明書を持っている必要があります。管理上の観点からは、クライアントとサーバの両方のユーザー名、パスワード、および証明書を持つことは冗長です。
o LIPKEY was intended to minimize additional infrastructure requirements beyond a certificate for the target, and the expectation is that existing password infrastructure can be leveraged for the initiator. In some environments, a per-host password does not exist yet. If certificates are used for any per-host principals, then additional password infrastructure is not needed.
OのLIPKEYは、ターゲットのための証明書以外の追加のインフラストラクチャ要件を最小限にするためのもの、と期待が既存のパスワードインフラストラクチャは、イニシエータのために活用することができるということであるました。一部の環境では、ホストごとのパスワードがまだ存在していません。証明書は任意のホストごとのプリンシパルのために使用されている場合は、追加のパスワードインフラストラクチャは必要ありません。
o In cases when a host is both an NFS client and server, it can share the same per-host certificate.
ホストは、NFSクライアントとサーバーの両方があるときOのケースでは、それは同じホストごとの証明書を共有することができます。
The filehandle in the NFS protocol is a per server unique identifier for a file system object. The contents of the filehandle are opaque to the client. Therefore, the server is responsible for translating the filehandle to an internal representation of the file system object. Since the filehandle is the client's reference to an object and the client may cache this reference, the server SHOULD not reuse a filehandle for another file system object. If the server needs to reuse a filehandle value, the time elapsed before reuse SHOULD be large enough such that it is unlikely the client has a cached copy of the reused filehandle value. Note that a client may cache a filehandle for a very long time. For example, a client may cache NFS data to local storage as a method to expand its effective cache size and as a means to survive client restarts. Therefore, the lifetime of a cached filehandle may be extended.
NFSプロトコルにおけるファイルハンドルは、ファイル・システム・オブジェクト用のサーバごとに一意の識別子です。ファイルハンドルの内容は、クライアントに不透明です。したがって、サーバは、ファイル・システム・オブジェクトの内部表現にファイルハンドルを変換する責任があります。ファイルハンドルは、オブジェクトに対するクライアントの参照であり、クライアントはこの参照をキャッシュする可能性があるため、サーバーは、別のファイルシステムオブジェクトのファイルハンドルを再利用してはなりません。サーバがファイルハンドル値を再利用する必要がある場合は、再使用する前に経過した時間は、クライアントが再利用ファイルハンドル値のキャッシュされたコピーを持っているそうであるように十分大きくなければなりません。クライアントは非常に長い時間のためのファイルハンドルをキャッシュすることがあります。例えば、クライアントは、その効果的なキャッシュサイズを拡大する方法として、クライアントの再起動を生き残るための手段としてのローカルストレージにNFSデータをキャッシュすることができます。したがって、キャッシュされたファイルハンドルの寿命を延ばすことができます。
The operations of the NFS protocol are defined in terms of one or more filehandles. Therefore, the client needs a filehandle to initiate communication with the server. With the NFS version 2 protocol [RFC1094] and the NFS version 3 protocol [RFC1813], there exists an ancillary protocol to obtain this first filehandle. The MOUNT protocol, RPC program number 100005, provides the mechanism of translating a string based file system path name to a filehandle which can then be used by the NFS protocols.
NFSプロトコルの動作は、一つ以上のファイルハンドルで定義されています。そのため、クライアントは、サーバとの通信を開始するためにファイルハンドルを必要とします。 NFSバージョン2プロトコル[RFC1094]とNFSバージョン3プロトコル[RFC1813]と、この第一のファイルハンドルを取得するために補助的なプロトコルが存在します。 MOUNTプロトコル、RPCプログラム番号100005は、次いで、NFSプロトコルによって使用することができるファイルハンドルに文字列ベースのファイルシステムパス名を変換する機構を提供します。
The MOUNT protocol has deficiencies in the area of security and use via firewalls. This is one reason that the use of the public filehandle was introduced in [RFC2054] and [RFC2055]. With the use of the public filehandle in combination with the LOOKUP procedure in the NFS version 2 and 3 protocols, it has been demonstrated that the MOUNT protocol is unnecessary for viable interaction between NFS client and server.
MOUNTプロトコルがファイアウォールを経由して、セキュリティと使用領域の欠陥を持っています。これは、1つの公共ファイルハンドルの使用は[RFC2054]で導入されたことを理由と[RFC2055]です。 NFSバージョン2と3のプロトコルにおけるLOOKUP手順との組み合わせで、公共ファイルハンドルを使用すると、MOUNTプロトコルはNFSクライアントとサーバの間で実行可能な相互作用のために不必要であることが証明されています。
Therefore, the NFS version 4 protocol will not use an ancillary protocol for translation from string based path names to a filehandle. Two special filehandles will be used as starting points for the NFS client.
したがって、NFSバージョン4プロトコルは、ファイルハンドルに文字列ベースのパス名からの翻訳のための補助的なプロトコルを使用しません。二つの特別なファイルハンドルはNFSクライアントのための出発点として使用されます。
The first of the special filehandles is the ROOT filehandle. The ROOT filehandle is the "conceptual" root of the file system name space at the NFS server. The client uses or starts with the ROOT filehandle by employing the PUTROOTFH operation. The PUTROOTFH operation instructs the server to set the "current" filehandle to the ROOT of the server's file tree. Once this PUTROOTFH operation is used, the client can then traverse the entirety of the server's file tree with the LOOKUP procedure. A complete discussion of the server name space is in the section "NFS Server Name Space".
特別なファイルハンドルの最初は、ROOTファイルハンドルです。 ROOTファイルハンドルは、NFSサーバーでのファイルシステムの名前空間の「概念」ルートです。クライアントが使用していますかPUTROOTFH操作を採用することにより、ROOTファイルハンドルから始まります。 PUTROOTFH操作は、サーバーのファイルツリーのルートに「現在の」ファイルハンドルを設定するために、サーバーに指示します。このPUTROOTFH操作が使用されると、クライアントは、LOOKUPの手順でサーバーのファイルツリーの全体を横切ることができます。サーバーの名前空間の完全な議論は、セクション「NFSサーバーの名前空間」です。
The second special filehandle is the PUBLIC filehandle. Unlike the ROOT filehandle, the PUBLIC filehandle may be bound or represent an arbitrary file system object at the server. The server is responsible for this binding. It may be that the PUBLIC filehandle and the ROOT filehandle refer to the same file system object. However, it is up to the administrative software at the server and the policies of the server administrator to define the binding of the PUBLIC filehandle and server file system object. The client may not make any assumptions about this binding.
第2の特殊ファイルハンドルは、PUBLICファイルハンドルです。 ROOTファイルハンドルとは異なり、PUBLICファイルハンドルを結合してもよいし、サーバに任意のファイル・システム・オブジェクトを表します。サーバーは、この結合の原因です。これは、PUBLICファイルハンドルとROOTファイルハンドルは同じファイル・システム・オブジェクトを参照している可能性があります。しかし、それはPUBLICファイルハンドルとサーバーのファイルシステムオブジェクトの結合を定義するために、サーバーの管理ソフトウェア、およびサーバ管理者の方針次第です。クライアントは、このバインディングについての仮定をしない場合があります。
In the NFS version 2 and 3 protocols, there was one type of filehandle with a single set of semantics. The NFS version 4 protocol introduces a new type of filehandle in an attempt to accommodate certain server environments. The first type of filehandle is 'persistent'. The semantics of a persistent filehandle are the same as the filehandles of the NFS version 2 and 3 protocols. The second or new type of filehandle is the "volatile" filehandle.
NFSバージョン2および3のプロトコルで、意味論の単一のセットを持つファイルハンドルの一つのタイプがありました。 NFSバージョン4プロトコルは、特定のサーバ環境に適応しようとしてファイルハンドルの新しいタイプを導入します。ファイルハンドルの第一のタイプは、「永続的」です。永続ファイルハンドルのセマンティクスは、NFSバージョン2および3つのプロトコルのファイルハンドルと同じです。ファイルハンドルの第二または新しいタイプの「揮発性」ファイルハンドルです。
The volatile filehandle type is being introduced to address server functionality or implementation issues which make correct implementation of a persistent filehandle infeasible. Some server environments do not provide a file system level invariant that can be used to construct a persistent filehandle. The underlying server file system may not provide the invariant or the server's file system programming interfaces may not provide access to the needed invariant. Volatile filehandles may ease the implementation of server functionality such as hierarchical storage management or file system reorganization or migration. However, the volatile filehandle increases the implementation burden for the client. However this increased burden is deemed acceptable based on the overall gains achieved by the protocol.
揮発性ファイルハンドルタイプは、実行不可能な永続的なファイルハンドルの正しい実装を行うサーバー機能や実装の問題に対処するために導入されています。一部のサーバー環境では、永続的なファイルハンドルを構築するために使用することができ、ファイル・システム・レベルの不変を提供していません。基盤となるサーバーのファイルシステムは、不変またはサーバのファイルシステム・プログラミング・インタフェースが必要な不変へのアクセスを提供することはできません提供することはできません。揮発性ファイルハンドルは、階層ストレージ管理やファイルシステムの再編成または移行などのサーバ機能の実装を容易にすることができます。ただし、揮発性ファイルハンドルは、クライアントの実装の負担が増加します。しかし、この負担増は、プロトコルによって達成全体の利益に基づいて許容できるとみなされます。
Since the client will need to handle persistent and volatile filehandle differently, a file attribute is defined which may be used by the client to determine the filehandle types being returned by the server.
クライアントは異なり、永続的かつ揮発性ファイルハンドルを処理する必要がありますので、ファイルの属性は、サーバーによって返されるファイルハンドルのタイプを決定するために、クライアントが使用することができるが定義されます。
The filehandle contains all the information the server needs to distinguish an individual file. To the client, the filehandle is opaque. The client stores filehandles for use in a later request and can compare two filehandles from the same server for equality by doing a byte-by-byte comparison. However, the client MUST NOT otherwise interpret the contents of filehandles. If two filehandles from the same server are equal, they MUST refer to the same file. If they are not equal, the client may use information provided by the server, in the form of file attributes, to determine whether they denote the same files or different files. The client would do this as necessary for client side caching. Servers SHOULD try to maintain a one-to-one correspondence between filehandles and files but this is not required. Clients MUST use filehandle comparisons only to improve performance, not for correct behavior. All clients need to be prepared for situations in which it cannot be determined whether two filehandles denote the same object and in such cases, avoid making invalid assumptions which might cause incorrect behavior.
ファイルハンドルは、サーバーは、個々のファイルを区別するために必要なすべての情報が含まれています。クライアントに、ファイルハンドルは不透明です。クライアント店後の要求で使用するためにファイルハンドルとバイト単位の比較を行うことによって平等に同じサーバーから二つのファイルハンドルを比較することができます。ただし、クライアントは、そうでない場合はファイルハンドルの内容を解釈してはいけません。同じサーバからの2つのファイルハンドルが等しい場合、それらは同じファイルを参照する必要があります。彼らが等しくない場合、クライアントは、彼らが同じファイルまたは別のファイルを示すかどうかを判断するために、ファイル属性の形式で、サーバーによって提供された情報を使用することができます。クライアントは、クライアント側のキャッシュのために、これは、必要に応じて行うだろう。サーバーは、ファイルハンドルとファイルとの間の1対1の対応を維持しようとする必要がありますが、これは必須ではありません。クライアントは、だけでなく、正しい動作のために、パフォーマンスを向上させるためにファイルハンドルの比較を使用しなければなりません。すべてのクライアントは、2つのファイルハンドルが同じオブジェクトを表すかどうかを判断し、そのような場合には、不正な動作を引き起こす可能性がある無効な仮定を避けることができない状況のために準備する必要があります。
Further discussion of filehandle and attribute comparison in the context of data caching is presented in the section "Data Caching and File Identity".
また、ファイルハンドルの議論とデータキャッシュの内容を比較した属性は、「データキャッシュとファイルのアイデンティティ」に提示されています。
As an example, in the case that two different path names when traversed at the server terminate at the same file system object, the server SHOULD return the same filehandle for each path. This can occur if a hard link is used to create two file names which refer to the same underlying file object and associated data. For example, if paths /a/b/c and /a/d/c refer to the same file, the server SHOULD return the same filehandle for both path names traversals.
一例として、サーバで横断つの異なるパス名が同じファイル・システム・オブジェクトで終端している場合に、サーバは、パス毎に同じファイルハンドルを返すべきです。ハードリンクは、同じ基本的なファイルオブジェクトと関連付けられたデータを参照する2人のファイル名を作成するために使用されている場合に発生する可能性があります。および/ A / D /同一のファイルを参照cはパス/ A / B / Cの場合、例えば、サーバは、両方のパス名のトラバーサルのために同じファイルハンドルを返すべきです。
A persistent filehandle is defined as having a fixed value for the lifetime of the file system object to which it refers. Once the server creates the filehandle for a file system object, the server MUST accept the same filehandle for the object for the lifetime of the object. If the server restarts or reboots the NFS server must honor the same filehandle value as it did in the server's previous instantiation. Similarly, if the file system is migrated, the new NFS server must honor the same file handle as the old NFS server.
永続ファイルハンドルは、それが参照するファイル・システム・オブジェクトの寿命のために固定値を有するものとして定義されます。サーバーは、ファイル・システム・オブジェクトのファイルハンドルを作成すると、サーバーは、オブジェクトの寿命のためのオブジェクトの同じファイルハンドルを受け入れなければなりません。サーバーが再起動または再起動すると、それは、サーバーの以前のインスタンスで行ったようにNFSサーバは、同じファイルハンドル値を尊重しなければなりません。ファイルシステムが移行された場合も同様に、新しいNFSサーバは、古いNFSサーバと同じファイルハンドルを尊重しなければなりません。
The persistent filehandle will be become stale or invalid when the file system object is removed. When the server is presented with a persistent filehandle that refers to a deleted object, it MUST return an error of NFS4ERR_STALE. A filehandle may become stale when the file system containing the object is no longer available. The file system may become unavailable if it exists on removable media and the media is no longer available at the server or the file system in whole has been destroyed or the file system has simply been removed from the server's name space (i.e. unmounted in a Unix environment).
ファイル・システム・オブジェクトが削除されたときに、永続ファイルハンドルは、古い、または無効になってされます。サーバーが削除されたオブジェクトを参照する永続的なファイルハンドルが提示されている場合、それはNFS4ERR_STALEのエラーを返さなければなりません。オブジェクトを含むファイルシステムが使用できなくなったとき、ファイルハンドルが古くなっていないことがあります。それは、リムーバブルメディア上に存在しないとメディアはサーバーで使用できなくなったか、Unixの内、すなわちアンマウント（全体でのファイルシステムが破壊されているか、ファイルシステムは、単にサーバーの名前空間から削除されている場合は、ファイルシステムが使用できなくなることがあり環境）。
A volatile filehandle does not share the same longevity characteristics of a persistent filehandle. The server may determine that a volatile filehandle is no longer valid at many different points in time. If the server can definitively determine that a volatile filehandle refers to an object that has been removed, the server should return NFS4ERR_STALE to the client (as is the case for persistent filehandles). In all other cases where the server determines that a volatile filehandle can no longer be used, it should return an error of NFS4ERR_FHEXPIRED.
揮発性ファイルハンドルは、持続的なファイルハンドルの同じ寿命特性を共有しません。サーバーは、揮発性ファイルハンドルが時間内に多くの異なる時点でもはや有効であることを決定しないことがあります。サーバは決定的揮発性ファイルハンドルが削除されたオブジェクトを参照することを決定することができる場合（永続ファイルハンドルの場合のように）、サーバは、クライアントにNFS4ERR_STALEを返すべきです。サーバーが揮発性ファイルハンドルが使用できなくなると判断した他のすべてのケースでは、それはNFS4ERR_FHEXPIREDのエラーを返す必要があります。
The mandatory attribute "fh_expire_type" is used by the client to determine what type of filehandle the server is providing for a particular file system. This attribute is a bitmask with the following values:
必須属性「fh_expire_typeは、」特定のファイルシステムのために提供しているファイルハンドルのサーバーの種類を決定するために、クライアントによって使用されます。この属性は、次の値を持つビットマスクです。
FH4_PERSISTENT The value of FH4_PERSISTENT is used to indicate a persistent filehandle, which is valid until the object is removed from the file system. The server will not return NFS4ERR_FHEXPIRED for this filehandle. FH4_PERSISTENT is defined as a value in which none of the bits specified below are set.
FH4_PERSISTENTはFH4_PERSISTENTの値は、オブジェクトがファイルシステムから削除されるまで有効で永続的なファイルハンドルを示すために使用されます。サーバーは、このファイルハンドルのためNFS4ERR_FHEXPIREDを返しません。 FH4_PERSISTENTは、以下の指定されたビットのどれも設定されていないれた値として定義されます。
FH4_NOEXPIRE_WITH_OPEN The filehandle will not expire while client has the file open. If this bit is set, then the values FH4_VOLATILE_ANY or FH4_VOL_RENAME do not impact expiration while the file is open. Once the file is closed or if the FH4_NOEXPIRE_WITH_OPEN bit is false, the rest of the volatile related bits apply.
FH4_NOEXPIRE_WITH_OPENクライアントがファイルを開いている間、ファイルハンドルが期限切れになりません。このビットがセットされている場合は、ファイルが開いている間、その値FH4_VOLATILE_ANYまたはFH4_VOL_RENAMEは、有効期限に影響を与えません。一度ファイルを閉じたりFH4_NOEXPIRE_WITH_OPENビットがfalseの場合、揮発性の関連ビットの残りの部分が適用されます。
FH4_VOLATILE_ANY The filehandle may expire at any time and will expire during system migration and rename.
ファイルハンドルは、任意の時点で有効期限が切れることがあり、システムの移行時に失効し、名前を変更しますFH4_VOLATILE_ANY。
FH4_VOL_MIGRATION The filehandle will expire during file system migration. May only be set if FH4_VOLATILE_ANY is not set.
FH4_VOL_MIGRATIONファイルハンドルは、ファイルシステム移行中に期限が切れます。 FH4_VOLATILE_ANYが設定されていない場合にのみ設定することができます。
FH4_VOL_RENAME The filehandle may expire due to a rename. This includes a rename by the requesting client or a rename by another client. May only be set if FH4_VOLATILE_ANY is not set.
FH4_VOL_RENAMEは、ファイルハンドルは、名前の変更が原因期限切れになることがあります。これは、要求元のクライアントによる名前変更または別のクライアントによる名前の変更が含まれています。 FH4_VOLATILE_ANYが設定されていない場合にのみ設定することができます。
Servers which provide volatile filehandles should deny a RENAME or REMOVE that would affect an OPEN file or any of the components leading to the OPEN file. In addition, the server should deny all RENAME or REMOVE requests during the grace or lease period upon server restart.
揮発性ファイルハンドルを提供するサーバは、OPENファイルまたはOPENファイルにつながるコンポーネントのいずれかに影響を与えるRENAMEまたは削除を拒否すべきです。また、サーバはすべてのRENAMEを否定するか、サーバーの再起動時に猶予またはリース期間中の要求を削除する必要があります。
The reader may be wondering why there are three FH4_VOL* bits and why FH4_VOLATILE_ANY is exclusive of FH4_VOL_MIGRATION and FH4_VOL_RENAME. If the a filehandle is normally persistent but cannot persist across a file set migration, then the presence of the FH4_VOL_MIGRATION or FH4_VOL_RENAME tells the client that it can treat the file handle as persistent for purposes of maintaining a file name to file handle cache, except for the specific event described by the bit. However, FH4_VOLATILE_ANY tells the client that it should not maintain such a cache for unopened files. A server MUST not present FH4_VOLATILE_ANY with FH4_VOL_MIGRATION or
FH4_VOLATILE_ANYはFH4_VOL_MIGRATIONとFH4_VOL_RENAMEの排他的である理由が3 FH4_VOL *ビットであり、なぜ読者は思ってもよいです。ファイルハンドルは通常永続的ですが、ファイルセット移行渡って持続することができない場合は、FH4_VOL_MIGRATIONの存在またはFH4_VOL_RENAMEは、ファイルを除いて、ハンドルキャッシュをファイルにファイル名を維持する目的のためとして永続扱う扱うことができることをクライアントに伝えますビットで記載された特定のイベント。しかし、FH4_VOLATILE_ANYは、未開封のファイルに対して、このようなキャッシュを維持するべきではないことをクライアントに伝えます。サーバーはFH4_VOL_MIGRATIONたりして本FH4_VOLATILE_ANYてはなりません
FH4_VOL_RENAME as this will lead to confusion. FH4_VOLATILE_ANY implies that the file handle will expire upon migration or rename, in addition to other events.
このようFH4_VOL_RENAMEは混乱につながります。 FH4_VOLATILE_ANYは、他のイベントに加えて、ファイルハンドルは、移行時に有効期限が切れたり名前を変更することを意味します。
As mentioned, in some instances a filehandle is stale (no longer valid; perhaps because the file was removed from the server) or it is expired (the underlying file is valid but since the filehandle is volatile, it may have expired). Thus the server needs to be able to return NFS4ERR_STALE in the former case and NFS4ERR_FHEXPIRED in the latter case. This can be done by careful construction of the volatile filehandle. One possible implementation follows.
前述のように、いくつかの例ではファイルハンドルが古い（もはや有効で、ファイルがサーバーから削除されたなどの理由で）ではありません（基本となるファイルが有効であるが、ファイルハンドルが揮発性であることから、それは有効期限が切れていてもよい）、または、それは有効期限が切れています。したがって、サーバは、後者の場合、前者の場合とNFS4ERR_FHEXPIREDにNFS4ERR_STALEを返すことができる必要があります。これは、揮発性ファイルハンドルを慎重に構築することによって行うことができます。一つの可能な実装は以下のとおりです。
A volatile filehandle, while opaque to the client could contain:
揮発性ファイルハンドル、クライアントへの不透明が含まれている可能性がありながら：
[volatile bit = 1 | server boot time | slot | generation number]
[揮発性ビット= 1 |サーバーの起動時間|スロット|世代番号]
o slot is an index in the server volatile filehandle table
Oスロットは、サーバ揮発性ファイルハンドルテーブルのインデックスであります
o generation number is the generation number for the table entry/slot
O世代番号は、テーブルエントリ/スロットの世代番号であります
If the server boot time is less than the current server boot time, return NFS4ERR_FHEXPIRED. If slot is out of range, return NFS4ERR_BADHANDLE. If the generation number does not match, return NFS4ERR_FHEXPIRED.
サーバーの起動時間は、現在のサーバーの起動時間よりも小さい場合、NFS4ERR_FHEXPIREDを返します。スロットが範囲外の場合は、NFS4ERR_BADHANDLEを返します。世代番号が一致しない場合は、NFS4ERR_FHEXPIREDを返します。
When the server reboots, the table is gone (it is volatile).
サーバーを再起動すると、テーブルには消えている（それは揮発性です）。
If volatile bit is 0, then it is a persistent filehandle with a different structure following it.
揮発性のビットが0であれば、それはそれ以下の異なる構造を持つ永続的なファイルハンドルです。
If possible, the client SHOULD recover from the receipt of an NFS4ERR_FHEXPIRED error. The client must take on additional responsibility so that it may prepare itself to recover from the expiration of a volatile filehandle. If the server returns persistent filehandles, the client does not need these additional steps.
可能な場合、クライアントはNFS4ERR_FHEXPIREDエラーの受領から回復する必要があります。それは揮発性ファイルハンドルの満了から回復するために自分自身を準備することができるように、クライアントは、追加の責任を取る必要があります。サーバーは、永続的なファイルハンドルを返した場合、クライアントは、これらの追加の手順は必要ありません。
For volatile filehandles, most commonly the client will need to store the component names leading up to and including the file system object in question. With these names, the client should be able to recover by finding a filehandle in the name space that is still available or by starting at the root of the server's file system name space.
揮発性ファイルハンドルのために、最も一般的なクライアントは、コンポーネント名に至るまで、問題のファイル・システム・オブジェクトを含むを保存する必要があります。これらの名前を使用すると、クライアントはまだ利用できたり、サーバーのファイルシステムの名前空間のルートから始まることである名前空間にファイルハンドルを見つけることによって回復することができるはずです。
If the expired filehandle refers to an object that has been removed from the file system, obviously the client will not be able to recover from the expired filehandle.
期限切れのファイルハンドルは、ファイルシステムから削除されたオブジェクトを参照する場合は、明らかにクライアントが期限切れのファイルハンドルから回復することはできません。
It is also possible that the expired filehandle refers to a file that has been renamed. If the file was renamed by another client, again it is possible that the original client will not be able to recover. However, in the case that the client itself is renaming the file and the file is open, it is possible that the client may be able to recover. The client can determine the new path name based on the processing of the rename request. The client can then regenerate the new filehandle based on the new path name. The client could also use the compound operation mechanism to construct a set of operations like:
期限切れのファイルハンドルの名前が変更されたファイルを参照することも可能です。ファイルが別のクライアントによって名前が変更された場合は、再度、元のクライアントが回復することができない可能性があります。しかし、クライアント自身がファイルの名前を変更され、ファイルが開いている場合には、クライアントが回復することができる可能性があります。クライアントは、名前変更要求の処理に基づいて、新しいパス名を決定することができます。クライアントは、新しいパス名に基づいて新しいファイルハンドルを再生成することができます。また、クライアントは、のような一連の操作を構築する複合操作機構を使用することができます。
RENAME A B
LOOKUP B
GETFH
To meet the requirements of extensibility and increased interoperability with non-Unix platforms, attributes must be handled in a flexible manner. The NFS Version 3 fattr3 structure contains a fixed list of attributes that not all clients and servers are able to support or care about. The fattr3 structure can not be extended as new needs arise and it provides no way to indicate non-support. With the NFS Version 4 protocol, the client will be able to ask what attributes the server supports and will be able to request only those attributes in which it is interested.
非Unixプラットフォームで拡張性と相互運用性が向上の要件を満たすために、属性は、柔軟な方法で処理しなければなりません。 NFSバージョン3 fattr3構造がない、すべてのクライアントとサーバーがサポートするかを気にすることができます属性の固定されたリストが含まれています。新たなニーズが発生し、それが非サポートを示す方法を提供していませんようfattr3構造を拡張することはできません。 NFSバージョン4プロトコルでは、クライアントは、サーバーがサポートする属性とそれが興味のある属性のみを要求することができるようになりますどのような尋ねることができるようになります。
To this end, attributes will be divided into three groups: mandatory, recommended, and named. Both mandatory and recommended attributes are supported in the NFS version 4 protocol by a specific and well-defined encoding and are identified by number. They are requested by setting a bit in the bit vector sent in the GETATTR request; the server response includes a bit vector to list what attributes were returned in the response. New mandatory or recommended attributes may be added to the NFS protocol between major revisions by publishing a standards-track RFC which allocates a new attribute number value and defines the encoding for the attribute. See the section "Minor Versioning" for further discussion.
、必須、推奨、およびという名前のこの目的を達成するために、属性は、3つのグループに分けされます。必須および推奨両方の属性を特定し、明確に定義されたエンコーディングによってNFSバージョン4プロトコルでサポートされており、番号で識別されます。それらはGETATTR要求で送信されたビット・ベクトル内のビットを設定することによって要求されています。サーバーの応答は、属性が応答で返されたものをリストするビットベクトルを含んでいます。新しい必須または推奨の属性は新しい属性数値を割り当て、属性のエンコーディングを定義する標準トラックRFCを公開することによって、主要なリビジョン間のNFSプロトコルに加えてもよいです。さらなる議論については、「マイナーバージョン」を参照してください。
Named attributes are accessed by the new OPENATTR operation, which accesses a hidden directory of attributes associated with a file system object. OPENATTR takes a filehandle for the object and returns the filehandle for the attribute hierarchy. The filehandle for the named attributes is a directory object accessible by LOOKUP or READDIR and contains files whose names represent the named attributes and whose data bytes are the value of the attribute. For example:
名前付き属性は、ファイル・システム・オブジェクトに関連付けられた属性の隠しディレクトリにアクセスし、新たなOPENATTR操作によってアクセスされています。 OPENATTRは、オブジェクトのファイルハンドルを取り、属性階層のためのファイルハンドルを返します。名前の属性のファイルハンドルは、LOOKUPまたはREADDIRからアクセス可能なディレクトリオブジェクトで、名前が命名された属性とデータバイト属性の値ですが表すファイルが含まれています。例えば：
LOOKUP "foo" ; look up file
GETATTR attrbits
OPENATTR ; access foo's named attributes
LOOKUP "x11icon" ; look up specific attribute
READ 0,4096 ; read stream of bytes
Named attributes are intended for data needed by applications rather than by an NFS client implementation. NFS implementors are strongly encouraged to define their new attributes as recommended attributes by bringing them to the IETF standards-track process.
名前付き属性は、アプリケーションではなく、NFSクライアントの実装が必要とするデータのために意図されています。 NFSの実装が強くIETF標準トラックプロセスにそれらをもたらすことによって推奨属性とその新しい属性を定義することをお勧めします。
The set of attributes which are classified as mandatory is deliberately small since servers must do whatever it takes to support them. The recommended attributes may be unsupported; though a server should support as many as it can. Attributes are deemed mandatory if the data is both needed by a large number of clients and is not otherwise reasonably computable by the client when support is not provided on the server.
サーバはそれがそれらをサポートするために取るものは何でもしなければならないので、必須として分類されている属性のセットは、意図的に小さいです。お勧めの属性がサポートされていないかもしれ。サーバはそれができる限り多くをサポートしなければならないのに。データは両方の多数のクライアントが必要とするとサポートがサーバー上で提供されていない場合、クライアントでそれ以外の場合は、合理的に計算可能でない場合、属性は必須と見なされます。
These MUST be supported by every NFS Version 4 client and server in order to ensure a minimum level of interoperability. The server must store and return these attributes and the client must be able to function with an attribute set limited to these attributes. With just the mandatory attributes some client functionality may be impaired or limited in some ways. A client may ask for any of these attributes to be returned by setting a bit in the GETATTR request and the server must return their value.
これらは、相互運用性の最小レベルを確保するために、すべてのNFSバージョン4のクライアントとサーバーがサポートしなければなりません。サーバに格納され、これらの属性を返し、クライアントがこれらの属性に制限された属性セットで機能することができなければならない必要があります。ただ、必須属性を持ついくつかのクライアント機能が損なわれる可能性があるか、いくつかの方法で制限されています。これらの属性のいずれかを求めることができるクライアントがGETATTR要求でビットを設定することによって返されると、サーバはその値を返す必要があります。
These attributes are understood well enough to warrant support in the NFS Version 4 protocol. However, they may not be supported on all clients and servers. A client may ask for any of these attributes to be returned by setting a bit in the GETATTR request but must handle the case where the server does not return them. A client may ask for the set of attributes the server supports and should not request attributes the server does not support. A server should be tolerant of requests for unsupported attributes and simply not return them rather than considering the request an error. It is expected that servers will support all attributes they comfortably can and only fail to support attributes which are difficult to support in their operating environments. A server should provide attributes whenever they don't have to "tell lies" to the client. For example, a file modification time should be either an accurate time or should not be supported by the server. This will not always be comfortable to clients but it seems that the client has a better ability to fabricate or construct an attribute or do without the attribute.
これらの属性は、NFSバージョン4プロトコルでサポートを保証するために十分に理解されています。しかし、彼らはすべてのクライアントとサーバーではサポートされない場合があります。クライアントは、GETATTR要求にビットをセットすることによって返されるこれらの属性のいずれかを求めることができるが、サーバーがそれらを返さない場合を処理する必要があります。クライアントは、サーバーがサポートする属性の集合を求めることができるとすべきではない要求はサポートしていないサーバを属性。サーバがサポートされていない属性に対する要求の耐性があると単純にかなり要求エラーを考慮よりもそれらを返すべきではありません。サーバは、彼らが快適にできるすべての属性をサポートするだけで自分の操作環境でサポートすることが困難な属性をサポートするために失敗することが期待されます。彼らは、クライアントに「嘘をつく」する必要はありませんいつでもサーバーは、属性を提供する必要があります。例えば、ファイルの修正時刻が正確な時間のいずれかでなければなりませんまたはサーバーでサポートされていないはずです。これは、常にクライアントに快適ではありませんが、クライアントは属性なしで製造または属性を構築または行うには良い能力を持っているようです。
These attributes are not supported by direct encoding in the NFS Version 4 protocol but are accessed by string names rather than numbers and correspond to an uninterpreted stream of bytes which are stored with the file system object. The name space for these attributes may be accessed by using the OPENATTR operation. The OPENATTR operation returns a filehandle for a virtual "attribute directory" and further perusal of the name space may be done using READDIR and LOOKUP operations on this filehandle. Named attributes may then be examined or changed by normal READ and WRITE and CREATE operations on the filehandles returned from READDIR and LOOKUP. Named attributes may have attributes.
これらの属性は、NFSバージョン4プロトコルで直接符号化することによってサポートされていないが、文字列の名前ではなく番号でアクセスされ、ファイル・システム・オブジェクトに格納されたバイトの未解釈のストリームに対応します。これらの属性の名前空間はOPENATTR操作を使用してアクセスすることができます。 OPENATTR操作は、仮想的な「属性ディレクトリ」と、このファイルハンドルに対してREADDIRとLOOKUP操作を用いて行うことができるネームスペースのさらなる閲覧のためのファイルハンドルを返します。命名された属性は、次いで、検査又は正常READによって変更およびファイルハンドルに書き込み、CREATE操作はREADDIRとLOOKUPから返されてもよいです。名前付き属性は、属性を有することができます。
It is recommended that servers support arbitrary named attributes. A client should not depend on the ability to store any named attributes in the server's file system. If a server does support named attributes, a client which is also able to handle them should be able to copy a file's data and meta-data with complete transparency from one location to another; this would imply that names allowed for regular directory entries are valid for named attribute names as well.
サーバは、任意の名前の属性をサポートすることをお勧めします。クライアントは、サーバのファイルシステム内の任意の名前の属性を格納する能力に依存すべきではありません。サーバがサポートという名前の属性がない場合、またそれらを扱うことができるクライアントは、ある場所から別の場所への完全な透明性を持つファイルのデータとメタデータをコピーすることができるはずです。これは、通常のディレクトリエントリには使用でき名称は、同様の名前の属性名のために有効であることを含意するでしょう。
Names of attributes will not be controlled by this document or other IETF standards track documents. See the section "IANA Considerations" for further discussion.
属性の名前は、この文書または他のIETFの標準トラック文書によって制御されることはありません。さらなる議論については、「IANAの考慮事項」を参照してください。
Name # DataType Access Description
___________________________________________________________________
supp_attr 0 bitmap READ The bit vector which
would retrieve all
mandatory and
recommended attributes
that are supported for
this object.
type 1 nfs4_ftype READ The type of the object (file, directory, symlink)
タイプ1 nfs4_ftypeオブジェクト（ファイル、ディレクトリ、シンボリックリンク）のタイプを読みます
fh_expire_type 2 uint32 READ Server uses this to specify filehandle expiration behavior to the client. See the section "Filehandles" for additional description.
fh_expire_type 2 UINT32 READサーバーは、クライアントにファイルハンドルの有効期限の動作を指定するために、これを使用しています。追加の説明については、「ファイルハンドル」を参照してください。
change 3 uint64 READ A value created by the server that the client can use to determine if file data, directory contents or attributes of the object have been modified. The server may return the object's time_modify attribute for this attribute's value but only if the file system object can not be updated more frequently than the resolution of time_modify.
変更3は、クライアントがファイルデータ、ディレクトリの内容またはオブジェクトの属性が変更されているかどうかを判断するために使用することができ、サーバによって作成された値を読み取るUINT64。サーバーは、この属性の値のオブジェクトのtime_modify属性を返すかもしれませんが、ファイルシステムオブジェクトはtime_modifyの解像度よりも頻繁に更新することができない場合にのみ。
size 4 uint64 R/W The size of the object in bytes.
サイズ4 UINT64のR /バイト単位でオブジェクトのサイズW。
link_support 5 boolean READ Does the object's file system supports hard links?
link_support 5ブールのREADは、オブジェクトのファイルシステムはハードリンクをサポートしていますか？
symlink_support 6 boolean READ Does the object's file system supports symbolic links?
symlink_support 6ブールREADは、オブジェクトのファイルシステムがシンボリックリンクをサポートしていますか？
named_attr 7 boolean READ Does this object have named attributes?
このオブジェクトは、属性をnamed_attr 7ブールのREAD名付けていますか？
fsid 8 fsid4 READ Unique file system identifier for the file system holding this object. fsid contains major and minor components each of which are uint64.
FSID 8 fsid4は、このオブジェクトを保持しているファイルシステムのためのユニークなファイルシステム識別子をお読みください。 FSIDはuint64型ですそれぞれのメジャーとマイナーのコンポーネントが含まれています。
unique_handles 9 boolean READ Are two distinct filehandles guaranteed to refer to two different file system objects?
unique_handles 9ブールのREADは、2つの異なるファイルハンドルは、二つの異なるファイル・システム・オブジェクトを参照することが保証されていますか？
lease_time 10 nfs_lease4 READ Duration of leases at server in seconds.
秒で、サーバーのリースのlease_time 10 nfs_lease4 READ期間。
rdattr_error 11 enum READ Error returned from getattr during readdir.
rdattr_error 11列挙型読み取りエラーがreaddirの中にGETATTRから返されました。
Name # Data Type Access Description
_____________________________________________________________________
ACL 12 nfsace4<> R/W The access control
list for the object.
aclsupport 13 uint32 READ Indicates what types of ACLs are supported on the current file system.
aclsupport 13 UINT32 READでは、ACLの種類は、現在のファイルシステム上でサポートされていることを示します。
archive 14 boolean R/W Whether or not this file has been archived since the time of last modification (deprecated in favor of time_backup).
アーカイブ14ブールR /このファイルは（time_backupの非推奨）最終更新時刻以降にアーカイブされているか否かは、W。
cansettime 15 boolean READ Is the server able to change the times for a file system object as specified in a SETATTR operation?
cansettime 15ブールREADは、サーバはSETATTR操作で指定されたファイル・システム・オブジェクトのための時間を変更することはできますか？
case_insensitive 16 boolean READ Are filename comparisons on this file system case insensitive?
CASE_INSENSITIVE 16ブールREADこのファイルシステムの場合のファイル名の比較では、小文字は区別されませんか？
case_preserving 17 boolean READ Is filename case on this file system preserved?
このファイルシステム上のファイル名の場合は、保存17ブールREADですcase_preserving？
chown_restricted 18 boolean READ If TRUE, the server will reject any request to change either the owner or the group associated with a file if the caller is not a privileged user (for example, "root" in Unix operating environments or in NT the "Take Ownership" privilege)
呼び出し側はUNIXオペレーティング環境で、または「テイクNTで、特権ユーザー（例えば、「ルート」でない場合TRUEの場合18ブールREADをchown_restricted、サーバーは、所有者またはファイルに関連付けられたグループのいずれかを変更するには、すべての要求を拒否します所有権」特権）
filehandle 19 nfs4_fh READ The filehandle of this object (primarily for readdir requests).
（主のreaddir要求のための）このオブジェクトのファイルハンドルをREAD nfs4_fh 19ファイルハンドル。
fileid 20 uint64 READ A number uniquely identifying the file within the file system.
20一意のファイルシステム内のファイルを識別する番号を読み取るUINT64 FILEID。
files_avail 21 uint64 READ File slots available to this user on the file system containing this object - this should be the smallest relevant limit.
21 files_availこのオブジェクトを含むファイルシステム上でこのユーザに利用可能UINT64 READファイルスロット - これは最小の関連限界であるべきです。
files_free 22 uint64 READ Free file slots on the file system containing this object - this should be the smallest relevant limit.
これは最小の関連限界であるべきである - このオブジェクトを含むファイルシステム上の空きファイルスロットを読みUINT64 files_free 22。
files_total 23 uint64 READ Total file slots on the file system containing this object.
files_total 23のuint64型は、このオブジェクトを含むファイルシステム上のファイルの総スロットをお読みください。
fs_locations 24 fs_locations READ Locations where this file system may be found. If the server returns NFS4ERR_MOVED as an error, this attribute must be supported.
fs_位置24のfs_位置は、このファイルシステムが見つけることができる場所をお読みください。サーバがエラーとしてNFS4ERR_MOVEDを返す場合、この属性はサポートされなければなりません。
hidden 25 boolean R/W Is file considered hidden with respect to the WIN32 API?
隠された25ブールのR / Wは、Win32 APIに関して隠しファイルと考えていますか？
homogeneous 26 boolean READ Whether or not this object's file system is homogeneous, i.e. are per file system attributes the same for all file system's objects.
均質26ブールREADかどうか、このオブジェクトのファイルシステムが均一である、すなわち、ファイルシステムごとにあるすべてのファイル・システムのオブジェクトに対して同じ属性。
maxfilesize 27 uint64 READ Maximum supported file size for the file system of this object.
MAXFILESIZE 27 uint64型READ最大は、このオブジェクトのファイルシステムのファイルサイズをサポートしていました。
maxlink 28 uint32 READ Maximum number of links for this object.
maxlink 28は、このオブジェクトのリンクの最大数をREAD UINT32。
maxname 29 uint32 READ Maximum filename size supported for this object.
29 UINT32は、このオブジェクトに対してサポートされる最大ファイル名のサイズをREAD MAXNAME。
maxread 30 uint64 READ Maximum read size supported for this object.
maxread 30 uint64型READ最大は、このオブジェクトに対してサポートされているサイズをお読みください。
maxwrite 31 uint64 READ Maximum write size supported for this object. This attribute SHOULD be supported if the file is writable. Lack of this attribute can lead to the client either wasting bandwidth or not receiving the best performance.
maxwrite 31のuint64型が、このオブジェクトに対してサポートされている最大書き込みサイズをお読みください。ファイルが書き込み可能である場合、この属性はサポートされる必要があります。この属性の欠如は、いずれかの帯域幅を浪費や最高のパフォーマンスを受けていないクライアントにつながることができます。
mimetype 32 utf8<> R/W MIME body type/subtype of this object.
MIMEタイプ32 UTF8 <オブジェクトの> R / W MIMEボディタイプ/サブタイプ。
mode 33 mode4 R/W Unix-style permission bits for this object (deprecated in favor of ACLs)
モード33（のACLのために廃止）このオブジェクトのMODE4 R / W Unixスタイルの許可ビット
no_trunc 34 boolean READ If a name longer than name_max is used, will an error be returned or will the name be truncated?
長いNAME_MAXよりも名を使用する場合は34ブールREAD no_trunc、エラーが返されますか名前は切り捨てられますか？
numlinks 35 uint32 READ Number of hard links to this object.
このオブジェクトへのハードリンクのnumlinks 35 UINT32 READ番号。
owner 36 utf8<> R/W The string name of the owner of this object.
所有者36 UTF8 <> R /このオブジェクトの所有者の文字列名W。
owner_group 37 utf8<> R/W The string name of the group ownership of this object.
owner_group 37 UTF8 <> R /このオブジェクトのグループ所有権の文字列名W。
quota_avail_hard 38 uint64 READ For definition see "Quota Attributes" section below.
quota_avail_hard 38は、以下の「クォータの属性」を参照してください。定義についてのセクションを読んUINT64。
quota_avail_soft 39 uint64 READ For definition see "Quota Attributes" section below.
参照定義についてquota_avail_soft 39 UINT64 READ以下の「クォータ属性」。
quota_used 40 uint64 READ For definition see "Quota Attributes" section below.
以下のセクションを「クォータの属性」を参照してください定義については40 UINT64 READをQUOTA_USED。
rawdev 41 specdata4 READ Raw device identifier. Unix device major/minor node information.
41 specdata4 READ生のデバイス識別子をrawdev。 Unixのデバイスのメジャー/マイナーノード情報。
space_avail 42 uint64 READ Disk space in bytes available to this user on the file system containing this object - this should be the smallest relevant limit.
42 space_availこのオブジェクトを含むファイルシステム上でこのユーザーに利用可能なバイト数でuint64型READディスクスペース - これは最も小さい関連限界であるべきです。
space_free 43 uint64 READ Free disk space in bytes on the file system containing this object - this should be the smallest relevant limit.
space_free 43このオブジェクトを含むファイルシステム上のバイト単位で空きディスク容量をREAD uint64型 - これは最も小さい関連限界であるべきです。
space_total 44 uint64 READ Total disk space in bytes on the file system containing this object.
space_total 44のuint64型は、このオブジェクトを含むファイルシステム上のバイト単位での総ディスク容量をお読みください。
space_used 45 uint64 READ Number of file system bytes allocated to this object.
このオブジェクトに割り当てられたファイルシステムのバイトの45 UINT64 READ数space_used。
system 46 boolean R/W Is this file a system file with respect to the WIN32 API?
システム46ブールのR / Wは、Win32 APIに関して、システムファイルこのファイルですか？
time_access 47 nfstime4 READ The time of last access to the object.
オブジェクトへの最後のアクセスの時間をREAD nfstime4 time_access 47。
time_access_set 48 settime4 WRITE Set the time of last access to the object. SETATTR use only.
time_access_set 48 settime4が書くには、オブジェクトへの最後のアクセスの時間を設定します。 SETATTRにのみ使用します。
time_backup 49 nfstime4 R/W The time of last backup of the object.
R /オブジェクトの最後のバックアップの時W nfstime4 49 time_backup。
time_create 50 nfstime4 R/W The time of creation of the object. This attribute does not have any relation to the traditional Unix file attribute "ctime" or "change time".
time_create 50 nfstime4 R /オブジェクトの作成の時間W。この属性は、伝統的なUnixファイル属性「CTIME」または「変更時間」とは関係ありません。
time_delta 51 nfstime4 READ Smallest useful server time granularity.
最小の便利なサーバーの時間精度をREAD nfstime4 TIME_DELTA 51。
time_metadata 52 nfstime4 R/W The time of last meta-data modification of the object.
time_metadata 52 nfstime4 R /オブジェクトの最後のメタデータ変更の時間W。
time_modify 53 nfstime4 READ The time of last modification to the object.
オブジェクトへの最後の変更の時間をREAD nfstime4 53 time_modify。
time_modify_set 54 settime4 WRITE Set the time of last modification to the object. SETATTR use only.
time_modify_set 54 settime4は、オブジェクトの最終更新時刻を設定書きます。 SETATTRにのみ使用します。
The recommended attributes "owner" and "owner_group" are represented in terms of a UTF-8 string. To avoid a representation that is tied to a particular underlying implementation at the client or server, the use of the UTF-8 string has been chosen. Note that section 6.1 of [RFC2624] provides additional rationale. It is expected that the client and server will have their own local representation of owner and owner_group that is used for local storage or presentation to the end user. Therefore, it is expected that when these attributes are transferred between the client and server that the local representation is translated to a syntax of the form "user@dns_domain". This will allow for a client and server that do not use the same local representation the ability to translate to a common syntax that can be interpreted by both.
推奨属性の「所有者」とは、「owner_group」UTF-8文字列で表現されています。クライアントまたはサーバーで特定の基本的な実装に結び付けられている表現を避けるために、UTF-8文字列の使用が選択されています。 [RFC2624]のセクション6.1に注意してください追加の理論的根拠を提供します。クライアントとサーバは、エンドユーザーにローカルストレージやプレゼンテーションのために使用されている所有者とowner_groupの独自のローカルな表現を持っていることが期待されます。したがって、それは期待されているこれらの属性は、ローカル表現がフォーム「のuser @ dns_domain」の構文に変換され、クライアントとサーバーの間で転送されたとき。これは、同じローカルな表現を両方によって解釈することができ、共通の構文に変換する機能を使用していないクライアントとサーバが可能になります。
The translation is not specified as part of the protocol. This allows various solutions to be employed. For example, a local translation table may be consulted that maps between a numeric id to the user@dns_domain syntax. A name service may also be used to accomplish the translation. The "dns_domain" portion of the owner string is meant to be a DNS domain name. For example, user@ietf.org.
翻訳は、プロトコルの一部として指定されていません。これは、様々なソリューションを採用することができるようになります。たとえば、ローカルの変換テーブルは、ユーザーの@ dns_domain構文の数値IDの間のマッピングし、その参考にすることができます。ネームサービスは、翻訳を達成するために使用することができます。所有者文字列の「dns_domain」の部分は、DNSドメイン名であることを意味しています。例えば、user@ietf.org。
In the case where there is no translation available to the client or server, the attribute value must be constructed without the "@". Therefore, the absence of the @ from the owner or owner_group attribute signifies that no translation was available and the receiver of the attribute should not place any special meaning with the attribute value. Even though the attribute value can not be translated, it may still be useful. In the case of a client, the attribute string may be used for local display of ownership.
クライアントまたはサーバに利用可能な翻訳が存在しない場合には、属性値は「@」なしで構築されなければなりません。したがって、所有者またはowner_group属性から@の不在には翻訳が利用できなかったと属性の受信機は、属性値を持つ特別な意味を置くべきではないことを意味します。属性値が変換できないにもかかわらず、それはまだ有用である可能性があります。クライアントの場合、属性文字列は、所有権のローカル・ディスプレイのために使用することができます。
With respect to the case_insensitive and case_preserving attributes, each UCS-4 character (which UTF-8 encodes) has a "long descriptive name" [RFC1345] which may or may not included the word "CAPITAL" or "SMALL". The presence of SMALL or CAPITAL allows an NFS server to implement unambiguous and efficient table driven mappings for case insensitive comparisons, and non-case-preserving storage. For general character handling and internationalization issues, see the section "Internationalization".
CASE_INSENSITIVEとcase_preserving属性に関して、各UCS-4文字（UTF-8符号化）「は、長い記述名」または単語「CAPITAL」または「SMALL」に含まれていてもいなくてもよい[RFC1345]を有します。 SMALL又は資本の存在は、NFSサーバが大文字と小文字を区別しない比較に明白かつ効率的なテーブルドリブンマッピングを実装することができ、ストレージ非ケース保存します。一般的な文字の取り扱いと国際化の問題については、「国際化」を参照してください。
For the attributes related to file system quotas, the following definitions apply:
ファイルシステムのクォータに関連する属性の場合は、以下の定義が適用されます。
quota_avail_soft The value in bytes which represents the amount of additional disk space that can be allocated to this file or directory before the user may reasonably be warned. It is understood that this space may be consumed by allocations to other files or directories though there is a rule as to which other files or directories.
ユーザーが合理的に警告される前に、このファイルまたはディレクトリに割り当てることができ、追加のディスク・スペースの量を表し、値をバイト単位でquota_avail_soft。他のどのファイルやディレクトリのようルールがあるが、このスペースは、他のファイルやディレクトリへの割り当てによって消費されてもよいことが理解されます。
quota_avail_hard The value in bytes which represent the amount of additional disk space beyond the current allocation that can be allocated to this file or directory before further allocations will be refused. It is understood that this space may be consumed by allocations to other files or directories.
さらに割り当てが拒否される前に、このファイルまたはディレクトリに割り当てることができる現在の割り当てを超えて追加のディスクスペースの量を表すバイトの値をquota_avail_hard。このスペースは、他のファイルまたはディレクトリへの割り当てによって消費されてもよいことが理解されます。
quota_used The value in bytes which represent the amount of disc space used by this file or directory and possibly a number of other similar files or directories, where the set of "similar" meets at least the criterion that allocating space to any file or directory in the set will reduce the "quota_avail_hard" of every other file or directory in the set.
「類似」のセットは、少なくとも基準を満たす可能性がこのファイルまたはディレクトリおよび他の類似のファイルまたはディレクトリの数によって使用されるディスク・スペースの量を表すバイトの値をQUOTA_USEDそのファイルまたはディレクトリ内にスペースを割り当てますセットは、セット内の他のすべてのファイルやディレクトリの「quota_avail_hard」を削減します。
Note that there may be a number of distinct but overlapping
sets of files or directories for which a quota_used value is
maintained. E.g. "all files with a given owner", "all files
with a given group owner". etc.
The server is at liberty to choose any of those sets but should do so in a repeatable way. The rule may be configured per-filesystem or may be "choose the set with the smallest quota".
サーバーは、これらのセットのいずれかを選択する自由であるが、再現可能な方法で行う必要があります。ルールごとのファイルシステムに構成してもよいし、「最小クォータとセットを選択」であってもよいです。
The NFS ACL attribute is an array of access control entries (ACE). There are various access control entry types. The server is able to communicate which ACE types are supported by returning the appropriate value within the aclsupport attribute. The types of ACEs are defined as follows:
NFS ACL属性は、アクセス制御エントリ（ACE）の配列です。様々なアクセス制御エントリの種類があります。サーバはaclsupport属性内の適切な値を返すことによってサポートされているACEタイプ通信することができます。次のようにACEの種類が定義されています。
Type Description
_____________________________________________________
ALLOW Explicitly grants the access defined in
acemask4 to the file or directory.
DENY Explicitly denies the access defined in acemask4 to the file or directory.
明示的にDENYは、ファイルまたはディレクトリへのacemask4で定義されたアクセスを拒否します。
AUDIT LOG (system dependent) any access attempt to a file or directory which uses any of the access methods specified in acemask4.
監査ログ（システムに依存）acemask4で指定したアクセス方法のいずれかを使用して、ファイルまたはディレクトリへのアクセスの試み。
ALARM Generate a system ALARM (system dependent) when any access attempt is made to a file or directory for the access methods specified in acemask4.
すべてのアクセスの試みがacemask4に指定されたアクセス方法のためのファイルまたはディレクトリに対して行われたときにアラームが（システムに依存）システムアラームを生成します。
The NFS ACE attribute is defined as follows:
次のようにNFS ACE属性が定義されています。
typedef uint32_t acetype4;
typedef uint32_t aceflag4;
typedef uint32_t acemask4;
struct nfsace4 {
acetype4 type;
aceflag4 flag;
acemask4 access_mask;
utf8string who;
};
To determine if an ACCESS or OPEN request succeeds each nfsace4 entry is processed in order by the server. Only ACEs which have a "who" that matches the requester are considered. Each ACE is processed until all of the bits of the requester's access have been ALLOWED. Once a bit (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer considered in the processing of later ACEs. If an ACCESS_DENIED_ACE is encountered where the requester's mode still has unALLOWED bits in common with the "access_mask" of the ACE, the request is denied.
ACCESSまたはOPEN要求が各nfsace4エントリが成功するかどうかを決定するためにサーバによって順に処理されます。依頼者と一致した「」持っている唯一のACEが考慮されます。依頼者のアクセスのビットのすべてが許可されるまで、各ACEが処理されます。ビットが（下記参照）ACCESS_ALLOWED_ACEによって許可された後、それはもはや後のACEの処理において考慮されません。 ACCESS_DENIED_ACEが発生した場合は、要求元のモードはまだACEの「access_mask」と共通の許可されていないビットを有する場合、要求は拒否されます。
The bitmask constants used to represent the above definitions within the aclsupport attribute are as follows:
次のようにaclsupport属性内の上記の定義を表すために使用されるビットマスク定数です。
const ACL4_SUPPORT_ALLOW_ACL = 0x00000001;
const ACL4_SUPPORT_DENY_ACL = 0x00000002;
const ACL4_SUPPORT_AUDIT_ACL = 0x00000004;
const ACL4_SUPPORT_ALARM_ACL = 0x00000008;
The semantics of the "type" field follow the descriptions provided above.
「タイプ」フィールドのセマンティクスは、上記の説明に従ってください。
The bitmask constants used for the type field are as follows:
次のようにタイプフィールドに使用されるビットマスク定数は、次のとおりです。
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000;
const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001;
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002;
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003;
The "flag" field contains values based on the following descriptions.
「フラグ」フィールドには、以下の説明に基づいて値を含んでいます。
ACE4_FILE_INHERIT_ACE
ACE4_FILE_INHERIT_ACE
Can be placed on a directory and indicates that this ACE should be added to each new non-directory file created.
ディレクトリに配置され、このACEが作成したそれぞれの新しい非ディレクトリファイルに追加する必要があることを示していることができます。
ACE4_DIRECTORY_INHERIT_ACE
ACE4_DIRECTORY_INHERIT_ACE
Can be placed on a directory and indicates that this ACE should be added to each new directory created.
ディレクトリに配置され、このACEが作成したそれぞれの新しいディレクトリに追加されなければならないことを示していることができます。
ACE4_INHERIT_ONLY_ACE
ACE4_INHERIT_ONLY_ACE
Can be placed on a directory but does not apply to the directory, only to newly created files/directories as specified by the above two flags.
ディレクトリに配置することができますが、上記の二つのフラグで指定されたのみで、新しく作成されたファイル/ディレクトリに、ディレクトリには適用されません。
ACE4_NO_PROPAGATE_INHERIT_ACE
ACE4_NO_PROPAGATE_INHERIT_ACE
Can be placed on a directory. Normally when a new directory is created and an ACE exists on the parent directory which is marked ACL4_DIRECTORY_INHERIT_ACE, two ACEs are placed on the new directory. One for the directory itself and one which is an inheritable ACE for newly created directories. This flag tells the server to not place an ACE on the newly created directory which is inheritable by subdirectories of the created directory.
ディレクトリに配置することができます。新しいディレクトリが作成され、ACEがACL4_DIRECTORY_INHERIT_ACEマークされている親ディレクトリに存在しているとき、通常、2つのACEを新しいディレクトリに配置されます。ディレクトリ自体の一つと新しく作成されたディレクトリの継承ACEである1。このフラグは、作成したディレクトリのサブディレクトリによって継承され、新しく作成したディレクトリにACEを置かないようにサーバに指示します。
ACE4_SUCCESSFUL_ACCESS_ACE_FLAG
ACE4_SUCCESSFUL_ACCESS_ACE_FLAG
ACL4_FAILED_ACCESS_ACE_FLAG
ACL4_FAILED_ACCESS_ACE_FLAG
Both indicate for AUDIT and ALARM which state to log the event. On every ACCESS or OPEN call which occurs on a file or directory which has an ACL that is of type ACE4_SYSTEM_AUDIT_ACE_TYPE or ACE4_SYSTEM_ALARM_ACE_TYPE, the attempted access is compared to the ace4mask of these ACLs. If the access is a subset of ace4mask and the identifier match, an AUDIT trail or an ALARM is generated. By default this happens regardless of the success or failure of the ACCESS or OPEN call.
どちらも、イベントをログに記録する状態AUDITとALARMのために示しています。ファイルまたはタイプACE4_SYSTEM_AUDIT_ACE_TYPEまたはACE4_SYSTEM_ALARM_ACE_TYPEのあるACLを持つディレクトリに発生したすべてのアクセスまたはOPENコールでは、アクセス試行がこれらのACLのace4maskと比較されます。アクセスace4maskのサブセット識別子が一致する場合には、監査証跡またはアラームが生成されます。デフォルトでは、これは関係なく、アクセスしたり、OPEN呼び出しの成功または失敗の起こります。
The flag ACE4_SUCCESSFUL_ACCESS_ACE_FLAG only produces the AUDIT or ALARM if the ACCESS or OPEN call is successful. The ACE4_FAILED_ACCESS_ACE_FLAG causes the ALARM or AUDIT if the ACCESS or OPEN call fails.
AccessまたはOPEN呼び出しが成功した場合にはフラグACE4_SUCCESSFUL_ACCESS_ACE_FLAGはAUDITかALARMを生成します。 AccessまたはOPEN呼び出しが失敗した場合ACE4_FAILED_ACCESS_ACE_FLAGはALARMまたはAUDITの原因となります。
ACE4_IDENTIFIER_GROUP
ACE4_IDENTIFIER_GROUP
Indicates that the "who" refers to a GROUP as defined under Unix.
Unixの下に定義される「誰が」基を意味することを示します。
The bitmask constants used for the flag field are as follows:
次のようにフラグフィールドに使用されるビットマスク定数です。
const ACE4_FILE_INHERIT_ACE = 0x00000001;
const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002;
const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004;
const ACE4_INHERIT_ONLY_ACE = 0x00000008;
const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010;
const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020;
const ACE4_IDENTIFIER_GROUP = 0x00000040;
The access_mask field contains values based on the following:
access_maskフィールドには、次のように基づく値が含まれています。
Access Description
_______________________________________________________________
READ_DATA Permission to read the data of the file
LIST_DIRECTORY Permission to list the contents of a
directory
WRITE_DATA Permission to modify the file's data
ADD_FILE Permission to add a new file to a
directory
APPEND_DATA Permission to append data to a file
ADD_SUBDIRECTORY Permission to create a subdirectory to a
directory
READ_NAMED_ATTRS Permission to read the named attributes
of a file
WRITE_NAMED_ATTRS Permission to write the named attributes
of a file
EXECUTE Permission to execute a file
DELETE_CHILD Permission to delete a file or directory
within a directory
READ_ATTRIBUTES The ability to read basic attributes
(non-acls) of a file
WRITE_ATTRIBUTES Permission to change basic attributes
(non-acls) of a file
DELETE Permission to Delete the file READ_ACL Permission to Read the ACL WRITE_ACL Permission to Write the ACL WRITE_OWNER Permission to change the owner SYNCHRONIZE Permission to access file locally at the server with synchronous reads and writes
同期とサーバーでローカルファイルにアクセスするには、所有者のSYNCHRONIZEアクセス権を変更するには、ACLのWRITE_OWNER許可を書くACL WRITE_ACL許可を読み取るために、ファイルREAD_ACL許可を削除する権限を削除すると、読み込みと書き込み
The bitmask constants used for the access mask field are as follows:
次のようにアクセスマスクフィールドに使用されるビットマスク定数は、次のとおりです。
const ACE4_READ_DATA = 0x00000001;
const ACE4_LIST_DIRECTORY = 0x00000001;
const ACE4_WRITE_DATA = 0x00000002;
const ACE4_ADD_FILE = 0x00000002;
const ACE4_APPEND_DATA = 0x00000004;
const ACE4_ADD_SUBDIRECTORY = 0x00000004;
const ACE4_READ_NAMED_ATTRS = 0x00000008;
const ACE4_WRITE_NAMED_ATTRS = 0x00000010;
const ACE4_EXECUTE = 0x00000020;
const ACE4_DELETE_CHILD = 0x00000040;
const ACE4_READ_ATTRIBUTES = 0x00000080;
const ACE4_WRITE_ATTRIBUTES = 0x00000100; const ACE4_DELETE = 0x00010000;
const ACE4_READ_ACL = 0x00020000;
const ACE4_WRITE_ACL = 0x00040000;
const ACE4_WRITE_OWNER = 0x00080000;
const ACE4_SYNCHRONIZE = 0x00100000;
There are several special identifiers ("who") which need to be understood universally. Some of these identifiers cannot be understood when an NFS client accesses the server, but have meaning when a local process accesses the file. The ability to display and modify these permissions is permitted over NFS.
普遍的に理解する必要があります（「」）、いくつかの特別な識別子があります。これらの識別子の一部は、NFSクライアントがサーバにアクセスするときに理解することはできませんが、ローカルプロセスがファイルにアクセスしたときに意味しています。これらの権限を表示および変更する機能は、NFS上で許可されています。
Who Description
_______________________________________________________________
"OWNER" The owner of the file.
"GROUP" The group associated with the file.
"EVERYONE" The world.
"INTERACTIVE" Accessed from an interactive terminal.
"NETWORK" Accessed via the network.
"DIALUP" Accessed as a dialup user to the server.
"BATCH" Accessed from a batch job.
"ANONYMOUS" Accessed without any authentication.
"AUTHENTICATED" Any authenticated user (opposite of
ANONYMOUS)
"SERVICE" Access from a system service.
To avoid conflict, these special identifiers are distinguish by an appended "@" and should appear in the form "xxxx@" (note: no domain name after the "@"). For example: ANONYMOUS@.
競合を避けるために、これらの特別な識別子は、「@」追加によって区別され、フォーム「XXXXの@」（注：ドメイン名「@」の後）に表示されます。例：ANONYMOUS @。
With the use of the recommended attribute "fs_locations", the NFS version 4 server has a method of providing file system migration or replication services. For the purposes of migration and replication, a file system will be defined as all files that share a given fsid (both major and minor values are the same).
推奨属性「fs_位置」を使用すると、NFSバージョン4サーバーは、ファイルシステムの移行やレプリケーションサービスを提供する方法があります。移行と複製の目的のために、ファイルシステムは与えられたfsidを共有するすべてのファイルが（メジャーとマイナーの両方の値が同じである）として定義されます。
The fs_locations attribute provides a list of file system locations. These locations are specified by providing the server name (either DNS domain or IP address) and the path name representing the root of the file system. Depending on the type of service being provided, the list will provide a new location or a set of alternate locations for the file system. The client will use this information to redirect its requests to the new server.
fs_位置の属性は、ファイルシステムの場所のリストを提供します。これらの場所は、サーバー名（DNSドメインやIPアドレスのいずれか）と、ファイルシステムのルートを表すパス名を提供することにより、指定されています。提供されるサービスのタイプに応じて、リストは、新しい場所またはファイルシステムの別の場所のセットを提供します。クライアントは、新しいサーバーにその要求をリダイレクトするために、この情報を使用します。
It is expected that file system replication will be used in the case of read-only data. Typically, the file system will be replicated on two or more servers. The fs_locations attribute will provide the list of these locations to the client. On first access of the file system, the client should obtain the value of the fs_locations attribute. If, in the future, the client finds the server unresponsive, the client may attempt to use another server specified by fs_locations.
ファイルシステムのレプリケーションは、読み取り専用データの場合に使用されることが期待されます。通常、ファイルシステムは、2台の以上のサーバーに複製されます。 fs_位置は、クライアントにこれらの場所のリストを提供します属性。ファイルシステムの最初のアクセスでは、クライアントはfs_位置の属性の値を取得する必要があります。 、将来的には、クライアントはサーバーが応答しない見つけた場合、クライアントはfs_位置で指定された別のサーバーを使用するように試みることができます。
If applicable, the client must take the appropriate steps to recover valid filehandles from the new server. This is described in more detail in the following sections.
該当する場合、クライアントは新しいサーバから有効なファイルハンドルを回復するために適切な措置を講じなければなりません。これは、次のセクションで詳細に記載されています。
File system migration is used to move a file system from one server to another. Migration is typically used for a file system that is writable and has a single copy. The expected use of migration is for load balancing or general resource reallocation. The protocol does not specify how the file system will be moved between servers. This server-to-server transfer mechanism is left to the server implementor. However, the method used to communicate the migration event between client and server is specified here.
ファイルシステムの移行は、別のサーバーからファイルシステムを移動するために使用されます。移行は、一般的に書き込み可能であり、単一のコピーを持っているファイル・システムに使用されます。移行の予想される使用は、負荷分散や、一般的なリソースの再配分のためです。プロトコルは、ファイルシステムがサーバ間で移動する方法を指定しません。このサーバー間の転送メカニズムは、サーバーの実装者に任されています。ただし、クライアントとサーバ間の移行イベントを通信するために使用される方法は、ここで指定されています。
Once the servers participating in the migration have completed the move of the file system, the error NFS4ERR_MOVED will be returned for subsequent requests received by the original server. The NFS4ERR_MOVED error is returned for all operations except GETATTR. Upon receiving the NFS4ERR_MOVED error, the client will obtain the value of the fs_locations attribute. The client will then use the contents of the attribute to redirect its requests to the specified server. To facilitate the use of GETATTR, operations such as PUTFH must also be accepted by the server for the migrated file system's filehandles. Note that if the server returns NFS4ERR_MOVED, the server MUST support the fs_locations attribute.
移行に参加するサーバーは、ファイルシステムの移動が完了したら、エラーNFS4ERR_MOVEDは、元のサーバーが受信した後続の要求のために返されます。 NFS4ERR_MOVEDエラーがGETATTR以外のすべての操作に対して返されます。 NFS4ERR_MOVEDエラーを受信すると、クライアントはfs_位置の属性の値を取得します。次に、クライアントは、指定されたサーバーへの要求をリダイレクトするために、属性の内容を使用します。 GETATTRの使用を容易にするために、このようPUTFHなどの操作も移行ファイルシステムのファイルハンドル用にサーバーによって受け入れられなければなりません。サーバがNFS4ERR_MOVEDを返した場合、サーバはfs_位置の属性をサポートしなければならないことに注意してください。
If the client requests more attributes than just fs_locations, the server may return fs_locations only. This is to be expected since the server has migrated the file system and may not have a method of obtaining additional attribute data.
クライアントはただfs_位置よりも多くの属性を要求した場合、サーバはfs_位置を返すことがあります。これは、サーバーがファイルシステムを移行しており、追加の属性データを取得する方法を持っていない可能性があるため予想されます。
The server implementor needs to be careful in developing a migration solution. The server must consider all of the state information clients may have outstanding at the server. This includes but is not limited to locking/share state, delegation state, and asynchronous file writes which are represented by WRITE and COMMIT verifiers. The server should strive to minimize the impact on its clients during and after the migration process.
サーバーの実装者は、移行ソリューションの開発に注意する必要があります。サーバは、サーバで優れていて、状態情報クライアントのすべてを考慮しなければなりません。これには含まれますが、ロック/共有状態、委任状態、およびWRITEによって表されると検証をCOMMITされている非同期のファイルへの書き込みに限定されるものではありません。サーバーは、移行プロセス中および後にそのクライアントへの影響を最小限に抑えるために努力すべきです。
The fs_location attribute is structured in the following way:
fs_location属性は次のように構成されています。
struct fs_location {
utf8string server<>;
pathname4 rootpath;
};
struct fs_locations {
pathname4 fs_root;
fs_location locations<>;
};
The fs_location struct is used to represent the location of a file system by providing a server name and the path to the root of the file system. For a multi-homed server or a set of servers that use the same rootpath, an array of server names may be provided. An entry in the server array is an UTF8 string and represents one of a traditional DNS host name, IPv4 address, or IPv6 address. It is not a requirement that all servers that share the same rootpath be listed in one fs_location struct. The array of server names is provided for convenience. Servers that share the same rootpath may also be listed in separate fs_location entries in the fs_locations attribute.
fs_location構造体は、サーバ名とファイル・システムのルートへのパスを提供することによって、ファイルシステムの位置を表すために使用されます。マルチホームサーバーまたは同じROOTPATHを使用するサーバのセットについて、サーバ名の配列を提供することができます。サーバーアレイ内のエントリは、UTF8の文字列であり、伝統的なDNSホスト名、IPv4アドレス、またはIPv6アドレスのいずれかを表しています。これは、同じROOTPATHを共有するすべてのサーバーが1つのfs_location構造体に記載されていることは必須ではありません。サーバー名の配列は、便宜のために提供されます。同じROOTPATHを共有するサーバもfs_位置の属性で別のfs_locationエントリに表示されることがあります。
The fs_locations struct and attribute then contains an array of locations. Since the name space of each server may be constructed differently, the "fs_root" field is provided. The path represented by fs_root represents the location of the file system in the server's name space. Therefore, the fs_root path is only associated with the server from which the fs_locations attribute was obtained. The fs_root path is meant to aid the client in locating the file system at the various servers listed.
fs_位置のstructと属性は、場所の配列が含まれています。各サーバーの名前空間が異なって構成することができるので、「fs_root」欄が設けられています。 fs_rootによって表されるパスは、サーバーの名前空間内のファイルシステムの場所を表します。したがって、fs_rootパスのみfs_位置の属性が取得されたサーバに関連付けられています。 fs_rootパスが記載されている各種サーバのファイルシステムを見つけるには、クライアントを支援するためのものです。
As an example, there is a replicated file system located at two servers (servA and servB). At servA the file system is located at path "/a/b/c". At servB the file system is located at path "/x/y/z". In this example the client accesses the file system first at servA with a multi-component lookup path of "/a/b/c/d". Since the client used a multi-component lookup to obtain the filehandle at "/a/b/c/d", it is unaware that the file system's root is located in servA's name space at "/a/b/c". When the client switches to servB, it will need to determine that the directory it first referenced at servA is now represented by the path "/x/y/z/d" on servB. To facilitate this, the fs_locations attribute provided by servA would have a fs_root value of "/a/b/c" and two entries in fs_location. One entry in fs_location will be for itself (servA) and the other will be for servB with a path of "/x/y/z". With this information, the client is able to substitute "/x/y/z" for the "/a/b/c" at the beginning of its access path and construct "/x/y/z/d" to use for the new server.
一例として、2台のサーバ（SERVAとservB）に位置する複製されたファイルシステムがあります。 SERVAでファイル・システムは、パス「/ A / B / C」に位置しています。 servBでファイルシステムは「/ X / Y / Z」経路に配置されています。この例では、クライアントは、「/ A / B / C / D」のマルチコンポーネントルックアップ経路とSERVAで第1のファイルシステムにアクセスします。クライアントは「/ A / B / C / D」のファイルハンドルを得るために、多成分のルックアップを使用しているので、ファイルシステムのルートは「/ A / B / C」でSERVAの名前空間に配置されていることを認識しません。クライアントはservBに切り替わるときに、それは最初SERVAで参照されるディレクトリは現在servBのパス「/ X / Y / Z / D」で表されることを決定する必要があります。これを容易にするために、セルバが提供する属性fs_位置は、「/ A / B / C」とfs_locationにおける2つのエントリのfs_root値を持っているでしょう。 fs_locationにおける1つのエントリがそれ自身のために（SERVA）になり、他方は「/ X / Y / Z」のパスとservBためであろう。この情報により、クライアントは、「/ X / Y / Z / D」に使用するとそのアクセスパスの先頭に「/ A / B / C」は、「/ X / Y / Z」を代入し、構築することが可能です新しいサーバー。
Filehandles for file systems that are replicated or migrated generally have the same semantics as for file systems that are not replicated or migrated. For example, if a file system has persistent filehandles and it is migrated to another server, the filehandle values for the file system will be valid at the new server.
複製されたか、移行されたファイル・システムのファイルハンドルは、一般的に、複製または移行されていないファイルシステムの場合と同じ意味を持っています。ファイルシステムは永続的なファイルハンドルを持っており、それが別のサーバに移行された場合、ファイルシステムのファイルハンドルの値は、新しいサーバーで有効になります。
For volatile filehandles, the servers involved likely do not have a mechanism to transfer filehandle format and content between themselves. Therefore, a server may have difficulty in determining if a volatile filehandle from an old server should return an error of NFS4ERR_FHEXPIRED. Therefore, the client is informed, with the use of the fh_expire_type attribute, whether volatile filehandles will expire at the migration or replication event. If the bit FH4_VOL_MIGRATION is set in the fh_expire_type attribute, the client must treat the volatile filehandle as if the server had returned the NFS4ERR_FHEXPIRED error. At the migration or replication event in the presence of the FH4_VOL_MIGRATION bit, the client will not present the original or old volatile file handle to the new server. The client will start its communication with the new server by recovering its filehandles using the saved file names.
揮発性ファイルハンドルの場合は、おそらく関係するサーバーは、自分たちの間でファイルハンドル形式と内容を転送するためのメカニズムを持っていません。そのため、サーバは、古いサーバからの揮発性ファイルハンドルがNFS4ERR_FHEXPIREDのエラーを返すべきかどうかを判断することが困難であってもよいです。そのため、クライアントは、揮発性ファイルハンドルが移動または複製イベントで期限切れとなるかどうか、fh_expire_type属性を使用して、通知されます。ビットFH4_VOL_MIGRATIONがfh_expire_type属性に設定されている場合は、サーバーがNFS4ERR_FHEXPIREDエラーを返したかのように、クライアントは、揮発性ファイルハンドルを扱う必要があります。 FH4_VOL_MIGRATIONビットの存在下での移動または複製イベントでは、クライアントは、新しいサーバーに、元または古い揮発性ファイルハンドルを提示しません。クライアントは、保存されたファイル名を使用して、そのファイルハンドルを回収することによって、新しいサーバとの通信を開始します。
On a UNIX server the name space describes all the files reachable by pathnames under the root directory or "/". On a Windows NT server the name space constitutes all the files on disks named by mapped disk letters. NFS server administrators rarely make the entire server's file system name space available to NFS clients. More often portions of the name space are made available via an "export" feature. In previous versions of the NFS protocol, the root filehandle for each export is obtained through the MOUNT protocol; the client sends a string that identifies the export of name space and the server returns the root filehandle for it. The MOUNT protocol supports an EXPORTS procedure that will enumerate the server's exports.
UNIXサーバーで名前空間は、ルートディレクトリの下にパス名で到達可能なすべてのファイルを記述したり、「/」。 Windows NTサーバーで名前空間がマッピングされたディスクの文字で指定されたディスク上のすべてのファイルを構成しています。 NFSサーバーの管理者は、めったにNFSクライアントに、サーバー全体のファイルシステムの名前空間を利用可能にしません。多くの場合、名前空間の部分は、「エクスポート」機能を経由して利用できるようになります。 NFSプロトコルの旧バージョンでは、各エクスポートのルートファイルハンドルは、MOUNTプロトコルを介して得られます。クライアントは、名前空間の輸出を識別する文字列を送信し、サーバーはそれのためのルートファイルハンドルを返します。 MOUNTプロトコルは、サーバの輸出を列挙しますEXPORTS手順をサポートしています。
The NFS version 4 protocol provides a root filehandle that clients can use to obtain filehandles for these exports via a multi-component LOOKUP. A common user experience is to use a graphical user interface (perhaps a file "Open" dialog window) to find a file via progressive browsing through a directory tree. The client must be able to move from one export to another export via single-component, progressive LOOKUP operations.
NFSバージョン4プロトコルは、クライアントが多成分LOOKUPを介してこれらの輸出のためにファイルハンドルを取得するために使用することができ、ルートファイルハンドルを提供します。一般的なユーザーエクスペリエンスは、ディレクトリツリーをプログレッシブブラウジング経由でファイルを見つけるために、グラフィカル・ユーザー・インターフェース（おそらくファイル「開く」ダイアログ・ウィンドウ）を使用することです。クライアントは、単一成分、プログレッシブLOOKUP操作を介して別の輸出に1つのエクスポートから動くことができなければなりません。
This style of browsing is not well supported by the NFS version 2 and 3 protocols. The client expects all LOOKUP operations to remain within a single server file system. For example, the device attribute will not change. This prevents a client from taking name space paths that span exports.
ブラウジングのこのスタイルはよくNFSバージョン2と3のプロトコルによってサポートされていません。クライアントは、すべてのLOOKUP操作は、単一のサーバ・ファイル・システム内にとどまると予想しています。例えば、デバイスの属性が変更されません。これは、輸出にまたがる名前空間のパスを取ってからクライアントを防ぎます。
An automounter on the client can obtain a snapshot of the server's name space using the EXPORTS procedure of the MOUNT protocol. If it understands the server's pathname syntax, it can create an image of the server's name space on the client. The parts of the name space that are not exported by the server are filled in with a "pseudo file system" that allows the user to browse from one mounted file system to another. There is a drawback to this representation of the server's name space on the client: it is static. If the server administrator adds a new export the client will be unaware of it.
クライアント上のオートマウンタは、MOUNTプロトコルのEXPORTS手順を使用して、サーバーの名前空間のスナップショットを取得することができます。それは、サーバのパス名の構文を理解している場合、それは、クライアント上のサーバーの名前空間の画像を作成することができます。サーバーによってエクスポートされていない名前空間の部分は、ユーザーが別のマウントされたファイルシステムから参照することができ、「擬似ファイルシステム」で満たされています。クライアント上のサーバーの名前空間のこの表現への欠点があります：それは静的です。サーバ管理者が新たな輸出を追加した場合、クライアントはそれに気づいていないだろう。
NFS version 4 servers avoid this name space inconsistency by presenting all the exports within the framework of a single server name space. An NFS version 4 client uses LOOKUP and READDIR operations to browse seamlessly from one export to another. Portions of the server name space that are not exported are bridged via a "pseudo file system" that provides a view of exported directories only. A pseudo file system has a unique fsid and behaves like a normal, read only file system.
NFSバージョン4サーバーは、単一のサーバーの名前空間の枠組みの中で、すべての輸出を提示することによって、この名前空間の矛盾を避けます。 NFSバージョン4クライアントは、別のエクスポートからシームレスに閲覧することLOOKUPとREADDIR操作を使用しています。エクスポートされていないサーバーの名前空間の一部のみがエクスポートされたディレクトリのビューを提供し、「擬似ファイルシステム」を介してブリッジされます。擬似ファイルシステムは、ユニークなFSIDを持っており、ファイルシステムのみを読んで、通常のように振る舞います。
Based on the construction of the server's name space, it is possible that multiple pseudo file systems may exist. For example,
サーバーの名前空間の構築に基づいて、複数の疑似ファイルシステムが存在する可能性があります。例えば、
/a pseudo file system /a/b real file system /a/b/c pseudo file system /a/b/c/d real file system
/擬似ファイルシステム/ A / B実ファイルシステム/ A / B / C疑似ファイルシステム/ A / B / C / D実ファイルシステム
Each of the pseudo file systems are consider separate entities and therefore will have a unique fsid.
疑似ファイルシステムのそれぞれはユニークなFSIDを持つことになりますので、別々のエンティティを検討しています。
The DOS and Windows operating environments are sometimes described as having "multiple roots". File systems are commonly represented as disk letters. MacOS represents file systems as top level names. NFS version 4 servers for these platforms can construct a pseudo file system above these root names so that disk letters or volume names are simply directory names in the pseudo root.
DOSとWindowsのオペレーティング環境は、時々「重根」を有すると記載されています。ファイルシステムは、一般的にディスクの文字として表されます。 MacOSのは、トップレベルの名前としてファイル・システムを表します。ディスクの文字またはボリューム名は、単に疑似ルートにディレクトリ名になるように、NFSバージョンこれらのプラットフォーム用の4台のサーバーは、これらのルート名の上の擬似ファイルシステムを構築することができます。
The nature of the server's pseudo file system is that it is a logical representation of file system(s) available from the server. Therefore, the pseudo file system is most likely constructed dynamically when the server is first instantiated. It is expected that the pseudo file system may not have an on disk counterpart from which persistent filehandles could be constructed. Even though it is preferable that the server provide persistent filehandles for the pseudo file system, the NFS client should expect that pseudo file system filehandles are volatile. This can be confirmed by checking the associated "fh_expire_type" attribute for those filehandles in question. If the filehandles are volatile, the NFS client must be prepared to recover a filehandle value (e.g. with a multi-component LOOKUP) when receiving an error of NFS4ERR_FHEXPIRED.
サーバの疑似ファイルシステムの性質は、それがサーバから利用可能なファイルシステム（複数可）の論理的な表現であるということです。そのため、擬似ファイルシステムは、最も可能性の高いサーバが最初にインスタンス化されるときに動的に構築されています。擬似ファイルシステムは永続的なファイルハンドルを構築することができたから、ディスク上の対応するものがないことが予想されます。それは、サーバが擬似ファイルシステムのための永続的なファイルハンドルを提供することが好ましいですが、NFSクライアントは、擬似ファイルシステムのファイルハンドルが揮発性であることを期待してください。これが問題になっているこれらのファイルハンドルに関連付けられた「fh_expire_type」属性をチェックすることで確認することができます。ファイルハンドルが揮発性である場合、NFSクライアントはNFS4ERR_FHEXPIREDのエラーを受信した場合（例えば、多成分LOOKUPで）ファイルハンドル値を回復するために用意されなければなりません。
If the server's root file system is exported, one might conclude that a pseudo-file system is not needed. This would be wrong. Assume the following file systems on a server:
サーバーのルートファイルシステムがエクスポートされている場合は、一つは、擬似ファイルシステムが必要とされていないと結論することがあります。これは間違っているだろう。サーバー上の次のファイルシステムを想定します。
/ disk1 (exported)
/a disk2 (not exported)
/a/b disk3 (exported)
Because disk2 is not exported, disk3 cannot be reached with simple LOOKUPs. The server must bridge the gap with a pseudo-file system.
DISK2はエクスポートされていないので、DISK3は簡単な検索で到達することはできません。サーバは、擬似ファイルシステムとのギャップを埋める必要があります。
The server file system environment may be constructed in such a way that one file system contains a directory which is 'covered' or mounted upon by a second file system. For example:
サーバ・ファイル・システム環境は、一つのファイルシステムは、「被覆」又は第二のファイルシステムによって上に搭載されているディレクトリを含むように構成してもよいです。例えば：
/a/b (file system 1)
/a/b/c/d (file system 2)
The pseudo file system for this server may be constructed to look like:
このサーバーの疑似ファイルシステムが見えるように構築することができます。
/ (place holder/not exported)
/a/b (file system 1)
/a/b/c/d (file system 2)
It is the server's responsibility to present the pseudo file system that is complete to the client. If the client sends a lookup request for the path "/a/b/c/d", the server's response is the filehandle of the file system "/a/b/c/d". In previous versions of the NFS protocol, the server would respond with the directory "/a/b/c/d" within the file system "/a/b".
クライアントへの完全な擬似ファイルシステムを提示するサーバーの責任です。クライアントは、パス「/ A / B / C / D」の検索要求を送信すると、サーバーの応答は、ファイルシステム「/ A / B / C / D」のファイルハンドルです。 NFSプロトコルの以前のバージョンでは、サーバーは、ディレクトリ、ファイル・システム内の「/ A / B / C / D」「/ A / B」と応答することになります。
The NFS client will be able to determine if it crosses a server mount point by a change in the value of the "fsid" attribute.
NFSクライアントは、サーバが「FSID」属性の値の変化により、マウントポイントを横断するかどうかを判断することができるようになります。
The application of the server's security policy needs to be carefully considered by the implementor. One may choose to limit the viewability of portions of the pseudo file system based on the server's perception of the client's ability to authenticate itself properly. However, with the support of multiple security mechanisms and the ability to negotiate the appropriate use of these mechanisms, the server is unable to properly determine if a client will be able to authenticate itself. If, based on its policies, the server chooses to limit the contents of the pseudo file system, the server may effectively hide file systems from a client that may otherwise have legitimate access.
サーバーのセキュリティポリシーの適用は慎重に実装者が検討する必要があります。一つは、適切に自身を認証するためのクライアントの能力のサーバーの認識に基づいて疑似ファイルシステムの部分の視認性を制限することもできます。しかし、複数のセキュリティ・メカニズムのサポートとこれらのメカニズムの適切な使用を交渉する能力を持つ、サーバーは、クライアントが自身を認証することができるようになります場合は、適切に決定することができません。 、そのポリシーに基づいて、サーバは疑似ファイルシステムの内容を制限することを選択した場合、サーバーは効果的にそれ以外の場合は、正当なアクセス権を持っていることがあり、クライアントからのファイルシステムを隠すことがあります。
Integrating locking into the NFS protocol necessarily causes it to be state-full. With the inclusion of "share" file locks the protocol becomes substantially more dependent on state than the traditional combination of NFS and NLM [XNFS]. There are three components to making this state manageable:
NFSプロトコルにロック統合必ずしもそれが状態フルさせます。 「共有」ファイルロックを含めてプロトコルはNFSとNLM [XNFS】従来の組合せよりも状態に実質的に依存するようになります。この状態は管理しやすい作りには3つのコンポーネントがあります。
o Clear division between client and server
クライアントとサーバの間に明確な区分O
o Ability to reliably detect inconsistency in state between client and server
O能力は確実にクライアントとサーバの間の状態に矛盾を検出します
o Simple and robust recovery mechanisms
Oシンプルで堅牢な回復メカニズム
In this model, the server owns the state information. The client communicates its view of this state to the server as needed. The client is also able to detect inconsistent state before modifying a file.
このモデルでは、サーバーは、状態情報を所有しています。必要に応じてクライアントがサーバにこの状態のビューを伝えます。また、クライアントは、ファイルを変更する前に、矛盾した状態を検出することが可能です。
To support Win32 "share" locks it is necessary to atomically OPEN or CREATE files. Having a separate share/unshare operation would not allow correct implementation of the Win32 OpenFile API. In order to correctly implement share semantics, the previous NFS protocol mechanisms used when a file is opened or created (LOOKUP, CREATE, ACCESS) need to be replaced. The NFS version 4 protocol has an OPEN operation that subsumes the functionality of LOOKUP, CREATE, and ACCESS. However, because many operations require a filehandle, the traditional LOOKUP is preserved to map a file name to filehandle without establishing state on the server. The policy of granting access or modifying files is managed by the server based on the client's state. These mechanisms can implement policy ranging from advisory only locking to full mandatory locking.
Win32の「シェア」ロックをサポートするために、それはアトミックOPENまたはファイルを作成する必要があります。別のシェア/共有解除操作を持つことのWin32のOpenFileのAPIの正しい実装を許可しないでしょう。正しく共有セマンティクスを実現するために、ファイルを開くまたは作成されたときに使用される従来のNFSプロトコルメカニズム（LOOKUPは、CREATE、ACCESS）に交換する必要があります。 NFSバージョン4プロトコルは、LOOKUP、CREATE、およびACCESSの機能を包含するOPEN操作を有します。多くの操作は、ファイルハンドルを必要とするためしかし、伝統的なLOOKUPは、サーバー上の状態を確立することなくファイルハンドルにファイル名をマップするために保存されています。アクセスを許可またはファイルを変更するポリシーは、クライアントの状態に基づいてサーバによって管理されています。これらのメカニズムは、完全な強制ロックにロックする諮問に至るまでポリシーを実装することができます。
It is assumed that manipulating a lock is rare when compared to READ and WRITE operations. It is also assumed that crashes and network partitions are relatively rare. Therefore it is important that the READ and WRITE operations have a lightweight mechanism to indicate if they possess a held lock. A lock request contains the heavyweight information required to establish a lock and uniquely define the lock owner.
読み出し動作と書き込み動作と比較した場合、ロックを操作することはまれであると仮定されます。また、クラッシュやネットワークパーティションは比較的まれであると仮定する。したがって、READとWRITE操作は、彼らが保持されたロックを所有どうかを示すための軽量なメカニズムを持っていることが重要です。ロック要求がロックを確立し、一意のロック所有者を定義するために必要なヘビーな情報を含んでいます。
The following sections describe the transition from the heavy weight information to the eventual stateid used for most client and server locking and lease interactions.
以下のセクションでは、ほとんどのクライアントとサーバーのロックとリースの相互作用のために使用される最終的なのstateidに重い重み情報からの遷移を記述しています。
For each LOCK request, the client must identify itself to the server.
各LOCK要求の場合、クライアントはサーバーに自分自身を識別しなければなりません。
This is done in such a way as to allow for correct lock identification and crash recovery. Client identification is accomplished with two values.
これは、正しいロック識別とクラッシュリカバリを可能にするような方法で行われます。クライアント識別は二つの値を用いて達成されます。
o A verifier that is used to detect client reboots.
クライアントの再起動を検出するために使用される検証O。
o A variable length opaque array to uniquely define a client.
O可変長の不透明な配列は、クライアントを一意に定義します。
For an operating system this may be a fully qualified host name
or IP address. For a user level NFS client it may additionally
contain a process id or other unique sequence.
The data structure for the Client ID would then appear as:
：クライアントIDのためのデータ構造は、次にようになり
struct nfs_client_id {
opaque verifier[4];
opaque id<>;
}
It is possible through the mis-configuration of a client or the existence of a rogue client that two clients end up using the same nfs_client_id. This situation is avoided by "negotiating" the nfs_client_id between client and server with the use of the SETCLIENTID and SETCLIENTID_CONFIRM operations. The following describes the two scenarios of negotiation.
これは、クライアントの設定ミスや2つのクライアントが同じnfs_client_idを使用して終了不正なクライアントの存在によって可能です。この状況は、SETCLIENTIDとSETCLIENTID_CONFIRM操作を使用して、クライアントとサーバの間nfs_client_idを「交渉」によって回避されます。以下は、交渉の2つのシナリオを説明しています。
1 Client has never connected to the server
1つのクライアントがサーバに接続されたことがありません
In this case the client generates an nfs_client_id and unless another client has the same nfs_client_id.id field, the server accepts the request. The server also records the principal (or principal to uid mapping) from the credential in the RPC request that contains the nfs_client_id negotiation request (SETCLIENTID operation).
この場合、クライアントはnfs_client_idを生成し、別のクライアントが同じnfs_client_id.idフィールドを持っていない限り、サーバーは要求を受け付けます。また、サーバはnfs_client_id交渉要求（SETCLIENTID操作）が含まRPC要求における資格から元本（またはUIDマッピングに元本）を記録します。
Two clients might still use the same nfs_client_id.id due to perhaps configuration error. For example, a High Availability configuration where the nfs_client_id.id is derived from the ethernet controller address and both systems have the same address. In this case, the result is a switched union that returns, in addition to NFS4ERR_CLID_INUSE, the network address (the rpcbind netid and universal address) of the client that is using the id.
2つのクライアントは、まだ原因おそらく、設定エラーに同じnfs_client_id.idを使用する場合があります。例えばnfs_client_id.id、イーサネットコントローラアドレスから導出され、両方のシステムが同じアドレスを持つ、高可用性構成。この場合、結果はNFS4ERR_CLID_INUSE、IDを使用しているクライアントのネットワークアドレス（のrpcbindのNETIDおよびユニバーサルアドレス）に加えて、戻り切り替え組合です。
2 Client is re-connecting to the server after a client reboot
2クライアントは、クライアントの再起動後にサーバーに再接続されます
In this case, the client still generates an nfs_client_id but the nfs_client_id.id field will be the same as the nfs_client_id.id generated prior to reboot. If the server finds that the principal/uid is equal to the previously "registered" nfs_client_id.id, then locks associated with the old nfs_client_id are immediately released. If the principal/uid is not equal, then this is a rogue client and the request is returned in error. For more discussion of crash recovery semantics, see the section on "Crash Recovery".
この場合、クライアントはまだnfs_client_idを生成しますが、nfs_client_id.idフィールドには、再起動する前に発生したnfs_client_id.idと同じになります。サーバープリンシパル/ uidは以前に「登録」nfs_client_id.idに等しいことを発見した場合、古いnfs_client_idに関連したロックがすぐに解放されます。校長/ uidが等しくない場合、これは不正なクライアントであり、要求がエラーで返されます。クラッシュリカバリのセマンティクスのより多くの議論については、「クラッシュリカバリ」のセクションを参照してください。
It is possible for a retransmission of request to be received by the server after the server has acted upon and responded to the original client request. Therefore to mitigate effects of the retransmission of the SETCLIENTID operation, the client and server use a confirmation step. The server returns a confirmation verifier that the client then sends to the server in the SETCLIENTID_CONFIRM operation. Once the server receives the confirmation from the client, the locking state for the client is released.
要求の再送信は、サーバーが作用し、元のクライアント要求に応答した後に、サーバが受信することが可能です。したがって、SETCLIENTID操作の再送信の影響を軽減するために、クライアントとサーバは、確認ステップを使用します。サーバーは、クライアントが、その後SETCLIENTID_CONFIRM操作でサーバーに送信する確認の検証を返します。サーバがクライアントからの確認を受信すると、クライアントのロック状態が解除されます。
In both cases, upon success, NFS4_OK is returned. To help reduce the amount of data transferred on OPEN and LOCK, the server will also return a unique 64-bit clientid value that is a shorthand reference to the nfs_client_id values presented by the client. From this point forward, the client will use the clientid to refer to itself.
どちらの場合も、成功すると、NFS4_OKが返されます。 OPENとLOCKに転送されるデータの量を減らすために、サーバは、クライアントから提示さnfs_client_id値に速記参照であるユニークな64ビットのClientID値を返します。これ以降、クライアントは、自分自身を参照するためのClientIDを使用します。
The clientid assigned by the server should be chosen so that it will not conflict with a clientid previously assigned by the server. This applies across server restarts or reboots. When a clientid is presented to a server and that clientid is not recognized, as would happen after a server reboot, the server will reject the request with the error NFS4ERR_STALE_CLIENTID. When this happens, the client must obtain a new clientid by use of the SETCLIENTID operation and then proceed to any other necessary recovery for the server reboot case (See the section "Server Failure and Recovery").
それは以前にサーバによって割り当てられたClientIDと競合しないように、サーバによって割り当てられたClientIDを選択する必要があります。これは、サーバの再起動または再起動しても適用されます。 ClientIDがサーバーに提示され、それにClientIDは、サーバの再起動後に起こるように、認識されない場合は、サーバがエラーNFS4ERR_STALE_CLIENTIDで要求を拒否します。このような場合、クライアントはSETCLIENTID操作の使用によって、新しいのClientIDを取得し、サーバーの再起動の場合のために、他の必要な回復（「サーバの障害と復旧」を参照してください）を行っている必要があります。
The client must also employ the SETCLIENTID operation when it receives a NFS4ERR_STALE_STATEID error using a stateid derived from its current clientid, since this also indicates a server reboot which has invalidated the existing clientid (see the next section "nfs_lockowner and stateid Definition" for details).
それが現在のclientidに由来したstateidを使用してNFS4ERR_STALE_STATEIDエラーを受信したとき、これはまた、既存のclientidを無効にしているサーバーの再起動を示しているため、クライアントはまた、SETCLIENTID操作を採用する必要があります（詳細については、次のセクション「のnfs_lockownerとのstateidの定義」を参照してください） 。
If the server determines that the client holds no associated state for its clientid, the server may choose to release the clientid. The server may make this choice for an inactive client so that resources are not consumed by those intermittently active clients. If the client contacts the server after this release, the server must ensure the client receives the appropriate error so that it will use the SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new identity. It should be clear that the server must be very hesitant to release a clientid since the resulting work on the client to recover from such an event will be the same burden as if the server had failed and restarted. Typically a server would not release a clientid unless there had been no activity from that client for many minutes.
サーバーは、クライアントがそのclientidのための関連した状態を保持していないと判断した場合、サーバーはそのclientidをリリースすることもできます。リソースは、これらの断続的にアクティブなクライアントによって消費されないように、サーバーは非アクティブクライアントのためにこの選択を行うことができます。クライアントは、このリリースの後にサーバー場合は、サーバーは、それが新しいアイデンティティを確立するためにSETCLIENTID / SETCLIENTID_CONFIRMシーケンスを使用するようにクライアントに適切なエラーを受け取るようにする必要があります。サーバーが失敗し、再起動したかのようなイベントから回復するには、クライアント上の結果の作業は同じ負担になりますので、サーバがのclientidをリリースするのは非常に躊躇しなければならないことは明らかです。多く分間そのクライアントからの活動がなかった場合を除き、通常のサーバーはのclientidをリリースしないでしょう。
When requesting a lock, the client must present to the server the clientid and an identifier for the owner of the requested lock. These two fields are referred to as the nfs_lockowner and the definition of those fields are:
ロックを要求すると、クライアントはサーバーにClientIDをし、要求されたロックの所有者のための識別子を提示する必要があります。これらの2つのフィールドはnfs_lockownerのと呼ばれ、それらのフィールドの定義がされています。
o A clientid returned by the server as part of the client's use of the SETCLIENTID operation.
OのClientIDはSETCLIENTID操作のクライアントの使用の一環として、サーバから返されました。
o A variable length opaque array used to uniquely define the owner of a lock managed by the client.
O可変長の不透明な配列は、一意のクライアントが管理するロックの所有者を定義するために使用されます。
This may be a thread id, process id, or other unique value.
これは、スレッドID、プロセスID、または他のユニークな値であってもよいです。
When the server grants the lock, it responds with a unique 64-bit stateid. The stateid is used as a shorthand reference to the nfs_lockowner, since the server will be maintaining the correspondence between them.
サーバーがロックを付与する場合は、固有の64ビットのstateidで応答します。サーバはそれらの間の対応を維持するためのstateidはnfs_lockownerのに速記参照として使用されます。
The server is free to form the stateid in any manner that it chooses as long as it is able to recognize invalid and out-of-date stateids. This requirement includes those stateids generated by earlier instances of the server. From this, the client can be properly notified of a server restart. This notification will occur when the client presents a stateid to the server from a previous instantiation.
サーバーは、それがある限り、無効と外の日付のstateidsを認識することが可能であるとして選択したことをどのようにしたstateidを形成して自由です。この要件は、サーバーの以前のインスタンスによって生成されたもののstateidsが含まれています。このことから、クライアントは適切にサーバの再起動を通知することができます。クライアントは、前のインスタンスからサーバーへのstateidを提示したときに、この通知は発生します。
The server must be able to distinguish the following situations and return the error as specified:
サーバーは、次のような状況を区別し、指定されたエラーを返すことができなければなりません。
o The stateid was generated by an earlier server instance (i.e. before a server reboot). The error NFS4ERR_STALE_STATEID should be returned.
stateid O（すなわち、サーバの再起動前に）以前のサーバインスタンスによって生成されました。エラーNFS4ERR_STALE_STATEIDが返されます。
o The stateid was generated by the current server instance but the stateid no longer designates the current locking state for the lockowner-file pair in question (i.e. one or more locking operations has occurred). The error NFS4ERR_OLD_STATEID should be returned.
stateidは現在のサーバインスタンスによって生成されないが、のstateidは、もはや問題でlockownerファイルペアの現在のロック状態を示したO（すなわち、1種またはそれ以上のロック操作が発生しています）。エラーNFS4ERR_OLD_STATEIDが返されます。
This error condition will only occur when the client issues a locking request which changes a stateid while an I/O request that uses that stateid is outstanding.
クライアントはのstateidが未解決であることを利用したI / O要求ながらのstateidを変えるロック要求を発行したときに、このエラー条件にのみ発生します。
o The stateid was generated by the current server instance but the stateid does not designate a locking state for any active lockowner-file pair. The error NFS4ERR_BAD_STATEID should be returned.
stateid oを現在のサーバインスタンスによって生成されたが、のstateidは、任意のアクティブlockownerファイルペアのロック状態を指定しません。エラーNFS4ERR_BAD_STATEIDが返されます。
This error condition will occur when there has been a logic error on the part of the client or server. This should not happen.
クライアントまたはサーバーの一部の論理エラーがあった場合に、このエラー条件が発生します。これは起こるべきではありません。
One mechanism that may be used to satisfy these requirements is for the server to divide stateids into three fields:
これらの要件を満たすために使用され得る1つの機構は、三つのフィールドへのstateidsを分割するサーバーのためのものです。
o A server verifier which uniquely designates a particular server instantiation.
一意に特定のサーバインスタンスを指定するサーバ検証O。
o An index into a table of locking-state structures.
Oロック状態構造のテーブルへのインデックス。
o A sequence value which is incremented for each stateid that is associated with the same index into the locking-state table.
ロック状態テーブル内に同じインデックスに関連付けられているそれぞれのstateidのためにインクリメントされるシーケンス値O。
By matching the incoming stateid and its field values with the state held at the server, the server is able to easily determine if a stateid is valid for its current instantiation and state. If the stateid is not valid, the appropriate error can be supplied to the client.
サーバに保持された状態に入ってくるのstateid、そのフィールドの値を照合することによって、サーバは容易のstateidが現在のインスタンスと状態のために有効であるかどうかを決定することができます。 stateidが有効でない場合、適切なエラーがクライアントに供給することができます。
All READ and WRITE operations contain a stateid. If the nfs_lockowner performs a READ or WRITE on a range of bytes within a locked range, the stateid (previously returned by the server) must be used to indicate that the appropriate lock (record or share) is held. If no state is established by the client, either record lock or share lock, a stateid of all bits 0 is used. If no conflicting locks are held on the file, the server may service the READ or WRITE operation. If a conflict with an explicit lock occurs, an error is returned for the operation (NFS4ERR_LOCKED). This allows "mandatory locking" to be implemented.
すべての読み取りおよび書き込み操作は、たstateidを含んでいます。 nfs_lockownerがREADまたはロック範囲内のバイトの範囲にWRITEを実行する場合、（以前にサーバによって返された）のstateidは、適切なロック（レコードまたは共有）が保持されていることを示すために使用されなければなりません。何の状態がクライアントによって確立されていない場合は、レコードロックまたは共有ロックのどちらかは、すべてのビット0ののstateidが使用されています。競合するロックがファイルに開催されていない場合、サーバーは、READのサービスや操作を書き込むことができます。明示的なロックとの競合が発生した場合、エラーが操作（NFS4ERR_LOCKED）返されます。これは「強制ロック」は実現することができます。
A stateid of all bits 1 (one) allows READ operations to bypass record locking checks at the server. However, WRITE operations with stateid with bits all 1 (one) do not bypass record locking checks. File locking checks are handled by the OPEN operation (see the section "OPEN/CLOSE Operations").
すべてのビット1（1）ののstateidは、READ操作はサーバにレコードロックチェックを回避することを可能にします。しかし、ビット全て1（1）とのstateidで操作を書くレコードロックチェックをバイパスしません。ファイルロックチェックがOPEN操作によって処理され（セクション「OPEN / CLOSE操作」を参照）。
An explicit lock may not be granted while a READ or WRITE operation with conflicting implicit locking is being performed.
競合暗黙ロックとREADまたはWRITE動作が行われている間、明示的なロックが付与されなくてもよいです。
Locking is different than most NFS operations as it requires "at-most-one" semantics that are not provided by ONCRPC. ONCRPC over a reliable transport is not sufficient because a sequence of locking requests may span multiple TCP connections. In the face of retransmission or reordering, lock or unlock requests must have a well defined and consistent behavior. To accomplish this, each lock request contains a sequence number that is a consecutively increasing integer. Different nfs_lockowners have different sequences. The server maintains the last sequence number (L) received and the response that was returned.
それが「で最も-1」ONCRPCによって提供されていないセマンティクスを必要とするロックは、ほとんどのNFS操作とは異なります。ロック要求のシーケンスは、複数のTCP接続にまたがる可能性があるため、信頼性の高いトランスポート上でONCRPCは十分ではありません。再送信または並べ替えの顔には、ロックまたはロック解除要求が明確に定義されたと一貫性のある動作を持っている必要があります。これを達成するために、各ロック要求が連続して増加する整数であり、シーケンス番号を含みます。異なるnfs_lockownersは異なる配列を有します。サーバーは、最後のシーケンス番号（L）を受信し、返された応答を維持します。
Note that for requests that contain a sequence number, for each nfs_lockowner, there should be no more than one outstanding request.
シーケンス番号を含む要求に対して、各nfs_lockownerのために、1つ未満の未処理の要求があってはならないことに注意してください。
If a request with a previous sequence number (r < L) is received, it is rejected with the return of error NFS4ERR_BAD_SEQID. Given a properly-functioning client, the response to (r) must have been received before the last request (L) was sent. If a duplicate of last request (r == L) is received, the stored response is returned. If a request beyond the next sequence (r == L + 2) is received, it is rejected with the return of error NFS4ERR_BAD_SEQID. Sequence history is reinitialized whenever the client verifier changes.
前回のシーケンス番号（R <L）とのリクエストを受信した場合、それはエラーNFS4ERR_BAD_SEQIDの復帰で拒絶されます。最後の要求（L）が送信される前に、適切に機能するクライアントを考えると、（R）への応答が受信されている必要があります。最後の要求（R == L）の複製を受信した場合、保存された応答が返されます。次のシーケンス（R == L + 2）を越えた要求を受信した場合、それはエラーNFS4ERR_BAD_SEQIDの復帰で拒絶されます。クライアント検証が変更されるたびに、シーケンス履歴が再初期化されます。
Since the sequence number is represented with an unsigned 32-bit integer, the arithmetic involved with the sequence number is mod 2^32.
シーケンス番号は32ビットの符号なし整数で表現されているので、シーケンス番号に関わる演算は、2 ^ 32のMODです。
It is critical the server maintain the last response sent to the client to provide a more reliable cache of duplicate non-idempotent requests than that of the traditional cache described in [Juszczak]. The traditional duplicate request cache uses a least recently used algorithm for removing unneeded requests. However, the last lock request and response on a given nfs_lockowner must be cached as long as the lock state exists on the server.
サーバーが[Juszczak]で説明従来のキャッシュよりも、重複非べき等の要求より信頼性の高いキャッシュを提供するために、クライアントに送信された最後の応答を維持する重要です。伝統的な重複要求キャッシュは不要な要求を除去するために最も最近使用されたアルゴリズムを使用しています。しかし、与えられたnfs_lockownerの上の最後のロック要求と応答がある限り、ロック状態がサーバー上に存在するとしてキャッシュする必要があります。
As described above, the sequence number is per nfs_lockowner. As long as the server maintains the last sequence number received and follows the methods described above, there are no risks of a Byzantine router re-sending old requests. The server need only maintain the nfs_lockowner, sequence number state as long as there are open files or closed files with locks outstanding.
上述したように、シーケンス番号はnfs_lockownerのあたりです。限り、サーバーが受信した最後のシーケンス番号を維持し、上記の方法を以下のように、古い要求を再送信するビザンチンルータの一切のリスクはありません。サーバは限り優れたロックと開いているファイルまたは閉じたファイルがあるとのnfs_lockowner、シーケンス番号の状態を維持する必要があります。
LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, and CLOSE each contain a sequence number and therefore the risk of the replay of these operations resulting in undesired effects is non-existent while the server maintains the nfs_lockowner state.
LOCK、LOCKU、OPEN、OPEN_DOWNGRADE、各サーバがnfs_lockownerの状態を維持しながら、非存在である配列番号したがって望ましくない影響をもたらすこれらの操作の再生のリスクを含むCLOSE。
When a particular nfs_lockowner no longer holds open or file locking state at the server, the server may choose to release the sequence number state associated with the nfs_lockowner. The server may make this choice based on lease expiration, for the reclamation of server memory, or other implementation specific details. In any event, the server is able to do this safely only when the nfs_lockowner no longer is being utilized by the client. The server may choose to hold the nfs_lockowner state in the event that retransmitted requests are received. However, the period to hold this state is implementation specific.
特定のnfs_lockownerは、もはやサーバーで開いたり、ファイルロック状態を保持している場合は、サーバーはnfs_lockownerのに関連付けられたシーケンス番号を解除することを選択しないことがあります。サーバーは、サーバーのメモリ、または他の実装固有の詳細の再生のために、リース満了に基づいてこの選択を行うことができます。いずれにせよ、サーバは安全のnfs_lockownerがもはやクライアントによって利用されていない場合にのみ、これを実行することができます。サーバは、再送要求が受信された場合にnfs_lockownerの状態を保持することもできます。しかし、この状態を保持する期間は、実装固有のものです。
In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is retransmitted after the server has previously released the nfs_lockowner state, the server will find that the nfs_lockowner has no files open and an error will be returned to the client. If the nfs_lockowner does have a file open, the stateid will not match and again an error is returned to the client.
サーバーが以前のnfs_lockowner状態をリリースした後にLOCK、LOCKU、OPEN_DOWNGRADE、またはCLOSEが再送される場合には、サーバはnfs_lockownerのは、オープンファイルがありませんし、エラーがクライアントに返されることがわかります。 nfs_lockownerがファイルを開いていない場合は、のstateidは一致しませんし、再びエラーがクライアントに返されます。
In the case that an OPEN is retransmitted and the nfs_lockowner is being used for the first time or the nfs_lockowner state has been previously released by the server, the use of the OPEN_CONFIRM operation will prevent incorrect behavior. When the server observes the use of the nfs_lockowner for the first time, it will direct the client to perform the OPEN_CONFIRM for the corresponding OPEN. This sequence establishes the use of an nfs_lockowner and associated sequence number. See the section "OPEN_CONFIRM - Confirm Open" for further details.
OPENが再送され、サーバーでのnfs_lockownerが初めて使用されているかのnfs_lockowner状態が以前にリリースされた場合には、オープン_CONFIRM操作を使用すると、不正な動作を防止します。サーバが初めてのnfs_lockownerの使用を観察すると、対応するOPENのためのオープン_CONFIRMを実行するために、クライアントに指示します。この配列はnfs_lockownerのおよび関連するシーケンス番号の使用を確立します。詳細について - セクション「オープンを確認してオープン_CONFIRM」を参照してください。
The protocol allows a lock owner to request a lock with one byte range and then either upgrade or unlock a sub-range of the initial lock. It is expected that this will be an uncommon type of request. In any case, servers or server file systems may not be able to support sub-range lock semantics. In the event that a server receives a locking request that represents a sub-range of current locking state for the lock owner, the server is allowed to return the error NFS4ERR_LOCK_RANGE to signify that it does not support sub-range lock operations. Therefore, the client should be prepared to receive this error and, if appropriate, report the error to the requesting application.
プロトコルは、ロック所有者は、1つのバイトの範囲のロックを要求した後、初期ロックのサブ範囲をアップグレードするか、アンロックのいずれかを可能にします。要求の珍しいタイプであることが期待されます。いずれの場合も、サーバーまたはサーバーのファイル・システムは、サブ範囲ロックのセマンティクスをサポートすることができない場合があります。サーバがロック所有者の現在のロック状態のサブ範囲を表すロック要求を受信した場合に、サーバは、それがサブ範囲ロック操作をサポートしていないことを示すためにエラーNFS4ERR_LOCK_RANGEを返すことが許可されています。そのため、クライアントは、適切な場合には、要求元のアプリケーションにエラーを報告し、このエラーを受け取るために準備してする必要があります。
The client is discouraged from combining multiple independent locking ranges that happen to be adjacent into a single request since the server may not support sub-range requests and for reasons related to the recovery of file locking state in the event of server failure. As discussed in the section "Server Failure and Recovery" below, the server may employ certain optimizations during recovery that work effectively only when the client's behavior during lock recovery is similar to the client's locking behavior prior to server failure.
クライアントは、サーバが、サブ範囲要求をサポートしないかもしれないので、単一の要求に隣接するように起こる複数の独立したロック範囲を組み合わせることから、サーバに障害が発生した場合の状態をロックファイルの回復に関連する理由のために推奨されています。以下の「サーバーの障害および回復」で説明したように、サーバはロックリカバリ時のクライアントの動作は、以前のサーバーの障害へのクライアントのロック動作に似ている場合にのみ、効果的に機能回復中の特定の最適化を使用することができます。
Some clients require the support of blocking locks. The NFS version 4 protocol must not rely on a callback mechanism and therefore is unable to notify a client when a previously denied lock has been granted. Clients have no choice but to continually poll for the lock. This presents a fairness problem. Two new lock types are added, READW and WRITEW, and are used to indicate to the server that the client is requesting a blocking lock. The server should maintain an ordered list of pending blocking locks. When the conflicting lock is released, the server may wait the lease period for the first waiting client to re-request the lock. After the lease period expires the next waiting client request is allowed the lock. Clients are required to poll at an interval sufficiently small that it is likely to acquire the lock in a timely manner. The server is not required to maintain a list of pending blocked locks as it is used to increase fairness and not correct operation. Because of the unordered nature of crash recovery, storing of lock state to stable storage would be required to guarantee ordered granting of blocking locks.
一部のクライアントには、ロックをブロックのサポートを必要とします。 NFSバージョン4プロトコルは、コールバックメカニズムに依存しているため、以前に拒否されたロックが許可されたときにクライアントに通知することができないではない必要があります。クライアントが継続的にロックをポーリングするしかありません。これは、公平性の問題を提示します。二つの新しいロックタイプは、READWとWRITEWを追加され、クライアントがブロッキングロックを要求しているサーバーに示すために使用されています。サーバーは、保留中のブロッキング・ロックの順序付きリストを維持する必要があります。矛盾するロックが解除されると、サーバーは再要求するロックへの最初の待機しているクライアントのリース期間を待つことがあります。リース期間が満了した後、次の待機中のクライアント要求は、ロックを許可されています。クライアントは、タイムリーにロックを取得する可能性があることを十分に小さい間隔でポーリングするように要求されています。サーバーは、正しい動作を公平性を高めるために使用されていないようブロックされたロックを保留中のリストを維持するために必要とされていません。そのためクラッシュ回復の順不同の性質上、安定したストレージにロック状態の記憶がロックをブロックする命じ付与を保証するために必要とされるであろう。
Servers may also note the lock types and delay returning denial of the request to allow extra time for a conflicting lock to be released, allowing a successful return. In this way, clients can avoid the burden of needlessly frequent polling for blocking locks. The server should take care in the length of delay in the event the client retransmits the request.
サーバはまた、ロックの種類に注意し、成功したリターンをできるように、リリースされる競合ロックのための余分な時間を与えるために、要求の拒否を返す遅れることがあります。このように、クライアントがロックを阻止するための不頻繁にポーリングの負担を回避することができます。サーバは、クライアントが要求を再送信する場合に、遅延の長さに世話をする必要があります。
The purpose of a lease is to allow a server to remove stale locks that are held by a client that has crashed or is otherwise unreachable. It is not a mechanism for cache consistency and lease renewals may not be denied if the lease interval has not expired.
リースの目的は、サーバがクラッシュしたか、そうでなければ到達できないいるクライアントによって保持されている古いロックを削除できるようにすることです。リース期間が満了していない場合は拒否されないことがキャッシュの一貫性とリース更新のためのメカニズムではありません。
The following events cause implicit renewal of all of the leases for a given client (i.e. all those sharing a given clientid). Each of these is a positive indication that the client is still active and that the associated state held at the server, for the client, is still valid.
次のイベントは、指定されたクライアントのリースのすべての暗黙の更新を引き起こす（すなわち、与えられたclientidを共有するすべてのものを）。これらのそれぞれは、クライアントがまだアクティブであると、サーバで開催された関連する状態は、クライアントのために、まだ有効であることを陽性表示です。
o An OPEN with a valid clientid.
有効なのclientIdを持つOPEN O。
o Any operation made with a valid stateid (CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, READ, RENEW, SETATTR, WRITE). This does not include the special stateids of all bits 0 or all bits 1.
O任意の操作が有効なstateid（CLOSE、DELEGRETURN、LOCK、LOCKU、OPEN、オープン_CONFIRM、READ、RENEW、SETATTR、WRITE）で作られました。これは、すべてのビット0または全てのビット1の特別のstateidsが含まれていません。
Note that if the client had restarted or rebooted, the client
would not be making these requests without issuing the
SETCLIENTID operation. The use of the SETCLIENTID operation
(possibly with the addition of the optional SETCLIENTID_CONFIRM
operation) notifies the server to drop the locking state
associated with the client.
If the server has rebooted, the stateids (NFS4ERR_STALE_STATEID error) or the clientid (NFS4ERR_STALE_CLIENTID error) will not be valid hence preventing spurious renewals.
サーバーを再起動している場合、のstateids（NFS4ERR_STALE_STATEIDエラー）またはのclientid（NFS4ERR_STALE_CLIENTIDエラー）スプリアス更新を妨げるので、有効になりません。
This approach allows for low overhead lease renewal which scales well. In the typical case no extra RPC calls are required for lease renewal and in the worst case one RPC is required every lease period (i.e. a RENEW operation). The number of locks held by the client is not a factor since all state for the client is involved with the lease renewal action.
このアプローチはうまくスケールの低オーバーヘッドのリース更新が可能になります。典型的な場合には余分なRPCコールはリース更新のために必要とされず、最悪の場合の1つのRPC（すなわちA操作をRENEW）毎にリース期間を要求されます。クライアントの状態はすべてのリース更新アクションに関与しているため、クライアントが保持しているロックの数倍ではありません。
Since all operations that create a new lease also renew existing leases, the server must maintain a common lease expiration time for all valid leases for a given client. This lease time can then be easily updated upon implicit lease renewal actions.
また、新しいリースを作成するすべての操作は、既存のリースを更新するので、サーバが特定のクライアントのための有効なすべてのリースのための共通のリース満了時間を維持しなければなりません。このリース時間は、簡単に暗黙のリース更新アクション時に更新することができます。
The important requirement in crash recovery is that both the client and the server know when the other has failed. Additionally, it is required that a client sees a consistent view of data across server restarts or reboots. All READ and WRITE operations that may have been queued within the client or network buffers must wait until the client has successfully recovered the locks protecting the READ and WRITE operations.
クラッシュリカバリでの重要な要件は、他に障害が発生したときにクライアントとサーバーの両方が知っていることです。さらに、クライアントがサーバの再起動または再起動してもデータの一貫性のあるビューを見ることが必要です。クライアントが正常に読み取りおよび書き込み操作を保護するロックを回復するまで、クライアントまたはネットワークバッファ内キューに登録されている可能性があり、すべての読み取りおよび書き込み操作が待機する必要があります。
In the event that a client fails, the server may recover the client's locks when the associated leases have expired. Conflicting locks from another client may only be granted after this lease expiration. If the client is able to restart or reinitialize within the lease period the client may be forced to wait the remainder of the lease period before obtaining new locks.
関連するリースが期限切れになったときに、クライアントに障害が発生した場合には、サーバはクライアントのロックを回復することができます。別のクライアントから競合するロックにのみ、このリース満了後に付与することができます。クライアントは、リース期間内に再起動するか、再初期化することが可能である場合、クライアントは新しいロックを取得する前に、リース期間の残りを待つことを余儀なくされることがあります。
To minimize client delay upon restart, lock requests are associated with an instance of the client by a client supplied verifier. This verifier is part of the initial SETCLIENTID call made by the client. The server returns a clientid as a result of the SETCLIENTID operation. The client then confirms the use of the verifier with SETCLIENTID_CONFIRM. The clientid in combination with an opaque owner field is then used by the client to identify the lock owner for OPEN. This chain of associations is then used to identify all locks for a particular client.
再起動時にクライアントの遅延を最小限に抑えるために、ロック要求は、クライアント供給検証することにより、クライアントのインスタンスに関連付けられています。この検証では、クライアントによって行われた最初のSETCLIENTID呼び出しの一部です。サーバーは、SETCLIENTID操作の結果としてのClientIDを返します。次に、クライアントは、SETCLIENTID_CONFIRMでの検証を使用することを確認します。不透明な所有者フィールドとの組み合わせでのClientIDは、OPENのためのロック所有者を識別するために、クライアントによって使用されます。団体のこのチェーンは、特定のクライアントのすべてのロックを識別するために使用されます。
Since the verifier will be changed by the client upon each initialization, the server can compare a new verifier to the verifier associated with currently held locks and determine that they do not match. This signifies the client's new instantiation and subsequent loss of locking state. As a result, the server is free to release all locks held which are associated with the old clientid which was derived from the old verifier.
検証は、各初期化時にクライアントによって変更されますので、サーバーは現在保持しているロックに関連した検証者に新しい検証を比較し、一致していないと判断することができます。これは、クライアントの新しいインスタンス化し、ロック状態のその後の損失を意味します。その結果、サーバは古い検証から得られた古いのClientIDに関連付けられて保持されているすべてのロックを解放して自由です。
For secure environments, a change in the verifier must only cause the release of locks associated with the authenticated requester. This is required to prevent a rogue entity from freeing otherwise valid locks.
セキュアな環境では、検証の変化は、認証要求者に関連付けられているロックの解放を引き起こす必要があります。これは、そうでない場合は、有効なロックを解放からの不正なエンティティを防止するために必要とされます。
Note that the verifier must have the same uniqueness properties of the verifier for the COMMIT operation.
検証は、COMMIT操作のための検証の同じ一意性の性質を持っている必要があることに注意してください。
If the server loses locking state (usually as a result of a restart or reboot), it must allow clients time to discover this fact and re-establish the lost locking state. The client must be able to re-establish the locking state without having the server deny valid requests because the server has granted conflicting access to another client. Likewise, if there is the possibility that clients have not yet re-established their locking state for a file, the server must disallow READ and WRITE operations for that file. The duration of this recovery period is equal to the duration of the lease period.
サーバーが（通常は再起動または再起動の結果として）状態をロック失った場合、それはクライアントの時間がこの事実を発見し、失われたロック状態を再確立することを許可する必要があります。クライアントは、サーバーが他のクライアントへのアクセスが競合付与しているため、サーバーは有効な要求を拒否せずにロック状態を再確立することができなければなりません。クライアントがまだファイルのために彼らのロック状態を再確立していない可能性がある場合同様に、サーバはREADを禁止し、そのファイルの操作を記述する必要があります。この回復期間の長さは、リース期間の長さに等しいです。
A client can determine that server failure (and thus loss of locking state) has occurred, when it receives one of two errors. The NFS4ERR_STALE_STATEID error indicates a stateid invalidated by a reboot or restart. The NFS4ERR_STALE_CLIENTID error indicates a clientid invalidated by reboot or restart. When either of these are received, the client must establish a new clientid (See the section "Client ID") and re-establish the locking state as discussed below.
クライアントは、それが2つのエラーのいずれかを受信した場合、そのサーバの障害（及び状態をロックする、したがって損失）が発生したかを決定することができます。 NFS4ERR_STALE_STATEIDエラーがリブートまたは再起動によって無効たstateidを示しています。 NFS4ERR_STALE_CLIENTIDエラーがリブートまたは再起動によって無効化のClientIDを示しています。これらのいずれかを受信したときに以下に説明するように、クライアントは新しいのclientid（セクション「クライアントID」を参照してください）と再確立ロック状態を確立する必要があります。
The period of special handling of locking and READs and WRITEs, equal in duration to the lease period, is referred to as the "grace period". During the grace period, clients recover locks and the associated state by reclaim-type locking requests (i.e. LOCK requests with reclaim set to true and OPEN operations with a claim type of CLAIM_PREVIOUS). During the grace period, the server must reject READ and WRITE operations and non-reclaim locking requests (i.e. other LOCK and OPEN operations) with an error of NFS4ERR_GRACE.
リース期間の持続時間が等しいロックおよび読み取りおよび書き込みの特別な処理の期間は、「猶予期間」と呼びます。猶予期間中、クライアントは再利用型のロック要求（CLAIM_PREVIOUSのクレームの種類と真とOPEN操作に設定され再利用と、すなわちロック要求）によってロックと関連した状態を回復します。猶予期間中、サーバはREADを拒絶しなければならず、NFS4ERR_GRACEのエラーで動作し、非再利用ロック要求（すなわち、他のLOCKとOPEN操作）を書き込みます。
If the server can reliably determine that granting a non-reclaim request will not conflict with reclamation of locks by other clients, the NFS4ERR_GRACE error does not have to be returned and the non-reclaim client request can be serviced. For the server to be able to service READ and WRITE operations during the grace period, it must again be able to guarantee that no possible conflict could arise between an impending reclaim locking request and the READ or WRITE operation. If the server is unable to offer that guarantee, the NFS4ERR_GRACE error must be returned to the client.
サーバが確実に非再利用要求を許可すると、他のクライアントによるロックの再生と競合しないだろうと判断できる場合は、NFS4ERR_GRACEエラーが返されると、非再利用のクライアント要求をサービスすることができていません。サーバが猶予期間中に読み取りおよび書き込み操作にサービスを提供できるようにするには、再び何の可能性競合が要求およびREADまたはWRITE操作をロックする差し迫った再利用の間で発生することができなかったことを保証することができなければなりません。サーバがその保証を提供することができない場合は、NFS4ERR_GRACEエラーがクライアントに返さなければなりません。
For a server to provide simple, valid handling during the grace period, the easiest method is to simply reject all non-reclaim locking requests and READ and WRITE operations by returning the NFS4ERR_GRACE error. However, a server may keep information about granted locks in stable storage. With this information, the server could determine if a regular lock or READ or WRITE operation can be safely processed.
サーバが猶予期間中に、単純な、有効な処理を提供するために、最も簡単な方法は、単純にNFS4ERR_GRACEエラーを返すことによって、要求とREADとWRITE操作をロックするすべての非再利用を拒否することです。ただし、サーバーは安定したストレージに付与されたロックに関する情報を保持することができます。通常のロックまたはREADまたはWRITE操作を安全に処理できる場合は、この情報を使用して、サーバが決定することができます。
For example, if a count of locks on a given file is available in stable storage, the server can track reclaimed locks for the file and when all reclaims have been processed, non-reclaim locking requests may be processed. This way the server can ensure that non-reclaim locking requests will not conflict with potential reclaim requests. With respect to I/O requests, if the server is able to determine that there are no outstanding reclaim requests for a file by information from stable storage or another similar mechanism, the processing of I/O requests could proceed normally for the file.
たとえば、指定したファイルのロックのカウントが安定したストレージに利用可能な場合、サーバーは、ファイルのロックを埋め立て追跡することができ、すべてを再要求が処理されたとき、非再利用ロック要求を処理することができます。この方法では、サーバーは、非再利用ロック要求は、潜在的な再利用の要求と競合しないことを確実にすることができます。 I / O要求に対して、サーバが安定したストレージまたは他の同様の機構からの情報により、ファイルに対する未処理の再利用の要求が存在しないことを決定することができるならば、I / O要求の処理は、ファイルを正常に進行できました。
To reiterate, for a server that allows non-reclaim lock and I/O requests to be processed during the grace period, it MUST determine that no lock subsequently reclaimed will be rejected and that no lock subsequently reclaimed would have prevented any I/O operation processed during the grace period.
猶予期間中に処理するために、非再利用ロックおよびI / O要求を可能にするサーバに対して、繰り返しに、それはその後埋め立て何のロックが拒否されないことを決定する必要があり、その後、埋め立て何のロックは任意のI / O操作を妨げないだろうということ猶予期間中に処理。
Clients should be prepared for the return of NFS4ERR_GRACE errors for non-reclaim lock and I/O requests. In this case the client should employ a retry mechanism for the request. A delay (on the order of several seconds) between retries should be used to avoid overwhelming the server. Further discussion of the general is included in
クライアントは、非再利用のためのロックNFS4ERR_GRACEエラーのリターンのために準備し、I / O要求されなければなりません。この場合、クライアントは、要求の再試行メカニズムを採用する必要があります。再試行の間（数秒程度）の遅延は、サーバーを圧倒回避するために使用する必要があります。一般のさらなる議論はに含まれています
[Floyd]. The client must account for the server that is able to perform I/O and non-reclaim locking requests within the grace period as well as those that can not do so.
[フロイド]。クライアントがそうすることができないものだけでなく、猶予期間内にI / Oと非再利用ロック要求を行うことが可能であるサーバーを考慮に入れなければなりません。
A reclaim-type locking request outside the server's grace period can only succeed if the server can guarantee that no conflicting lock or I/O request has been granted since reboot or restart.
サーバが競合するロックまたはI / O要求を再起動や再起動してから付与されていないことを保証することができた場合、サーバーの猶予期間外の再利用型のロック要求にのみ成功することができます。
If the duration of a network partition is greater than the lease period provided by the server, the server will have not received a lease renewal from the client. If this occurs, the server may free all locks held for the client. As a result, all stateids held by the client will become invalid or stale. Once the client is able to reach the server after such a network partition, all I/O submitted by the client with the now invalid stateids will fail with the server returning the error NFS4ERR_EXPIRED. Once this error is received, the client will suitably notify the application that held the lock.
ネットワークパーティションの期間は、サーバーが提供するリース期間よりも大きい場合、サーバはクライアントからのリースの更新を受け取っていないだろう。この問題が発生した場合、サーバはクライアントのために開催されたすべてのロックを解放することがあります。その結果、クライアントが保持しているすべてのstateidsが無効または古くなります。クライアントは、そのようなネットワークパーティションの後にサーバーにアクセスできるようになると、すべてのIエラーNFS4ERR_EXPIREDを返すサーバーで失敗します今無効のstateidsでクライアントによって提出/ O。このエラーが受信されると、クライアントは、適切にロックを保持するアプリケーションに通知します。
As a courtesy to the client or as an optimization, the server may continue to hold locks on behalf of a client for which recent communication has extended beyond the lease period. If the server receives a lock or I/O request that conflicts with one of these courtesy locks, the server must free the courtesy lock and grant the new request.
クライアントへの礼儀として、または最適化として、サーバは、最近の通信は、リース期間を超えて延長していたために、クライアントに代わってロックを保持し続けることができます。サーバはこれらの礼儀ロックの一つと競合するロックまたはI / O要求を受信した場合、サーバは礼儀ロックを解放し、新しい要求を付与する必要があります。
If the server continues to hold locks beyond the expiration of a client's lease, the server MUST employ a method of recording this fact in its stable storage. Conflicting locks requests from another client may be serviced after the lease expiration. There are various scenarios involving server failure after such an event that require the storage of these lease expirations or network partitions. One scenario is as follows:
サーバーがクライアントのリースの期限を超えてロックを保持し続けた場合、サーバーは、その安定したストレージにこの事実を記録する方法を採用しなければなりません。別のクライアントから競合するロック要求は、リース満了後にサービスされます。これらのリース満了またはネットワーク・パーティションのストレージを必要とし、このようなイベントの後、サーバーの障害を含む様々なシナリオがあります。次のように1つのシナリオは次のとおりです。
A client holds a lock at the server and encounters a network
partition and is unable to renew the associated lease. A
second client obtains a conflicting lock and then frees the
lock. After the unlock request by the second client, the
server reboots or reinitializes. Once the server recovers, the
network partition heals and the original client attempts to
reclaim the original lock.
In this scenario and without any state information, the server will allow the reclaim and the client will be in an inconsistent state because the server or the client has no knowledge of the conflicting lock.
このシナリオでは、あらゆる状態情報なしに、サーバーは再利用を可能にし、サーバーまたはクライアントが競合ロックの知識を持たないため、クライアントは、一貫性のない状態になります。
The server may choose to store this lease expiration or network partitioning state in a way that will only identify the client as a whole. Note that this may potentially lead to lock reclaims being denied unnecessarily because of a mix of conflicting and non-conflicting locks. The server may also choose to store information about each lock that has an expired lease with an associated conflicting lock. The choice of the amount and type of state information that is stored is left to the implementor. In any case, the server must have enough state information to enable correct recovery from multiple partitions and multiple server failures.
サーバは、全体として、クライアントを識別します方法でこのリース期間満了またはネットワーク分割状態を保存することもできます。潜在的にロックにつながる可能性があり、これがあるため、競合と競合しないロックのミックスを不必要に拒否されて再利用することに注意してください。また、サーバは、関連する競合ロック付き期限切れのリースを持っているそれぞれのロックについての情報を保存することもできます。格納された状態情報の量及び種類の選択は実装者に任されています。いずれの場合も、サーバーは複数のパーティションと複数のサーバーの障害からの正しい回復を可能にするために十分な状態情報を持っている必要があります。
In the event a lock request times out, a client may decide to not retry the request. The client may also abort the request when the process for which it was issued is terminated (e.g. in UNIX due to a signal. It is possible though that the server received the request and acted upon it. This would change the state on the server without the client being aware of the change. It is paramount that the client re-synchronize state with server before it attempts any other operation that takes a seqid and/or a stateid with the same nfs_lockowner. This is straightforward to do without a special re-synchronize operation.
ロック要求がタイムアウトする場合には、クライアントが要求を再試行しないことを決定することができます。それが発行されたプロセスが終了すると、クライアントにも起因する信号にUNIXで例えば（要求を中止することがあります。サーバーが要求を受信し、それに作用することをけれどもそれは可能である。これはせずに、サーバー上の状態を変更しますクライアントが変更を認識している。同じnfs_lockownerの持つSEQIDおよび/またはたstateidをとり、他の操作を試みる前に、クライアントがサーバーとの状態を再同期させることを最優先事項である。これは、特別な再なしで行うことは簡単です操作を同期させます。
Since the server maintains the last lock request and response received on the nfs_lockowner, for each nfs_lockowner, the client should cache the last lock request it sent such that the lock request did not receive a response. From this, the next time the client does a lock operation for the nfs_lockowner, it can send the cached request, if there is one, and if the request was one that established state (e.g. a LOCK or OPEN operation) the client can follow up with a request to remove the state (e.g. a LOCKU or CLOSE operation). With this approach, the sequencing and stateid information on the client and server for the given nfs_lockowner will re-synchronize and in turn the lock state will re-synchronize.
サーバはnfs_lockownerの上で受け取った最後のロック要求と応答を維持するので、各nfs_lockownerのために、クライアントは、それがロック要求が応答を受信しないように送られた最後のロック要求をキャッシュする必要があります。要求は、状態（例えばLOCKまたはOPEN操作）を設立しました1だった場合は、このことから、クライアントはnfs_lockownerのためのロック操作を行い、次回は、それは、クライアントがフォローアップすることができます1が存在する場合、キャッシュされたリクエストを送信し、することができます状態を削除するための要求（例えばLOCKUまたはCLOSE操作）を持ちます。このアプローチでは、与えられたnfs_lockownerのために、クライアントとサーバー上のシーケンシングとのstateid情報は再同期と順番になりますロック状態は、同期を再します。
At any point, the server can revoke locks held by a client and the client must be prepared for this event. When the client detects that its locks have been or may have been revoked, the client is responsible for validating the state information between itself and the server. Validating locking state for the client means that it must verify or reclaim state for each lock currently held.
任意の時点で、サーバは、クライアントが保持しているロックを取り消すことができますし、クライアントは、このイベントのために準備しなければなりません。クライアントは、そのロックがされているか、取り消されたことを検出すると、クライアントは、それ自体とサーバの間で状態情報を検証する責任があります。クライアントのロック状態を検証することは、現在開催され、各ロックの状態を確認したり、再利用しなければならないことを意味します。
The first instance of lock revocation is upon server reboot or re-initialization. In this instance the client will receive an error (NFS4ERR_STALE_STATEID or NFS4ERR_STALE_CLIENTID) and the client will proceed with normal crash recovery as described in the previous section.
ロック失効の最初のインスタンスは、サーバの再起動または再初期化時です。この場合、クライアントは、エラー（NFS4ERR_STALE_STATEID又はNFS4ERR_STALE_CLIENTID）を受信すると、前のセクションで説明したように、クライアントは、通常のクラッシュ・リカバリを続行します。
The second lock revocation event is the inability to renew the lease period. While this is considered a rare or unusual event, the client must be prepared to recover. Both the server and client will be able to detect the failure to renew the lease and are capable of recovering without data corruption. For the server, it tracks the last renewal event serviced for the client and knows when the lease will expire. Similarly, the client must track operations which will renew the lease period. Using the time that each such request was sent and the time that the corresponding reply was received, the client should bound the time that the corresponding renewal could have occurred on the server and thus determine if it is possible that a lease period expiration could have occurred.
第2ロック失効イベントは、リース期間を更新することができないことです。これは稀なまたは異常なイベントと見なされますが、クライアントが回復する準備をしなければなりません。サーバとクライアントの両方がリースを更新し、データの破損せずに回復することができるに失敗したことを検出することができます。サーバーの場合は、クライアントのためにサービスを最後に更新イベントを追跡し、リースが期限切れになる知っています。同様に、クライアントは、リース期間を更新されます操作を追跡する必要があります。それぞれのそのようなリクエストが送信された時刻と対応する応答が受信された時刻を使用して、クライアントは、対応する更新がサーバー上で発生したので、リース期間の満了が発生している可能性があるかどうかを判断していることができると時間をバインドする必要があり。
The third lock revocation event can occur as a result of administrative intervention within the lease period. While this is considered a rare event, it is possible that the server's administrator has decided to release or revoke a particular lock held by the client. As a result of revocation, the client will receive an error of NFS4ERR_EXPIRED and the error is received within the lease period for the lock. In this instance the client may assume that only the nfs_lockowner's locks have been lost. The client notifies the lock holder appropriately. The client may not assume the lease period has been renewed as a result of failed operation.
第三のロック失効イベントがリース期間内に管理者の介入の結果として起こり得ます。これはまれなイベントと見なされているが、サーバーの管理者がクライアントによって保持された特定のロックを解除するか、取り消すことを決めている可能性があります。取り消しの結果、クライアントはNFS4ERR_EXPIREDのエラーが表示され、エラーはロックのリース期間内に受信されます。この例では、クライアントは、唯一のnfs_lockownerのロックが失われていると仮定してよいです。クライアントは、適切にロックホルダを通知します。リース期間を想定していないことがあり、クライアントは、失敗した操作の結果としてリニューアルしました。
When the client determines the lease period may have expired, the client must mark all locks held for the associated lease as "unvalidated". This means the client has been unable to re-establish or confirm the appropriate lock state with the server. As described in the previous section on crash recovery, there are scenarios in which the server may grant conflicting locks after the lease period has expired for a client. When it is possible that the lease period has expired, the client must validate each lock currently held to ensure that a conflicting lock has not been granted. The client may accomplish this task by issuing an I/O request, either a pending I/O or a zero-length read, specifying the stateid associated with the lock in question. If the response to the request is success, the client has validated all of the locks governed by that stateid and re-established the appropriate state between itself and the server. If the I/O request is not successful, then one or more of the locks associated with the stateid was revoked by the server and the client must notify the owner.
クライアントは、リース期間が満了したかもしれないと判断した場合、クライアントは「未検証」として関連付けられたリースのために開催されたすべてのロックをマークする必要があります。これは、クライアントがサーバーとの適切なロック状態を再確立または確認することができなかったことを意味します。クラッシュリカバリの前のセクションで説明したように、リース期間は、クライアントのために有効期限が切れた後に、サーバーが競合するロックを与える可能性のあるシナリオがあります。それは、リース期間が終了している可能性がある場合は、クライアントは各ロックを検証する必要があり、現在、競合するロックが付与されていないことを確認するために開催されました。クライアントは、当該ロックに関連付けられているのstateidを指定し、I / O要求、保留中のI / Oのいずれか、または長さゼロのリードを発行することにより、このタスクを達成することができます。要求に対する応答が成功の場合、クライアントはそののstateidに支配し、自分自身とサーバの間の適切な状態を再確立ロックのすべてを検証しました。 I / O要求が成功しなかった場合、その後のstateidに関連付けられているロックの一つ以上は、サーバとクライアントによって取り消された所有者に通知しなければなりません。
A share reservation is a mechanism to control access to a file. It is a separate and independent mechanism from record locking. When a client opens a file, it issues an OPEN operation to the server specifying the type of access required (READ, WRITE, or BOTH) and the type of access to deny others (deny NONE, READ, WRITE, or BOTH). If the OPEN fails the client will fail the application's open request.
シェア予約は、ファイルへのアクセスを制御するメカニズムです。これは、レコードロックとは別の独立した機構です。クライアントがファイルを開くと、それは（NONEは、読み取り、書き込みしない、拒否、またはBOTH）他者を否定するために必要なアクセスの種類（読み取り、書き込み、またはその両方）とアクセスの種類を指定してサーバにOPEN操作を発行します。 OPENが失敗した場合、クライアントは、アプリケーションのオープン要求を失敗します。
Pseudo-code definition of the semantics:
セマンティクスの擬似コードの定義：
if ((request.access & file_state.deny)) ||
(request.deny & file_state.access))
return (NFS4ERR_DENIED)
The constants used for the OPEN and OPEN_DOWNGRADE operations for the access and deny fields are as follows:
次のようにアクセスするためにOPENとOPEN_DOWNGRADE操作に使用してフィールドを否定する定数は、次のとおりです。
const OPEN4_SHARE_ACCESS_READ = 0x00000001;
const OPEN4_SHARE_ACCESS_WRITE = 0x00000002;
const OPEN4_SHARE_ACCESS_BOTH = 0x00000003;
const OPEN4_SHARE_DENY_NONE = 0x00000000;
const OPEN4_SHARE_DENY_READ = 0x00000001;
const OPEN4_SHARE_DENY_WRITE = 0x00000002;
const OPEN4_SHARE_DENY_BOTH = 0x00000003;
To provide correct share semantics, a client MUST use the OPEN operation to obtain the initial filehandle and indicate the desired access and what if any access to deny. Even if the client intends to use a stateid of all 0's or all 1's, it must still obtain the filehandle for the regular file with the OPEN operation so the appropriate share semantics can be applied. For clients that do not have a deny mode built into their open programming interfaces, deny equal to NONE should be used.
正しい共有セマンティクスを提供するために、クライアントは、最初のファイルハンドルを取得するためにOPEN操作を使用し、すべてのアクセスを拒否するならば所望のアクセスと何を示さなければなりません。クライアントがすべて0またはすべて1つのののstateidを使用しようとする場合であっても、適切な共有のセマンティクスを適用することができますので、それはまだOPEN操作で通常のファイルのためのファイルハンドルを取得する必要があります。彼らのオープンプログラミングインターフェースに組み込まれて拒否モードを持っていないクライアントの場合、使用されるべきであるNONEに等しい拒否。
The OPEN operation with the CREATE flag, also subsumes the CREATE operation for regular files as used in previous versions of the NFS protocol. This allows a create with a share to be done atomically.
CREATEフラグをOPEN操作は、また、NFSプロトコルの旧バージョンで使用される通常のファイルのCREATE操作を包含する。これはアトミックに行われるシェアで作成できます。
The CLOSE operation removes all share locks held by the nfs_lockowner on that file. If record locks are held, the client SHOULD release all locks before issuing a CLOSE. The server MAY free all outstanding locks on CLOSE but some servers may not support the CLOSE of a file that still has record locks held. The server MUST return failure if any locks would exist after the CLOSE.
CLOSE操作は、そのファイル上のnfs_lockownerが保有するすべての共有ロックを削除します。レコードロックが保持されている場合、クライアントはCLOSEを発行する前に、すべてのロックを解除しなければなりません。サーバーは、CLOSE上のすべての未解決のロックを解放するかもしれませんが、いくつかのサーバは、まだ開催されたレコードロックを持っているファイルのCLOSEをサポートしていないかもしれません。すべてのロックは、CLOSEの後に存在するならば、サーバーは失敗を返さなければなりません。
The LOOKUP operation will return a filehandle without establishing any lock state on the server. Without a valid stateid, the server will assume the client has the least access. For example, a file opened with deny READ/WRITE cannot be accessed using a filehandle obtained through LOOKUP because it would not have a valid stateid (i.e. using a stateid of all bits 0 or all bits 1).
LOOKUP操作は、サーバー上の任意のロック状態を確立することなくファイルハンドルを返します。有効なstateidがなければ、サーバーは、クライアントが少なくともアクセス権を持っていると仮定します。例えば、ファイルは、それが有効なのstateidを持たないため（すなわち、すべてのビット0または全ビット1のstateidを使用して）LOOKUPにより得られたファイルハンドルを使用してアクセスすることができない拒否READ / WRITEで開きます。
When an OPEN is done for a file and the lockowner for which the open is being done already has the file open, the result is to upgrade the open file status maintained on the server to include the access and deny bits specified by the new OPEN as well as those for the existing OPEN. The result is that there is one open file, as far as the protocol is concerned, and it includes the union of the access and deny bits for all of the OPEN requests completed. Only a single CLOSE will be done to reset the effects of both OPEN's. Note that the client, when issuing the OPEN, may not know that the same file is in fact being opened. The above only applies if both OPEN's result in the OPEN'ed object being designated by the same filehandle.
OPENは、ファイルのオープンはまだ行ってファイルを開いているされているためlockownerのために行われた場合、その結果は、新しいOPENで指定されたビットへのアクセスを含めると拒否するようにサーバー上に保持開いているファイルのステータスをアップグレードすることですうまく既存のOPENのものとして。結果は限りプロトコルに関しては、1つの開いているファイルがあることであり、それはアクセスの組合を含んでおり、完成OPENすべての要求のためのビットを否定します。つだけCLOSEは、両方のOPENの効果をリセットするために行われます。 OPENを発行するとき、クライアントは、同じファイルが実際に開かれていることを知らないかもしれないことに注意してください。 OPEN'edオブジェクトの両方のOPENの結果が同じファイルハンドルで指定されている場合は、上記にのみ適用されます。
When the server chooses to export multiple filehandles corresponding to the same file object and returns different filehandles on two different OPEN's of the same file object, the server MUST NOT "OR" together the access and deny bits and coalesce the two open files. Instead the server must maintain separate OPEN's with separate stateid's and will require separate CLOSE's to free them.
サーバーは、同じファイルオブジェクトに対応する複数のファイルハンドルをエクスポートすることを選択した2つの異なるOPENの同じファイルオブジェクトの上の異なるファイルハンドルを返し、サーバーはMUST NOT「OR」一緒にアクセスをしてビットを否定し、2つの開いているファイルを結合する場合。代わりに、サーバは別のOPENの独立したstateidのとを維持しなければならないし、それらを解放するために別々のCLOSEのが必要になります。
When multiple open files on the client are merged into a single open file object on the server, the close of one of the open files (on the client) may necessitate change of the access and deny status of the open file on the server. This is because the union of the access and deny bits for the remaining open's may be smaller (i.e. a proper subset) than previously. The OPEN_DOWNGRADE operation is used to make the necessary change and the client should use it to update the server so that share reservation requests by other clients are handled properly.
クライアント上の複数の開いているファイルを、サーバー上の単一のオープンファイルオブジェクトにマージされている場合、（クライアント上）開いているファイルの一つの近くには、アクセスの変更を必要とし、サーバー上の開いているファイルの状態を拒否することができます。アクセスの組合が、以前よりも小さくてもよい（すなわち、適切なサブセット）を残りの開放のためのビットを否定するためです。 OPEN_DOWNGRADE操作が必要な変更を行うために使用され、他のクライアントがその共有の予約要求が適切に処理されているように、クライアントはサーバーを更新するためにそれを使用する必要があります。
When determining the time period for the server lease, the usual lease tradeoffs apply. Short leases are good for fast server recovery at a cost of increased RENEW or READ (with zero length) requests. Longer leases are certainly kinder and gentler to large internet servers trying to handle very large numbers of clients. The number of RENEW requests drop in proportion to the lease time. The disadvantages of long leases are slower recovery after server failure (server must wait for leases to expire and grace period before granting new lock requests) and increased file contention (if client fails to transmit an unlock request then server must wait for lease expiration before granting new locks).
サーバーのリース期間を決定する際に、通常の賃貸借トレードオフが適用されます。短いリースは（ゼロ長さ）RENEW増加またはREAD要求のコストで高速なサーバー回復のために良いです。長いリースは、クライアントの非常に大きな数字を扱うしようとしている大規模なインターネットサーバーへの確かに親切と穏やかなです。 RENEW要求の数は、リース時間に比例してドロップします。長いリースの欠点は、（新しいロック要求を許可する前に期限切れにリースおよび猶予期間を待つ必要がありますサーバー）サーバーの障害が発生した後に遅い回復と増加したファイルの競合（クライアントがアンロック要求を送信するために失敗した場合、サーバ許可する前に、リース満了を待たなければならないです新しいロック）。
Long leases are usable if the server is able to store lease state in non-volatile memory. Upon recovery, the server can reconstruct the lease state from its non-volatile memory and continue operation with its clients and therefore long leases are not an issue.
サーバーは、不揮発性メモリにリース状態を記憶することが可能であるならばロングリースが使用可能です。回復時に、サーバーは、その不揮発性メモリからリース状態を再構築することができ、そのクライアントで動作を継続し、そのため長いリースは問題ではありません。
To avoid the need for synchronized clocks, lease times are granted by the server as a time delta. However, there is a requirement that the client and server clocks do not drift excessively over the duration of the lock. There is also the issue of propagation delay across the network which could easily be several hundred milliseconds as well as the possibility that requests will be lost and need to be retransmitted.
同期クロックの必要性を回避するには、リース時間は時間デルタとしてサーバによって付与されます。ただし、クライアントとサーバーのクロックがロックの期間にわたって過度にドリフトしていない要件があります。簡単に数百ミリ秒だけでなく、要求が失われ、再送信する必要があります可能性可能性があり、ネットワーク全体の伝播遅延の問題もあります。
To take propagation delay into account, the client should subtract it from lease times (e.g. if the client estimates the one-way propagation delay as 200 msec, then it can assume that the lease is already 200 msec old when it gets it). In addition, it will take another 200 msec to get a response back to the server. So the client must send a lock renewal or write data back to the server 400 msec before the lease would expire.
アカウントに伝播遅延を取るために、クライアントはリース時間（クライアントが200ミリ秒として一方向の伝搬遅延を推定した場合、例えば、それは、それはそれを取得するとき、リースがすでに200ミリ秒古いであると仮定することができる）からそれを差し引く必要があります。また、それは戻って、サーバへの応答を取得するには、別の200ミリ秒かかります。リースが期限切れになるでしょう前に400ミリ秒だから、クライアントは、ロックの更新を送信しなければならないか、サーバーに戻ってデータを書き込みます。
When responsibility for handling a given file system is transferred to a new server (migration) or the client chooses to use an alternate server (e.g. in response to server unresponsiveness) in the context of file system replication, the appropriate handling of state shared between the client and server (i.e. locks, leases, stateid's, and clientid's) is as described below. The handling differs between migration and replication. For related discussion of file server state and recover of such see the sections under "File Locking and Share Reservations"
特定のファイルシステムを処理するための責任は、新しいサーバー（マイグレーション）に転送されるか、またはクライアントが代替サーバーを使用することを選択した場合（例えば、サーバ不応答に応答して）ファイルシステムレプリケーションの文脈において、状態の適切な取り扱いは間で共有しました後述のように、クライアントとサーバは（すなわちロック、リース、のstateid年代、とのClientIDの）です。取り扱いは、移行と複製の間で異なっています。ファイルサーバの状態の関連議論についてと下のセクションを参照してください。「ファイルロックや予約の共有」などの回復
In the case of migration, the servers involved in the migration of a file system SHOULD transfer all server state from the original to the new server. This must be done in a way that is transparent to the client. This state transfer will ease the client's transition when a file system migration occurs. If the servers are successful in transferring all state, the client will continue to use stateid's assigned by the original server. Therefore the new server must recognize these stateid's as valid. This holds true for the clientid as well. Since responsibility for an entire file system is transferred with a migration event, there is no possibility that conflicts will arise on the new server as a result of the transfer of locks.
移行の場合には、ファイルシステムの移行に関係するサーバーは、元から新しいサーバーにすべてのサーバーの状態を転送する必要があります。これは、クライアントに透過的な方法で行う必要があります。ファイルシステムの移行が発生したときに、この状態転送は、クライアントの移行を容易にします。サーバはすべての状態を転送することに成功している場合、クライアントはのstateidの元のサーバーによって割り当てを使用し続けます。したがって、新しいサーバーは有効なものとしてこれらのstateid年代を認識しなければなりません。これは、同様のclientidにも当てはまります。ファイルシステム全体の責任が移行イベントで転送されているので、競合はロックの転送の結果として、新しいサーバ上で生じてしまうおそれはありません。
As part of the transfer of information between servers, leases would be transferred as well. The leases being transferred to the new server will typically have a different expiration time from those for the same client, previously on the new server. To maintain the property that all leases on a given server for a given client expire at the same time, the server should advance the expiration time to the later of the leases being transferred or the leases already present. This allows the client to maintain lease renewal of both classes without special effort.
サーバ間の情報の転送の一部として、リースは同様に転送されます。新しいサーバーに転送されているリースは、通常、以前に新しいサーバーで、同じクライアントのためのものとは異なる有効期限を持っています。与えられたクライアントのために特定のサーバー上のすべてのリースが同時に期限切れに財産を維持するために、サーバーが転送されているリース、または既に存在リースの後のに有効期限を進める必要があります。これにより、クライアントは、特別な努力なしで両方のクラスのリース更新を維持することができます。
The servers may choose not to transfer the state information upon migration. However, this choice is discouraged. In this case, when the client presents state information from the original server, the client must be prepared to receive either NFS4ERR_STALE_CLIENTID or NFS4ERR_STALE_STATEID from the new server. The client should then recover its state information as it normally would in response to a server failure. The new server must take care to allow for the recovery of state information as it would in the event of server restart.
サーバは、移行時に状態情報を転送しないこともできます。しかし、この選択はお勧めしません。クライアントは、元のサーバーからの状態情報を提示すると、この場合、クライアントは、新しいサーバーからNFS4ERR_STALE_CLIENTIDまたはNFS4ERR_STALE_STATEIDのいずれかを受け取ることを準備する必要があります。それは通常、サーバーの障害に応じて同じように、クライアントは、その状態情報を復元する必要があります。新しいサーバーは、サーバーの再起動のイベントと同じように状態情報の復旧を可能にするように注意する必要があります。
Since client switch-over in the case of replication is not under server control, the handling of state is different. In this case, leases, stateid's and clientid's do not have validity across a transition from one server to another. The client must re-establish its locks on the new server. This can be compared to the re-establishment of locks by means of reclaim-type requests after a server reboot. The difference is that the server has no provision to distinguish requests reclaiming locks from those obtaining new locks or to defer the latter. Thus, a client re-establishing a lock on the new server (by means of a LOCK or OPEN request), may have the requests denied due to a conflicting lock. Since replication is intended for read-only use of filesystems, such denial of locks should not pose large difficulties in practice. When an attempt to re-establish a lock on a new server is denied, the client should treat the situation as if his original lock had been revoked.
複製の場合のクライアントスイッチオーバーは、サーバーの管理下にはないので、状態の取り扱いが異なっています。この場合、リースは、のstateidのとのClientIDの1つのサーバーから別への移行全体の妥当性を持っていません。クライアントは、新しいサーバー上のロックを再確立する必要があります。これは、サーバの再起動後に再利用型リクエストによってロックの再確立と比較することができます。違いは、サーバーがそれらの取得新しいロックからロックを再利用要求を区別するか、後者を延期することを想定していませんということです。このように、クライアントの再確立新しいサーバーのロックを（LOCKまたはOPENのリクエストによる）は、競合ロックが原因で拒否されたリクエストを有することができます。レプリケーションがファイルシステムの読み取り専用の使用を意図しているので、ロックのように否定は実際には大きな困難をもたらすべきではありません。新しいサーバーにロックを再確立しようとする試みが拒否された場合には、彼のオリジナルロックが取り消されたかのように、クライアントは状況を扱うべきです。
In the case of lease renewal, the client may not be submitting requests for a file system that has been migrated to another server. This can occur because of the implicit lease renewal mechanism. The client renews leases for all file systems when submitting a request to any one file system at the server.
リース更新の場合、クライアントは別のサーバに移行されたファイルシステムに対する要求を提出することはできません。これは、暗黙のリース更新機構から発生する可能性があります。サーバーのいずれかのファイルシステムに要求を提出するとき、クライアントは、すべてのファイルシステムのためのリースを更新します。
In order for the client to schedule renewal of leases that may have been relocated to the new server, the client must find out about lease relocation before those leases expire. To accomplish this, all operations which implicitly renew leases for a client (i.e. OPEN, CLOSE, READ, WRITE, RENEW, LOCK, LOCKT, LOCKU), will return the error NFS4ERR_LEASE_MOVED if responsibility for any of the leases to be renewed has been transferred to a new server. This condition will continue until the client receives an NFS4ERR_MOVED error and the server receives the subsequent GETATTR(fs_locations) for an access to each file system for which a lease has been moved to a new server.
これらのリース期限が切れる前に新しいサーバーに移転されている可能性がリースの更新をスケジュールするクライアントのために、クライアントは、リースの再配置を知る必要があります。更新するリースのいずれかの責任が転送された場合は、これを達成するために、暗黙的にクライアントのリースを更新するすべての操作は、（すなわちOPEN、CLOSE、READ、WRITE、RENEW、LOCK、LOCKT、LOCKU）は、エラーNFS4ERR_LEASE_MOVEDを返します。新しいサーバへ。クライアントがNFS4ERR_MOVEDエラーを受信して、サーバがリースを新しいサーバーに移動された各ファイルシステムにアクセスするために、その後のGETATTR（fs_位置）を受信するまで、この状態が継続されます。
When a client receives an NFS4ERR_LEASE_MOVED error, it should perform some operation, such as a RENEW, on each file system associated with the server in question. When the client receives an NFS4ERR_MOVED error, the client can follow the normal process to obtain the new server information (through the fs_locations attribute) and perform renewal of those leases on the new server. If the server has not had state transferred to it transparently, it will receive either NFS4ERR_STALE_CLIENTID or NFS4ERR_STALE_STATEID from the new server, as described above, and can then recover state information as it does in the event of server failure.
クライアントがNFS4ERR_LEASE_MOVEDエラーを受信した場合、そのような問題のサーバーに関連付けられている各ファイルシステム上で、RENEWとして、いくつかの操作を実行する必要があります。クライアントがNFS4ERR_MOVEDエラーを受信した場合、クライアントは、（fs_位置の属性で）新しいサーバーの情報を取得するために、通常のプロセスに従うと、新しいサーバー上のリースの更新を行うことができます。サーバは状態が透過的に転送されなかった場合は、上記のように、新しいサーバーからNFS4ERR_STALE_CLIENTIDまたはNFS4ERR_STALE_STATEIDのいずれかを受け取ることになります、そしてそれは、サーバーに障害が発生した場合に行うように、状態情報を復元することができます。
Client-side caching of data, of file attributes, and of file names is essential to providing good performance with the NFS protocol. Providing distributed cache coherence is a difficult problem and previous versions of the NFS protocol have not attempted it. Instead, several NFS client implementation techniques have been used to reduce the problems that a lack of coherence poses for users. These techniques have not been clearly defined by earlier protocol specifications and it is often unclear what is valid or invalid client behavior.
ファイル属性の、およびファイル名のデータのクライアント側のキャッシュは、NFSプロトコルとの良好なパフォーマンスを提供するために不可欠です。分散キャッシュの一貫性を提供することは難しい問題であり、NFSプロトコルの以前のバージョンではそれをしようとしていません。代わりに、いくつかのNFSクライアントの実装技術は、一貫性の欠如は、ユーザーのためのポーズの問題を軽減するために使用されています。これらの技術は明らかに以前のプロトコル仕様で定義されていない、有効か無効クライアントの動作が何であるかを、多くの場合不明です。
The NFS version 4 protocol uses many techniques similar to those that have been used in previous protocol versions. The NFS version 4 protocol does not provide distributed cache coherence. However, it defines a more limited set of caching guarantees to allow locks and share reservations to be used without destructive interference from client side caching.
NFSバージョン4プロトコルは、以前のプロトコル・バージョンで使用されたものと同様の多くの技術を使用します。 NFSバージョン4プロトコルは、分散キャッシュの一貫性を提供していません。しかし、ロックと共有の予約がクライアント側のキャッシュからの破壊的干渉なしに使用することができるようにキャッシング保証のより限定されたセットを定義します。
In addition, the NFS version 4 protocol introduces a delegation mechanism which allows many decisions normally made by the server to be made locally by clients. This mechanism provides efficient support of the common cases where sharing is infrequent or where sharing is read-only.
また、NFSバージョン4プロトコルは、通常はサーバーによって行われた多くの決定は、クライアントによってローカルで行うことを可能にする委譲メカニズムを導入しています。この機構は、共有がまれであるか、または共有が読み取り専用である場合に一般的なケースの効率的なサポートを提供します。
Caching techniques used in previous versions of the NFS protocol have been successful in providing good performance. However, several scalability challenges can arise when those techniques are used with very large numbers of clients. This is particularly true when clients are geographically distributed which classically increases the latency for cache revalidation requests.
NFSプロトコルの以前のバージョンで使用されるキャッシュ技術は、優れた性能を提供することに成功しています。これらの技術は、クライアントの非常に大きな数字で使用されている場合しかし、いくつかのスケーラビリティの問題が発生する可能性があります。これは、クライアントが地理的に古典的にキャッシュ再検証要求のための待ち時間を増加させる分散している場合は特にそうです。
The previous versions of the NFS protocol repeat their file data cache validation requests at the time the file is opened. This behavior can have serious performance drawbacks. A common case is one in which a file is only accessed by a single client. Therefore, sharing is infrequent.
NFSプロトコルの以前のバージョンでは、ファイルが開かれた時にそのファイルのデータ・キャッシュの検証要求を繰り返します。この動作は、パフォーマンスに重大な欠点を持つことができます。一般的なケースでは、ファイルは、単一のクライアントがアクセスしたものです。そのため、共有はまれです。
In this case, repeated reference to the server to find that no conflicts exist is expensive. A better option with regards to performance is to allow a client that repeatedly opens a file to do so without reference to the server. This is done until potentially conflicting operations from another client actually occur.
この場合、競合が存在しないことを見つけるために、サーバへの反復参照は高価です。パフォーマンスに関してとのより良いオプションは、繰り返し、サーバーを参照することなくこれを行うには、ファイルを開くクライアントをできるようにすることです。別のクライアントからの潜在的な競合の操作が実際に発生するまで、これが行われます。
A similar situation arises in connection with file locking. Sending file lock and unlock requests to the server as well as the read and write requests necessary to make data caching consistent with the locking semantics (see the section "Data Caching and File Locking") can severely limit performance. When locking is used to provide protection against infrequent conflicts, a large penalty is incurred. This penalty may discourage the use of file locking by applications.
同様の状況は、ファイルのロックに関連して発生します。ファイルロックを送信すると、パフォーマンスが大幅に制限することができ、サーバーへの要求だけでなく、読み取りロックを解除し、データがロックセマンティクス（節参照「データキャッシングとロックファイル」）と一致キャッシングさせるために必要な要求を記述します。ロックがまれ衝突に対する保護を提供するために使用される場合、大きなペナルティが発生しています。このペナルティはアプリケーションによるファイルロックの使用を阻止します。
The NFS version 4 protocol provides more aggressive caching strategies with the following design goals:
NFSバージョン4プロトコルは、次の設計目標をより積極的なキャッシング戦略を提供します。
o Compatibility with a large range of server semantics.
サーバーのセマンティクスの大規模な範囲でのOの互換性。
o Provide the same caching benefits as previous versions of the NFS protocol when unable to provide the more aggressive model.
Oより積極的なモデルを提供することができませんでしNFSプロトコルの以前のバージョンと同じキャッシングの利点を提供します。
o Requirements for aggressive caching are organized so that a large portion of the benefit can be obtained even when not all of the requirements can be met.
利益の大部分は、要件のすべてを満たすことができない場合でも得られるように、積極的なキャッシュ用のO要件が整理されています。
The appropriate requirements for the server are discussed in later sections in which specific forms of caching are covered. (see the section "Open Delegation").
サーバのための適切な要件は、キャッシュの特定の形態は、被覆された後のセクションに記載されています。 （セクション「オープン委譲」を参照してください）。
Recallable delegation of server responsibilities for a file to a client improves performance by avoiding repeated requests to the server in the absence of inter-client conflict. With the use of a "callback" RPC from server to client, a server recalls delegated responsibilities when another client engages in sharing of a delegated file.
クライアントへのファイルのサーバー責任のリコール代表団は、クライアント間の競合が存在しない場合に、サーバーへの再三の要求を回避することによって、パフォーマンスが向上します。別のクライアントが委任ファイルの共有に従事したときに、サーバーからクライアントへの「コールバック」RPCを使用すると、サーバーは、委任の責任を思い出します。
A delegation is passed from the server to the client, specifying the object of the delegation and the type of delegation. There are different types of delegations but each type contains a stateid to be used to represent the delegation when performing operations that depend on the delegation. This stateid is similar to those associated with locks and share reservations but differs in that the stateid for a delegation is associated with a clientid and may be used on behalf of all the nfs_lockowners for the given client. A delegation is made to the client as a whole and not to any specific process or thread of control within it.
委任は、委任の対象と委任の種類を指定して、サーバからクライアントに渡されます。そこ代表団の異なるタイプがあるが、それぞれのタイプには、代表団に依存する操作を実行する場合、委任を表すために使用されるのstateidが含まれています。これのstateidはロックとシェアの予約に関連したものと同様であるが、代表団のためのstateidはClientIDが関連付けられ、特定のクライアントのためのすべてのnfs_lockownersに代わって使用することができるという点で異なります。代表団は、全体としてではなく、特定のプロセスやその内のコントロールのスレッドに、クライアントに行われます。
Because callback RPCs may not work in all environments (due to firewalls, for example), correct protocol operation does not depend on them. Preliminary testing of callback functionality by means of a CB_NULL procedure determines whether callbacks can be supported. The CB_NULL procedure checks the continuity of the callback path. A server makes a preliminary assessment of callback availability to a given client and avoids delegating responsibilities until it has determined that callbacks are supported. Because the granting of a delegation is always conditional upon the absence of conflicting access, clients must not assume that a delegation will be granted and they must always be prepared for OPENs to be processed without any delegations being granted.
コールバックRPCが（例えば、原因ファイアウォールに）すべての環境で動作しない場合がありますので、正しいプロトコル動作は、それらに依存しません。 CB_NULL手順によって、コールバック機能の予備試験は、コールバックをサポートできるかどうかを決定します。 CB_NULL手順は、コールバック・パスの連続性をチェックします。サーバーは、特定のクライアントへのコールバックの可用性の予備的な評価を行い、それがコールバックがサポートされていると判断するまで、責任を委譲することを回避します。代表団の付与は、常に競合アクセスの不在時に条件付きであるため、クライアントは、代表団が付与されると、彼らは常に許可されている任意の代表団ずに処理されるために開くために準備しなければならないと仮定してはいけません。
Once granted, a delegation behaves in most ways like a lock. There is an associated lease that is subject to renewal together with all of the other leases held by that client.
付与された後は、代表団は、ロックのように、ほとんどの方法で動作します。そのクライアントが保有する他のリースのすべてと一緒に更新の対象となる関連したリースがあります。
Unlike locks, an operation by a second client to a delegated file will cause the server to recall a delegation through a callback.
ロックとは異なり、委任ファイルへの2番目のクライアントによる操作は、サーバーがコールバックを通じて委任をリコールするようになります。
On recall, the client holding the delegation must flush modified state (such as modified data) to the server and return the delegation. The conflicting request will not receive a response until the recall is complete. The recall is considered complete when the client returns the delegation or the server times out on the recall and revokes the delegation as a result of the timeout. Following the resolution of the recall, the server has the information necessary to grant or deny the second client's request.
リコールでは、委任を保持しているクライアントは、サーバに（例えば修正されたデータなど）変更された状態をフラッシュし、委任を返す必要があります。リコールが完了するまで、相反する要求が応答を受信しません。クライアントがリコールに委任またはサーバーがタイムアウトを返し、タイムアウトの結果として委任を取り消したときにリコールが完了したと見なされます。リコールの解決に続いて、サーバーは、第二のクライアントの要求を許可または拒否するために必要な情報を持っています。
At the time the client receives a delegation recall, it may have substantial state that needs to be flushed to the server. Therefore, the server should allow sufficient time for the delegation to be returned since it may involve numerous RPCs to the server. If the server is able to determine that the client is diligently flushing state to the server as a result of the recall, the server may extend the usual time allowed for a recall. However, the time allowed for recall completion should not be unbounded.
クライアントが委譲リコールを受ける時には、それがサーバーにフラッシュする必要がかなりの状態を有することができます。そのため、サーバーは、サーバーに多数のRPCを含むことができるので、返される委譲のための十分な時間を許可する必要があります。サーバは、クライアントが熱心にリコールの結果としてサーバーに状態をフラッシュしていることを決定することができる場合は、サーバーはリコールのために許可される通常の時間を延長することができます。しかし、リコール完了に許される時間は無制限ではありません。
An example of this is when responsibility to mediate opens on a given file is delegated to a client (see the section "Open Delegation"). The server will not know what opens are in effect on the client. Without this knowledge the server will be unable to determine if the access and deny state for the file allows any particular open until the delegation for the file has been returned.
仲介する責任が与えられたファイルに開いたときに、この例では（セクション「オープン委譲」を参照）、クライアントに委譲されています。開いたのか分からなくなり、サーバーは、クライアントに適用されています。この知識がないと、サーバーは、ファイルの委譲が返されるまでの任意の特定のオープンできるアクセスかどうかを判断し、ファイルの状態を否定することはできません。
A client failure or a network partition can result in failure to respond to a recall callback. In this case, the server will revoke the delegation which in turn will render useless any modified state still on the client.
クライアント障害またはネットワークパーティションは、リコールコールバックに応答する障害が発生することができます。この場合、サーバは、順番に、クライアント上ではまだ役に立たない任意の変更された状態をレンダリングする委任を取り消します。
There are three situations that delegation recovery must deal with:
代表団の回復が対処しなければならないことの3つの状況があります。
o Client reboot or restart
oクライアントの再起動または再起動
o Server reboot or restart
Oサーバの再起動や再起動
o Network partition (full or callback-only)
Oネットワークパーティション（フルまたはコールバックのみ）
In the event the client reboots or restarts, the failure to renew leases will result in the revocation of record locks and share reservations. Delegations, however, may be treated a bit differently.
イベントでは、クライアントの再起動や再起動、リースの更新に失敗するとレコードロックと共有の予約の取り消しになります。代表団は、しかし、異なるビットを処理することができます。
There will be situations in which delegations will need to be reestablished after a client reboots or restarts. The reason for this is the client may have file data stored locally and this data was associated with the previously held delegations. The client will need to reestablish the appropriate file state on the server.
代表団は、クライアントの再起動や再起動後に再確立する必要がある状況があります。この理由は、クライアントがローカルに保存されたファイルデータを持っていることであり、このデータは、以前開催された代表団と関連していました。クライアントは、サーバ上の適切なファイルの状態を再確立する必要があります。
To allow for this type of client recovery, the server may extend the period for delegation recovery beyond the typical lease expiration period. This implies that requests from other clients that conflict with these delegations will need to wait. Because the normal recall process may require significant time for the client to flush changed state to the server, other clients need be prepared for delays that occur because of a conflicting delegation. This longer interval would increase the window for clients to reboot and consult stable storage so that the delegations can be reclaimed. For open delegations, such delegations are reclaimed using OPEN with a claim type of CLAIM_DELEGATE_PREV. (see the sections on "Data Caching and Revocation" and "Operation 18: OPEN" for discussion of open delegation and the details of OPEN respectively).
クライアントの回復のこのタイプを可能にするため、サーバーは、一般的なリースの有効期限を越えた委任回復のための期間を延長することができます。これは、他のクライアントからの要求は、これらの代表団と競合を待つ必要があることを意味します。クライアントがサーバに変更された状態をフラッシュするために、通常のリコール処理はかなりの時間が必要な場合がありますので、他のクライアントがあるため、競合する代表団の発生の遅れのために準備される必要があります。この長い間隔は代表団を再利用できるように、安定した記憶装置を再起動して相談するクライアントのためのウィンドウを増加させることになります。オープン委譲のために、そのような委任はCLAIM_DELEGATE_PREVのクレームタイプOPEN用いて再生されます。 （：それぞれ開いている委譲とOPENの詳細については、「データキャッシングと失効」と「OPENオペレーション18」のセクションを参照してください）。
When the server reboots or restarts, delegations are reclaimed (using the OPEN operation with CLAIM_DELEGATE_PREV) in a similar fashion to record locks and share reservations. However, there is a slight semantic difference. In the normal case if the server decides that a delegation should not be granted, it performs the requested action (e.g. OPEN) without granting any delegation. For reclaim, the server grants the delegation but a special designation is applied so that the client treats the delegation as having been granted but recalled by the server. Because of this, the client has the duty to write all modified state to the server and then return the delegation. This process of handling delegation reclaim reconciles three principles of the NFS Version 4 protocol:
サーバの再起動または再起動したときに、委任がロックと共有の予約を記録するために同様の方法で（CLAIM_DELEGATE_PREVで開く操作を使用して）再利用されます。しかし、わずかなセマンティック違いがあります。サーバは委任が許可されるべきではないと判断した場合、通常のケースでは、任意の委任を許可することなく、要求されたアクション（例えばOPEN）を行います。再利用のために、サーバが委任を許可しますが、クライアントがサーバによって付与されたが、リコールされたものとして委任を扱うように、特別な指定が適用されます。このため、クライアントは、サーバーへのすべての変更された状態を書き込み、委任を返す義務があります。委任再利用を扱うこのプロセスは、NFSバージョン4プロトコルの3つの原則を調和させます。
o Upon reclaim, a client reporting resources assigned to it by an earlier server instance must be granted those resources.
O再利用時には、以前のサーバインスタンスによってそれに割り当てられたリソースを報告するクライアントは、それらのリソースを付与する必要があります。
o The server has unquestionable authority to determine whether delegations are to be granted and, once granted, whether they are to be continued.
Oサーバは、代表団は、かつて彼らが継続するかどうか、付与された、許可されたとされるようにしているかどうかを判断するために疑う余地のない権限を有しています。
o The use of callbacks is not to be depended upon until the client has proven its ability to receive them.
クライアントがそれらを受信する能力を証明しているまで、Oコールバックの使用はないに依存することがあります。
When a network partition occurs, delegations are subject to freeing by the server when the lease renewal period expires. This is similar to the behavior for locks and share reservations. For delegations, however, the server may extend the period in which conflicting requests are held off. Eventually the occurrence of a conflicting request from another client will cause revocation of the delegation. A loss of the callback path (e.g. by later network configuration change) will have the same effect. A recall request will fail and revocation of the delegation will result.
ネットワークパーティションが発生した場合、代表団はリース更新期間が満了したときに、サーバによって解放の対象となっています。これは、ロックとシェアの予約のための動作に似ています。委譲のために、しかし、サーバは、競合する要求がオフに保持される期間を延長することができます。結局、別のクライアントから競合の要求の発生は委任の取消しの原因となります。 （例えば、後にネットワーク設定変更によって）コールバックパスの損失は、同じ効果を有するであろう。リコール要求は失敗し、代表団の失効が発生します。
A client normally finds out about revocation of a delegation when it uses a stateid associated with a delegation and receives the error NFS4ERR_EXPIRED. It also may find out about delegation revocation after a client reboot when it attempts to reclaim a delegation and receives that same error. Note that in the case of a revoked write open delegation, there are issues because data may have been modified by the client whose delegation is revoked and separately by other clients. See the section "Revocation Recovery for Write Open Delegation" for a discussion of such issues. Note also that when delegations are revoked, information about the revoked delegation will be written by the server to stable storage (as described in the section "Crash Recovery"). This is done to deal with the case in which a server reboots after revoking a delegation but before the client holding the revoked delegation is notified about the revocation.
それは代表団に関連付けられたstateidを使用すると、エラーNFS4ERR_EXPIREDを受信したときに、クライアントは通常、委任の取消しについて見つけ出します。それは代表団を再利用しようとすると、同じエラーを受信した場合も、クライアントの再起動後に委任失効について調べることがあります。データはその代表団、他のクライアントによって個別に無効化され、クライアントによって変更された可能性があるため、失効書き込みオープン委譲の場合には、問題があることに注意してください。そのような問題の議論については、「書き込みオープン委譲のための失効リカバリ」を参照してください。代表団が取り消されたときに（セクション「クラッシュリカバリ」で説明したように）、取り消された代表団についての情報が安定したストレージにサーバーによって書き込まれることにも注意してください。これは、サーバが委任を取り消した後が、取り消された代表団を保持しているクライアントが失効について通知される前に再起動した場合に対処するために行われます。
When applications share access to a set of files, they need to be implemented so as to take account of the possibility of conflicting access by another application. This is true whether the applications in question execute on different clients or reside on the same client.
ファイルのセットにアプリケーション共有アクセス、彼らは他のアプリケーションによるアクセスの競合の可能性を考慮するように実装する必要があります。これは、問題のアプリケーションは、異なるクライアント上で実行するか、同じクライアント上に存在するかどうか本当です。
Share reservations and record locks are the facilities the NFS version 4 protocol provides to allow applications to coordinate access by providing mutual exclusion facilities. The NFS version 4 protocol's data caching must be implemented such that it does not invalidate the assumptions that those using these facilities depend upon.
共有の予約とレコードロックは、NFSバージョン4プロトコルは、アプリケーションが相互排他設備を提供することによって、アクセスを調整できるようにするために提供する機能です。 NFSバージョン4プロトコルのデータのキャッシングは、これらの施設を利用したものが依存することを仮定を無効にしないように実装する必要があります。
In order to avoid invalidating the sharing assumptions that applications rely on, NFS version 4 clients should not provide cached data to applications or modify it on behalf of an application when it would not be valid to obtain or modify that same data via a READ or WRITE operation.
、アプリケーションが依存する共有の仮定を無効避けるためにNFSバージョン4つのクライアントは、アプリケーションにキャッシュされたデータを提供してはならないか、入手またはREADを経由して、同じデータを変更したり、書き込むには有効ではないだろうというとき、アプリケーションに代わって、それを修正します操作。
Furthermore, in the absence of open delegation (see the section "Open Delegation") two additional rules apply. Note that these rules are obeyed in practice by many NFS version 2 and version 3 clients.
さらに、開いている委譲が存在しない場合に二つの追加の規則が適用されます（セクション「オープン委譲」を参照してください）。これらのルールは、多くのNFSバージョン2とバージョン3つのクライアントが実際に守られることに注意してください。
o First, cached data present on a client must be revalidated after doing an OPEN. This is to ensure that the data for the OPENed file is still correctly reflected in the client's cache. This validation must be done at least when the client's OPEN operation includes DENY=WRITE or BOTH thus terminating a period in which other clients may have had the opportunity to open the file with WRITE access. Clients may choose to do the revalidation more often (i.e. at OPENs specifying DENY=NONE) to parallel the NFS version 3 protocol's practice for the benefit of users assuming this degree of cache revalidation.
Oまず、クライアント上に存在し、キャッシュされたデータは、OPENをやった後、再検証する必要があります。これは、開いたファイルのデータがまだ正しくクライアントのキャッシュに反映されていることを確認することです。この検証は、クライアントのOPEN操作は、このように他のクライアントが書き込みアクセスでファイルを開くための機会を持っていた可能性のある期間を終了= WRITEまたはBOTHをDENY、少なくとも時に行われなければなりません。クライアントはより頻繁に再検証を行うことを選択することができ（すなわちで開き指定= NONEを否定できない）キャッシュ再検証のこの程度を想定し、ユーザーの利益のためにNFSバージョン3プロトコルの練習を並行して。
o Second, modified data must be flushed to the server before closing a file OPENed for write. This is complementary to the first rule. If the data is not flushed at CLOSE, the revalidation done after client OPENs as file is unable to achieve its purpose. The other aspect to flushing the data before close is that the data must be committed to stable storage, at the server, before the CLOSE operation is requested by the client. In the case of a server reboot or restart and a CLOSEd file, it may not be possible to retransmit the data to be written to the file. Hence, this requirement.
O第二に、変更されたデータは、書き込みのために開いたファイルを閉じる前に、サーバーにフラッシュする必要があります。これは最初のルールに相補的です。データはCLOSEでフラッシュされていない場合は、クライアントがファイルとして開いた後に行う再検証は、その目的を達成することができません。クローズする前にデータをフラッシュする他の側面は、CLOSE操作がクライアントによって要求される前のデータは、サーバーで、安定したストレージにコミットしなければならないということです。サーバーの再起動または再起動し、閉じられたファイルの場合は、ファイルに書き込まれるデータを再送することはできないかもしれません。したがって、この要件。
For those applications that choose to use file locking instead of share reservations to exclude inconsistent file access, there is an analogous set of constraints that apply to client side data caching. These rules are effective only if the file locking is used in a way that matches in an equivalent way the actual READ and WRITE operations executed. This is as opposed to file locking that is based on pure convention. For example, it is possible to manipulate a two-megabyte file by dividing the file into two one-megabyte regions and protecting access to the two regions by file locks on bytes zero and one. A lock for write on byte zero of the file would represent the right to do READ and WRITE operations on the first region. A lock for write on byte one of the file would represent the right to do READ and WRITE operations on the second region. As long as all applications manipulating the file obey this convention, they will work on a local file system. However, they may not work with the NFS version 4 protocol unless clients refrain from data caching.
一貫性のないファイルへのアクセスを除外するために、代わりに株式の予約のファイルロックを使用することを選択し、それらのアプリケーションでは、クライアント側のデータキャッシュに適用される制約の類似したセットがあります。これらのルールは、ファイルのロックが実際の読み出しおよび書き込み動作が実行される同等の方法で一致するように使用されている場合にのみ有効です。純粋な慣例に基づいて、ロックファイルとは対照的にこれがあります。例えば、2つの1メガバイトの領域にファイルを分割し、バイト0と1上のファイルロックによって二つの領域へのアクセスを保護することにより、二メガバイトのファイルを操作することが可能です。ファイルのバイトゼロの書き込みのためのロックは、第1の領域に読み取りおよび書き込み操作を行う権利を表します。ファイルのバイト1の書き込みのためのロックは第二の領域に読み取りおよび書き込み操作を行う権利を表します。限り、ファイルを操作するすべてのアプリケーションがこの規則に従うように、彼らはローカルファイルシステム上で動作します。クライアントがデータ・キャッシングを控える場合を除きしかし、彼らは、NFSバージョン4プロトコルでは動作しない場合があります。
The rules for data caching in the file locking environment are:
ファイルロック環境でのデータのキャッシュのためのルールは以下のとおりです。
o First, when a client obtains a file lock for a particular region, the data cache corresponding to that region (if any cache data exists) must be revalidated. If the change attribute indicates that the file may have been updated since the cached data was obtained, the client must flush or invalidate the cached data for the newly locked region. A client might choose to invalidate all of non-modified cached data that it has for the file but the only requirement for correct operation is to invalidate all of the data in the newly locked region.
クライアントは、特定の領域のためのファイルのロックを取得した場合、Oまず、その領域に対応するデータキャッシュは、（任意のキャッシュデータが存在する場合）再検証されなければなりません。変化属性がキャッシュされたデータが得られたので、ファイルが更新された可能性があることを示している場合、クライアントは、新たにロックされた領域のためにキャッシュされたデータをフラッシュしたり無効化しなければなりません。クライアントは、ファイルのために持っていますが、正しく動作するための唯一の要件は、新たにロックされた領域内のすべてのデータを無効化するためにある非改変キャッシュされたデータのすべてを無効にすることを選択するかもしれません。
o Second, before releasing a write lock for a region, all modified data for that region must be flushed to the server. The modified data must also be written to stable storage.
O第二に、地域のために書き込みロックを解除する前に、その地域のすべての変更されたデータをサーバーにフラッシュする必要があります。変更されたデータはまた、安定したストレージに書き込む必要があります。
Note that flushing data to the server and the invalidation of cached data must reflect the actual byte ranges locked or unlocked. Rounding these up or down to reflect client cache block boundaries will cause problems if not carefully done. For example, writing a modified block when only half of that block is within an area being unlocked may cause invalid modification to the region outside the unlocked area. This, in turn, may be part of a region locked by another client. Clients can avoid this situation by synchronously performing portions of write operations that overlap that portion (initial or final) that is not a full block. Similarly, invalidating a locked area which is not an integral number of full buffer blocks would require the client to read one or two partial blocks from the server if the revalidation procedure shows that the data which the client possesses may not be valid.
サーバとキャッシュされたデータの無効化へデータをフラッシュすると、実際のバイト範囲ロックまたはロック解除を反映しなければならないことに注意してください。注意深く行われていない場合は、クライアントのキャッシュ・ブロックの境界を反映するためにダウンこれらを丸めたりすると、問題が発生します。例えば、修飾されたブロックを書き込むと、そのブロックの半分だけがロック解除された領域の外側の領域に、無効な変更を引き起こすことがアンロックされている領域内にある場合。これは、順番に、別のクライアントによってロックされた領域の一部であってもよいです。クライアントは同期満杯ブロックでない部分（初期または最終）を重複書き込み操作の一部を実行することによってこの状況を回避することができます。同様に、サーバーから一つまたは二つの部分ブロックを読み取るためにクライアントを必要とする完全なバッファブロックの整数倍ではないロックされた領域を無効にする再検証手順は、クライアントが保有するデータが有効ではないかもしれないことを示している場合。
The data that is written to the server as a pre-requisite to the unlocking of a region must be written, at the server, to stable storage. The client may accomplish this either with synchronous writes or by following asynchronous writes with a COMMIT operation. This is required because retransmission of the modified data after a server reboot might conflict with a lock held by another client.
領域の解除に前提条件としてサーバに書き込まれたデータは、安定したストレージに、サーバに書き込まれなければなりません。クライアントは同期書き込みまたはCOMMIT操作で非同期書き込みを、次のいずれかによって、これを達成することができます。サーバーの再起動後に変更されたデータの再送信は、別のクライアントによって保持されたロックと競合する可能性がありますので、これが必要です。
A client implementation may choose to accommodate applications which use record locking in non-standard ways (e.g. using a record lock as a global semaphore) by flushing to the server more data upon an LOCKU than is covered by the locked range. This may include modified data within files other than the one for which the unlocks are being done. In such cases, the client must not interfere with applications whose READs and WRITEs are being done only within the bounds of record locks which the application holds. For example, an application locks a single byte of a file and proceeds to write that single byte. A client that chose to handle a LOCKU by flushing all modified data to the server could validly write that single byte in response to an unrelated unlock. However, it would not be valid to write the entire block in which that single written byte was located since it includes an area that is not locked and might be locked by another client. Client implementations can avoid this problem by dividing files with modified data into those for which all modifications are done to areas covered by an appropriate record lock and those for which there are modifications not covered by a record lock. Any writes done for the former class of files must not include areas not locked and thus not modified on the client.
クライアントの実装では、サーバにロックされた範囲によってカバーされるよりもLOCKU際に多くのデータをフラッシュすることにより、非標準的な方法（例えば、グローバルセマフォとしてレコードロックを使用して）にレコードロックを使用するアプリケーションに対応することを選択することができます。これは、アンロックが行われているために1以外のファイル内で変更されたデータを含むことができます。このような場合には、クライアントは、その読み込みと書き込みのみアプリケーションが保持しているレコードロックの範囲内で行われているアプリケーションを妨害してはなりません。例えば、アプリケーションは、ファイルの単一のバイトをロックし、その単一バイトの書き込みに進みます。サーバーへのすべての変更されたデータをフラッシュしてLOCKUを処理するために選択したクライアントが有効に無関係なロック解除に応じて、その1バイトを書くことができます。しかし、ロックされていないと別のクライアントによってロックされるかもしれない領域を含むので、その単一書かれたバイトが配置されたブロック全体を書き込むことが有効ではありません。クライアントの実装は、すべての変更が適切なレコードロックとレコードロックでカバーされていない変更がありますそのため、それらによってカバーされる領域に行われているため、それらに変更されたデータを含むファイルを分割することによって、この問題を回避することができます。ファイルの元のクラスに行って、任意の書き込みは、領域がロックされていないため、クライアント上で変更されていない含めることはできません。
Client side data caching needs to respect mandatory file locking when it is in effect. The presence of mandatory file locking for a given file is indicated in the result flags for an OPEN. When mandatory locking is in effect for a file, the client must check for an appropriate file lock for data being read or written. If a lock exists for the range being read or written, the client may satisfy the request using the client's validated cache. If an appropriate file lock is not held for the range of the read or write, the read or write request must not be satisfied by the client's cache and the request must be sent to the server for processing. When a read or write request partially overlaps a locked region, the request should be subdivided into multiple pieces with each region (locked or not) treated appropriately.
クライアント側のデータキャッシュは、それが有効になっている場合は必須ファイルロックを尊重する必要があります。与えられたファイルのための必須のファイルのロックの存在は、OPENのために結果フラグで示されています。強制ロックは、ファイルのために有効である場合には、クライアントが読み取りまたは書き込まれるデータのための適切なファイルロックを確認する必要があります。ロックが読み取りまたは書き込まれている範囲に存在する場合、クライアントは、クライアントの検証キャッシュを使用して要求を満たすようにしてもよいです。適切なファイルロックは、読み取りの範囲で保有または書き込み、読み取りまたは書き込み要求されていない場合は、クライアントのキャッシュによって満たされなければならないと要求を処理するためにサーバーに送信する必要があります。読み取りまたは書き込み要求が部分的にロックされた領域と重なる場合、要求が適切に処理（ロックされたかどうか）は、各領域を有する複数の部分に細分されるべきです。
When clients cache data, the file data needs to organized according to the file system object to which the data belongs. For NFS version 3 clients, the typical practice has been to assume for the purpose of caching that distinct filehandles represent distinct file system objects. The client then has the choice to organize and maintain the data cache on this basis.
クライアントがデータをキャッシュすると、ファイルデータは、データが属するファイル・システム・オブジェクトに従って整理する必要があります。 NFSバージョン3つのクライアントの場合、典型的な練習は、異なるファイルハンドルが別個のファイル・システム・オブジェクトを表すキャッシングの目的のために仮定することでした。その後、クライアントはこれに基づいてデータキャッシュを整理し、維持するための選択肢を持っています。
In the NFS version 4 protocol, there is now the possibility to have significant deviations from a "one filehandle per object" model because a filehandle may be constructed on the basis of the object's pathname. Therefore, clients need a reliable method to determine if two filehandles designate the same file system object. If clients were simply to assume that all distinct filehandles denote distinct objects and proceed to do data caching on this basis, caching inconsistencies would arise between the distinct client side objects which mapped to the same server side object.
ファイルハンドルは、オブジェクトのパス名に基づいて構築することができるので、NFSバージョン4プロトコルでは、「一のファイルハンドルオブジェクトごとに」モデルから有意な偏差を持っている可能性が今あります。したがって、クライアントは、二つのファイルハンドルが同じファイル・システム・オブジェクトを指定する場合に信頼性の高い方法を決定する必要があります。クライアントは単純にすべての個別のファイルハンドルが別個のオブジェクトを表すことを前提とし、これに基づいてデータのキャッシュを行うに進みした場合、キャッシュの不整合は、同じサーバー側オブジェクトにマッピングされた個別のクライアント側のオブジェクト間で生じるであろう。
By providing a method to differentiate filehandles, the NFS version 4 protocol alleviates a potential functional regression in comparison with the NFS version 3 protocol. Without this method, caching inconsistencies within the same client could occur and this has not been present in previous versions of the NFS protocol. Note that it is possible to have such inconsistencies with applications executing on multiple clients but that is not the issue being addressed here.
ファイルハンドルを区別するための方法を提供することによって、NFSバージョン4プロトコルは、NFSバージョン3プロトコルと比較して潜在的な機能的回帰を緩和します。この方法がなければ、同じクライアント内のキャッシュの不整合が発生する可能性があり、これは、NFSプロトコルの以前のバージョンに存在していませんでした。複数のクライアント上で実行されるアプリケーションと、そのような矛盾を持つことが可能であるが、それはここで扱われている問題ではないことに注意してください。
For the purposes of data caching, the following steps allow an NFS version 4 client to determine whether two distinct filehandles denote the same server side object: o If GETATTR directed to two filehandles have different values of the fsid attribute, then the filehandles represent distinct objects.
GETATTRは、2つのファイルハンドルに向けた場合FSID属性の異なる値を有するO、次にファイルハンドルが別個のオブジェクトを表す：データキャッシュの目的のために、次のステップは、2つの別個のファイルハンドルは、同じサーバー側のオブジェクトを表すかどうかを決定するためにNFSバージョン4クライアントを許可します。
o If GETATTR for any file with an fsid that matches the fsid of the two filehandles in question returns a unique_handles attribute with a value of TRUE, then the two objects are distinct.
問題の2つのファイルハンドルのFSIDと一致するFSIDを持つ任意のファイルのGETATTRがunique_handlesがTRUEの値を持つ属性を返した場合、O、その後、2つのオブジェクトが異なっています。
o If GETATTR directed to the two filehandles does not return the fileid attribute for one or both of the handles, then the it cannot be determined whether the two objects are the same. Therefore, operations which depend on that knowledge (e.g. client side data caching) cannot be done reliably.
O GETATTRは、2つのファイルハンドルに向かう場合は、1つ又はハンドルの両方にFILEID属性を返さない、2つのオブジェクトが同一であるか否かを判断することはできません。したがって、その知識（例えばクライアント側のデータキャッシュ）に依存する操作を確実に行うことができません。
o If GETATTR directed to the two filehandles returns different values for the fileid attribute, then they are distinct objects.
GETATTRは、2つのファイルハンドルに向けFILEID属性の異なる値を返す場合、O、それらは別個のオブジェクトです。
o Otherwise they are the same object.
Oそれ以外の場合は、同じオブジェクトです。
When a file is being OPENed, the server may delegate further handling of opens and closes for that file to the opening client. Any such delegation is recallable, since the circumstances that allowed for the delegation are subject to change. In particular, the server may receive a conflicting OPEN from another client, the server must recall the delegation before deciding whether the OPEN from the other client may be granted. Making a delegation is up to the server and clients should not assume that any particular OPEN either will or will not result in an open delegation. The following is a typical set of conditions that servers might use in deciding whether OPEN should be delegated:
ファイルが開かれている場合は、サーバーがオープンのさらなる取り扱いを委任し、開口部クライアントにそのファイルを閉じて。委任に対して許可状況が変更される場合がありますので、任意のそのような委任は、リコールです。特に、サーバは別のクライアントから競合OPENを受けることができる、サーバーは他のクライアントからのOPENを付与することができるかどうかを決定する前に委任を思い出す必要があります。委任を作ることはどちらかのいずれかの特定のOPENがまたは開いている委譲にはなりませんだろうと想定してはならない、サーバーとクライアント次第です。以下は、サーバーがOPENを委任する必要があるかどうかを決定する際に使用する可能性のある条件の典型的なセットです。
o The client must be able to respond to the server's callback requests. The server will use the CB_NULL procedure for a test of callback ability.
Oクライアントは、サーバーのコールバック要求に応答できなければなりません。サーバーは、コールバック機能のテストのためにCB_NULLプロシージャを使用します。
o The client must have responded properly to previous recalls.
Oクライアントは、以前のリコールに適切に対応している必要があります。
o There must be no current open conflicting with the requested delegation.
O要求された代表団とは、現在開いている矛盾があってはいけません。
o There should be no current delegation that conflicts with the delegation being requested.
O委任が要求されていると競合するどんな現在の代表団があってはなりません。
o The probability of future conflicting open requests should be low based on the recent history of the file.
Oオープン要求が競合し、将来の確率が低いファイルの最近の履歴に基づくべきです。
o The existence of any server-specific semantics of OPEN/CLOSE that would make the required handling incompatible with the prescribed handling that the delegated client would apply (see below).
必要な規定の委任クライアントが適用されることを扱うと互換性の取り扱いになるだろうOPEN / CLOSEの任意のサーバ固有の意味の存在O（下記参照）。
There are two types of open delegations, read and write. A read open delegation allows a client to handle, on its own, requests to open a file for reading that do not deny read access to others. Multiple read open delegations may be outstanding simultaneously and do not conflict. A write open delegation allows the client to handle, on its own, all opens. Only one write open delegation may exist for a given file at a given time and it is inconsistent with any read open delegations.
オープン委譲の2種類、読み取りと書き込みがあります。読んで開いている委譲は、他人への読み取りアクセスを拒否していない読書のためのファイルを開くには、独自の、要求に、クライアントが処理することができます。複数の読み取りオープンの代表団が同時に優れたことと競合しないことがあります。書き込みオープン委譲が独自に、クライアントが処理することができ、すべてが表示されます。一つだけの書き込みオープン委譲は、与えられた時間に指定したファイルの存在する可能性があり、それはどの読んオープン委譲と矛盾しています。
When a client has a read open delegation, it may not make any changes to the contents or attributes of the file but it is assured that no other client may do so. When a client has a write open delegation, it may modify the file data since no other client will be accessing the file's data. The client holding a write delegation may only affect file attributes which are intimately connected with the file data: object_size, time_modify, change.
クライアントが読ん開いている委譲を持っている場合は、ファイルの内容や属性を変更しないかもしれないが、他のクライアントがそうしないことが保証されています。クライアントが書き込みオープン委譲を持っている場合は、他のクライアントがファイルのデータにアクセスできなくなりますので、ファイルのデータを変更することがあります。オブジェクト_、time_modify、変更：書き込み委託を保持しているクライアントは、密接にファイルデータに接続されているファイルの属性に影響を与える可能性があります。
When a client has an open delegation, it does not send OPENs or CLOSEs to the server but updates the appropriate status internally. For a read open delegation, opens that cannot be handled locally (opens for write or that deny read access) must be sent to the server.
クライアントが開いている委譲を持っているときは、サーバーに開閉するを送ったが、内部で適切なステータスを更新しません。読んで開いている委譲のために、それがサーバーに送信されなければならない（書き込みのために開くか、その読み拒否アクセス）ローカルで処理することができません開きます。
When an open delegation is made, the response to the OPEN contains an open delegation structure which specifies the following:
開いている委譲が行われると、OPENへの応答は次のように指定するオープン委譲構造が含まれています。
o the type of delegation (read or write)
代表団のタイプO（読み取りまたは書き込み）
o space limitation information to control flushing of data on close (write open delegation only, see the section "Open Delegation and Data Caching")
Oスペースの制限情報が近い上のデータのフラッシュを制御する（セクション「オープン委任やデータキャッシング」を参照してください、唯一のオープン委譲を書きます）
o an nfsace4 specifying read and write permissions
読み取りおよび書き込み権限を指定nfsace4 O
o a stateid to represent the delegation for READ and WRITE
OのstateidはREADとWRITEのための委任を表現します
The stateid is separate and distinct from the stateid for the OPEN proper. The standard stateid, unlike the delegation stateid, is associated with a particular nfs_lockowner and will continue to be valid after the delegation is recalled and the file remains open.
stateidはOPEN適切ためのstateidから独立した別個です。標準のstateidは、委任のstateidとは異なり、特定のnfs_lockownerに関連付けられており、委任がリコールされた後に有効であり続けるであろうと、ファイルは開いたままになります。
When a request internal to the client is made to open a file and open delegation is in effect, it will be accepted or rejected solely on the basis of the following conditions. Any requirement for other checks to be made by the delegate should result in open delegation being denied so that the checks can be made by the server itself.
クライアントへの内部要求がファイルを開くために作られ、開いている委譲が有効になっている場合、それは受け入れられたか、次の条件のみに基づいて拒否されます。チェックはサーバ自体によって行うことができるように、デリゲートによってなされる他のチェックのためにどのような要件が拒否され開いている委譲を生じるはずです。
o The access and deny bits for the request and the file as described in the section "Share Reservations".
アクセスoおよびセクション「共有予約」に記載されているように要求し、ファイルのビットを否定します。
o The read and write permissions as determined below.
読み取りおよび書き込み権限O以下決定されます。
The nfsace4 passed with delegation can be used to avoid frequent ACCESS calls. The permission check should be as follows:
代表団に渡さnfsace4は、頻繁にアクセス呼び出しを回避するために使用することができます。次のようにパーミッションチェックは次のようになります。
o If the nfsace4 indicates that the open may be done, then it should be granted without reference to the server.
O nfsace4は、それがサーバーを参照することなく付与されなければならない、オープンを行うことができることを示している場合。
o If the nfsace4 indicates that the open may not be done, then an ACCESS request must be sent to the server to obtain the definitive answer.
nfsace4がオープンが行われない可能性があることを示した場合は、O、その後、アクセス要求は、決定的な答えを得るために、サーバーに送信する必要があります。
The server may return an nfsace4 that is more restrictive than the actual ACL of the file. This includes an nfsace4 that specifies denial of all access. Note that some common practices such as mapping the traditional user "root" to the user "nobody" may make it incorrect to return the actual ACL of the file in the delegation response.
サーバーは、ファイルの実際のACLよりも制限さnfsace4を返すことがあります。これは、すべてのアクセスの拒否を指定nfsace4が含まれています。こうしたユーザー「誰」に伝統的なユーザー「root」をマッピングするなど、いくつかの一般的な慣行が、それは間違った委任応じて、ファイルの実際のACLを返すように作ることに注意してください。
The use of delegation together with various other forms of caching creates the possibility that no server authentication will ever be performed for a given user since all of the user's requests might be satisfied locally. Where the client is depending on the server for authentication, the client should be sure authentication occurs for each user by use of the ACCESS operation. This should be the case even if an ACCESS operation would not be required otherwise. As mentioned before, the server may enforce frequent authentication by returning an nfsace4 denying all access with every open delegation.
キャッシングの様々な他の形態と一緒に委任の使用は、ユーザーのすべての要求をローカルに満足されることがありますので、何のサーバ認証が今まで与えられたユーザのために実行されません可能性が作成されます。クライアントが認証のためのサーバに依存している場合は、クライアントは、認証がアクセス動作を使用することによって、ユーザーごとに発生したことを確認する必要があります。これは、アクセス動作がそうでなければ必要とされない場合でも同様である必要があります。前に述べたように、サーバーはすべての開いている委譲を持つすべてのアクセスを拒否nfsace4を返すことによって、頻繁に認証を強制することがあります。
OPEN delegation allows much of the message overhead associated with the opening and closing files to be eliminated. An open when an open delegation is in effect does not require that a validation message be sent to the server. The continued endurance of the "read open delegation" provides a guarantee that no OPEN for write and thus no write has occurred. Similarly, when closing a file opened for write and if write open delegation is in effect, the data written does not have to be flushed to the server until the open delegation is recalled. The continued endurance of the open delegation provides a guarantee that no open and thus no read or write has been done by another client.
OPEN代表団は、ファイルを開いたり閉じ関連付けられているメッセージオーバーヘッドの多くは解消することができます。開いている委譲が有効になっているオープンは、検証メッセージをサーバーに送信する必要はありません。 「読んで開いている委譲」の継続的な耐久性はありません書き込みのためOPENので、何の書き込みが発生していない保証を提供します。同様に閉じるときに、ファイルが書き込みのためにオープンし、書き込みオープン委譲が有効な場合、書き込まれたデータは、開いている委譲が呼び出されるまで、サーバーにフラッシュする必要はありません。開いている委譲の継続的な耐久性は、このようにオープンし、何の読み取りまたは書き込みまったく別のクライアントによって行われていないという保証を提供します。
For the purposes of open delegation, READs and WRITEs done without an OPEN are treated as the functional equivalents of a corresponding type of OPEN. This refers to the READs and WRITEs that use the special stateids consisting of all zero bits or all one bits. Therefore, READs or WRITEs with a special stateid done by another client will force the server to recall a write open delegation. A WRITE with a special stateid done by another client will force a recall of read open delegations.
オープン委譲の目的のために、読み取り、OPENなく行わ書き込みがOPENの対応するタイプの機能的等価物として扱われます。これは、読み取り、すべてのゼロのビット又は全て1個のビットからなる特別のstateidsを使用するのWRITEを指します。そのため、読み取りや書き込みオープン委譲を思い出すために、サーバーを強制的に別のクライアントによって行わ特別なstateidで書き込みます。別のクライアントによって行わ特別なstateidとのWRITEは読まオープン委譲のリコールを強制します。
With delegations, a client is able to avoid writing data to the server when the CLOSE of a file is serviced. The CLOSE operation is the usual point at which the client is notified of a lack of stable storage for the modified file data generated by the application. At the CLOSE, file data is written to the server and through normal accounting the server is able to determine if the available file system space for the data has been exceeded (i.e. server returns NFS4ERR_NOSPC or NFS4ERR_DQUOT). This accounting includes quotas. The introduction of delegations requires that a alternative method be in place for the same type of communication to occur between client and server.
代表団では、クライアントは、ファイルのCLOSEがサービスされているサーバへのデータの書き込みを避けることができます。 CLOSE操作は、クライアントがアプリケーションによって生成された変更されたファイルデータの保存安定性の不足が通知される通常のポイントです。 CLOSEでは、ファイルデータがサーバーに、データに利用可能なファイル・システム・スペースを超えているかどうかを判断することができるサーバを占め正常を通じて書き込まれる（すなわち、サーバはNFS4ERR_NOSPC又はNFS4ERR_DQUOT返します）。この会計は、クォータが含まれています。代表団の導入は、別の方法は、クライアントとサーバーの間で発生する通信の同じタイプのための場所であることが必要です。
In the delegation response, the server provides either the limit of the size of the file or the number of modified blocks and associated block size. The server must ensure that the client will be able to flush data to the server of a size equal to that provided in the original delegation. The server must make this assurance for all outstanding delegations. Therefore, the server must be careful in its management of available space for new or modified data taking into account available file system space and any applicable quotas. The server can recall delegations as a result of managing the available file system space. The client should abide by the server's state space limits for delegations. If the client exceeds the stated limits for the delegation, the server's behavior is undefined.
委任応答して、サーバは、ファイルまたは変更されたブロックの数と関連したブロックサイズの大きさの制限のいずれかを提供します。サーバーは、クライアントが、元代表団に提供されるものに等しいサイズのサーバにデータをフラッシュすることができるようになりますことを確認する必要があります。サーバーはすべての未処理の代表団のために、この保証をしなければなりません。そのため、サーバは、アカウントに使用可能なファイルシステムスペースおよび適用クォータを取って、新規または変更されたデータのために利用可能なスペースの経営で注意しなければなりません。サーバーは、使用可能なファイルシステム領域の管理の結果として、代表団を思い出すことができます。クライアントは、代表団のために、サーバの状態空間の制限を遵守しなければなりません。クライアントは、委譲のために述べた制限を超えた場合は、サーバーの動作は未定義です。
Based on server conditions, quotas or available file system space, the server may grant write open delegations with very restrictive space limitations. The limitations may be defined in a way that will always force modified data to be flushed to the server on close.
サーバーの状況、クォータまたは使用可能なファイル・システム・スペースに基づいて、サーバーは非常に制限容量の制限付きオープン委任を書く与えることができます。制限は、常に近くにサーバーにフラッシュされるように変更されたデータを強制する方法で定義することができます。
With respect to authentication, flushing modified data to the server after a CLOSE has occurred may be problematic. For example, the user of the application may have logged off of the client and unexpired authentication credentials may not be present. In this case, the client may need to take special care to ensure that local unexpired credentials will in fact be available. This may be accomplished by tracking the expiration time of credentials and flushing data well in advance of their expiration or by making private copies of credentials to assure their availability when needed.
認証に関しては、CLOSEが発生した後、サーバーに変更されたデータをフラッシュすることは問題となり得ます。たとえば、アプリケーションのユーザは、クライアントからログオフしていることと、有効期限内の認証資格情報は存在しないかもしれません。この場合、クライアントは、ローカルの期限が切れていない証明書が実際に利用可能になることを保証するために特別な注意を払う必要があるかもしれません。これは、資格証明書の有効期限を追跡し、その有効期限の事前にデータをフラッシュするか、必要なときに自分の可用性を保証するために資格のプライベートコピーを作成することによって達成することができます。
When a client holds a write open delegation, lock operations are performed locally. This includes those required for mandatory file locking. This can be done since the delegation implies that there can be no conflicting locks. Similarly, all of the revalidations that would normally be associated with obtaining locks and the flushing of data associated with the releasing of locks need not be done.
クライアントが書き込みオープン委譲を保持している場合は、ロック操作がローカルで実行されています。これは必須ファイルのロックに必要なものも含まれます。代表団は、競合するロックがないことを意味するので、これは行うことができます。同様に、通常は入手ロックとロックの解除に関連したデータのフラッシュに関連付けられる再確認のすべてが行われる必要がありません。
The following events necessitate recall of an open delegation:
次のイベントが開いている委譲のリコールを余儀なく：
o Potentially conflicting OPEN request (or READ/WRITE done with "special" stateid)
O潜在的OPEN要求（または "特別" なstateidで行わREAD / WRITE）を矛盾
o SETATTR issued by another client
O SETATTR別のクライアントによって発行されました
o REMOVE request for the file
ファイルに対する要求を削除するには
o RENAME request for the file as either source or target of the RENAME
O RENAMEのソースまたはターゲットとしてファイルの要求の名前を変更
Whether a RENAME of a directory in the path leading to the file results in recall of an open delegation depends on the semantics of the server file system. If that file system denies such RENAMEs when a file is open, the recall must be performed to determine whether the file in question is, in fact, open.
開いている委譲のリコールで、ファイルの結果につながるパス内のディレクトリのRENAMEかどうかは、サーバーのファイルシステムのセマンティクスに依存します。ファイルが開いているときに、そのファイル・システムは、このような名前に変更を拒否した場合、リコールは、問題のファイルは、実際には、開いているかどうかを決定するために行われなければなりません。
In addition to the situations above, the server may choose to recall open delegations at any time if resource constraints make it advisable to do so. Clients should always be prepared for the possibility of recall.
上記の状況に加えて、サーバは、リソースの制約がそうすることをお勧めします場合はいつでも開いている委任をリコールすることもできます。クライアントは常にリコールの可能性のために準備されるべきです。
The server needs to employ special handling for a GETATTR where the target is a file that has a write open delegation in effect. In this case, the client holding the delegation needs to be interrogated. The server will use a CB_GETATTR callback, if the GETATTR attribute bits include any of the attributes that a write open delegate may modify (object_size, time_modify, change).
サーバーは、ターゲットが有効な書き込みオープン委譲を持つファイルであるGETATTRのための特別な処理を採用する必要があります。この場合、委任を保持しているクライアントを尋問する必要があります。 GETATTRは、ビットは、書き込みオープンデリゲートは（オブジェクト_、time_modify、変更を）修正する可能性のある属性のいずれかを含む属性場合、サーバーは、CB_GETATTRコールバックを使用します。
When a client receives a recall for an open delegation, it needs to update state on the server before returning the delegation. These same updates must be done whenever a client chooses to return a delegation voluntarily. The following items of state need to be dealt with:
クライアントが開いている委譲のためのリコールを受信すると、それは代表団を返す前に、サーバー上での状態を更新する必要があります。これらの同じ更新は、クライアントが自発的に委任を返すことを選択したときに行われなければなりません。状態の以下の項目が扱われる必要があります。
o If the file associated with the delegation is no longer open and no previous CLOSE operation has been sent to the server, a CLOSE operation must be sent to the server.
代表団に関連付けられたファイルは、もはや開いていて、以前のCLOSE操作がサーバーに送信されていない場合は、O、CLOSE操作がサーバーに送信されませんする必要があります。
o If a file has other open references at the client, then OPEN operations must be sent to the server. The appropriate stateids will be provided by the server for subsequent use by the client since the delegation stateid will not longer be valid. These OPEN requests are done with the claim type of CLAIM_DELEGATE_CUR. This will allow the presentation of the delegation stateid so that the client can establish the appropriate rights to perform the OPEN. (see the section "Operation 18: OPEN" for details.)
ファイルがクライアントで開いている他の参照を持っている場合は、O、その後、OPEN操作はサーバに送信する必要があります。委任のstateidは、もはや有効ではありませんので、適切なのstateidsは、クライアントによって、その後の使用のために、サーバによって提供されます。これらのOPEN要求はCLAIM_DELEGATE_CURの請求タイプで行われます。クライアントがOPENを実行するための適切な権限を確立できるように、これは、委任のstateidのプレゼンテーションが可能になります。 （セクション「操作18：OPEN」を参照してください。詳細については、を）
o If there are granted file locks, the corresponding LOCK operations need to be performed. This applies to the write open delegation case only.
ファイルロックが付与されている場合は、O、対応するロック操作を実行する必要があります。これは、書き込みオープン委譲場合にのみ適用されます。
o For a write open delegation, if at the time of recall the file is not open for write, all modified data for the file must be flushed to the server. If the delegation had not existed, the client would have done this data flush before the CLOSE operation.
リコール時にファイルが書き込みのために開かれていない場合はO書き込みオープン委譲については、ファイルのすべての変更されたデータをサーバーにフラッシュする必要があります。代表団が存在していなかった場合、クライアントはCLOSE操作の前に、このデータフラッシュを行っているでしょう。
o For a write open delegation when a file is still open at the time of recall, any modified data for the file needs to be flushed to the server.
書き込みオープン委譲のためのOファイルはリコールの時にまだ開いている、ファイルの任意の変更されたデータをサーバーにフラッシュする必要があります。
o With the write open delegation in place, it is possible that the file was truncated during the duration of the delegation. For example, the truncation could have occurred as a result of an OPEN UNCHECKED with a object_size attribute value of zero. Therefore, if a truncation of the file has occurred and this operation has not been propagated to the server, the truncation must occur before any modified data is written to the server.
代わりに書き込みオープン委譲してO、ファイルが委任の期間中に切り捨てられた可能性があります。たとえば、切り捨てがゼロのオブジェクト_属性値を持つOPEN UNCHECKEDの結果として発生した可能性があります。ファイルの切り捨てが発生していると、この操作は、サーバーに伝播されていない場合、任意の変更されたデータがサーバーに書き込まれる前にそのため、切り捨てが行われなければなりません。
In the case of write open delegation, file locking imposes some additional requirements. The flushing of any modified data in any region for which a write lock was released while the write open delegation was in effect is what is required to precisely maintain the associated invariant. However, because the write open delegation implies no other locking by other clients, a simpler implementation is to flush all modified data for the file (as described just above) if any write lock has been released while the write open delegation was in effect.
書き込みオープン委譲の場合は、ファイルロックは、いくつかの追加の要件を課します。書き込みオープン委譲が有効であった間書き込みロックが解除されたために任意の領域の任意の変更されたデータのフラッシュは正確に関連する不変を維持するために必要とされるものです。書き込みオープン委譲は、他のクライアントが他のロックを意味しないためしかし、より簡単な実装は、（ちょうど上記のように）書き込みオープン委譲が有効であった任意の書き込みロックが解除された場合、ファイルのすべての変更されたデータをフラッシュすることです。
At the point a delegation is revoked, if there are associated opens on the client, the applications holding these opens need to be notified. This notification usually occurs by returning errors for READ/WRITE operations or when a close is attempted for the open file.
そこに関連付けられている場合時点で、委任がクライアントに開き、取り消され、これらを保持しているアプリケーションに通知する必要が開きます。この通知は、通常、READ / WRITE操作にエラーを返すとき、またはクローズが開いたファイルのためにしようとしていることによって起こります。
If no opens exist for the file at the point the delegation is revoked, then notification of the revocation is unnecessary. However, if there is modified data present at the client for the file, the user of the application should be notified. Unfortunately, it may not be possible to notify the user since active applications may not be present at the client. See the section "Revocation Recovery for Write Open Delegation" for additional details.
委任が取り消された時点でファイルの存在開いたいかなる場合は、取り消しの通知は不要ではありません。ファイルのクライアントで変更されたデータが存在した場合ただし、アプリケーションの利用者に通知しなければなりません。残念ながら、アクティブなアプリケーションがクライアントに存在しないかもしれないので、ユーザに通知することはできないかもしれません。詳細については、「書き込みオープン委譲のための失効リカバリ」を参照してください。
When locks and delegations are revoked, the assumptions upon which successful caching depend are no longer guaranteed. The owner of the locks or share reservations which have been revoked needs to be notified. This notification includes applications with a file open that has a corresponding delegation which has been revoked. Cached data associated with the revocation must be removed from the client. In the case of modified data existing in the client's cache, that data must be removed from the client without it being written to the server. As mentioned, the assumptions made by the client are no longer valid at the point when a lock or delegation has been revoked. For example, another client may have been granted a conflicting lock after the revocation of the lock at the first client. Therefore, the data within the lock range may have been modified by the other client. Obviously, the first client is unable to guarantee to the application what has occurred to the file in the case of revocation.
ロックや代表団が取り消された場合は、成功したキャッシュが依存する仮定はもはや保証されません。取り消されたロックまたは共有の予約の所有者に通知する必要があります。この通知は取り消された対応する代表団を持っているファイルのオープンとアプリケーションが含まれています。失効に関連付けられたキャッシュされたデータは、クライアントから削除する必要があります。クライアントのキャッシュ内の既存の変更されたデータの場合には、そのデータは、それがサーバーに書き込まれずに、クライアントから削除する必要があります。前述のように、クライアントによって行われた仮定は、ロックまたは委任が取り消された時点で、もはや有効ではありません。例えば、別のクライアントは、最初のクライアントでのロックの失効後に矛盾するロックが付与されている可能性があります。したがって、ロック範囲内のデータは、他のクライアントによって修飾されていてもよいです。もちろん、最初のクライアントが失効した場合のファイルに発生したものをアプリケーションに保証することができません。
Notification to a lock owner will in many cases consist of simply returning an error on the next and all subsequent READs/WRITEs to the open file or on the close. Where the methods available to a client make such notification impossible because errors for certain operations may not be returned, more drastic action such as signals or process termination may be appropriate. The justification for this is that an invariant for which an application depends on may be violated. Depending on how errors are typically treated for the client operating environment, further levels of notification including logging, console messages, and GUI pop-ups may be appropriate.
ロック所有者への通知は、多くの場合、単純に次のエラーを返すから構成され、後続のすべては/がオープンファイルまたは近くに読み書きを行います。特定の操作のためにエラーが返されない場合があるため、クライアントが利用可能な方法は、そのような通知が不可能ここで、このような信号またはプロセス終了、より思い切ったアクションが適切であり得ます。これを正当化する理由は、アプリケーションが依存するため、不変に違反することができるということです。エラーは通常、クライアントの動作環境のために処理されている方法に応じて、ログ、コンソールメッセージ、およびGUIのポップアップを含む通知のさらなるレベルが適切かもしれません。
Revocation recovery for a write open delegation poses the special issue of modified data in the client cache while the file is not open. In this situation, any client which does not flush modified data to the server on each close must ensure that the user receives appropriate notification of the failure as a result of the revocation. Since such situations may require human action to correct problems, notification schemes in which the appropriate user or administrator is notified may be necessary. Logging and console messages are typical examples.
ファイルが開いていない間、書き込みオープン委譲のための失効回復は、クライアントキャッシュに変更されたデータの特別な問題を提起します。このような状況では、各近い上のサーバーに変更されたデータをフラッシュしない任意のクライアントは、ユーザーが失効した結果として故障の適切な通知を受けたことを確認する必要があります。このような状況は、問題を修正するために人間の行動を必要とするかもしれないので、適切なユーザまたは管理者に通知された通知方式が必要であってもよいです。ロギングとコンソールメッセージが典型的な例です。
If there is modified data on the client, it must not be flushed normally to the server. A client may attempt to provide a copy of the file data as modified during the delegation under a different name in the file system name space to ease recovery. Unless the client can determine that the file has not modified by any other client, this technique must be limited to situations in which a client has a complete cached copy of the file in question. Use of such a technique may be limited to files under a certain size or may only be used when sufficient disk space is guaranteed to be available within the target file system and when the client has sufficient buffering resources to keep the cached copy available until it is properly stored to the target file system.
クライアント上のデータが変更された場合は、サーバーに正常にフラッシュされてはなりません。クライアントは、リカバリを容易にするために、ファイルシステムの名前空間に別の名前で、委任時に変更されたファイルデータのコピーを提供しようとすることができます。クライアントは、ファイルが他のクライアントによって変更されていないことを決定することができない限り、この技術は、クライアントが問題のファイルの完全なキャッシュされたコピーを持っている状況に限定されなければなりません。このような技術の使用は、特定のサイズの下のファイルに限定することができるか、十分なディスク領域が、ターゲット・ファイル・システム内で利用可能であることが保証されている場合、クライアントはそれがあるまで利用できるキャッシュされたコピーを維持するために十分なバッファリング資源を持っている場合にのみ使用することができます適切にターゲット・ファイル・システムに格納されています。
The attributes discussed in this section do not include named attributes. Individual named attributes are analogous to files and caching of the data for these needs to be handled just as data caching is for ordinary files. Similarly, LOOKUP results from an OPENATTR directory are to be cached on the same basis as any other pathnames and similarly for directory contents.
このセクションで説明する属性が指定された属性が含まれていません。個々の名前の属性は、ファイルやデータのキャッシングは通常のファイルのためであると同じように処理されるこれらのニーズのためのデータのキャッシュに似ています。同様に、OPENATTRディレクトリから参照結果は、ディレクトリの内容のための任意の他のパス名と同様に同じに基づいてキャッシュされるべきです。
Clients may cache file attributes obtained from the server and use them to avoid subsequent GETATTR requests. Such caching is write through in that modification to file attributes is always done by means of requests to the server and should not be done locally and cached. The exception to this are modifications to attributes that are intimately connected with data caching. Therefore, extending a file by writing data to the local data cache is reflected immediately in the object_size as seen on the client without this change being immediately reflected on the server. Normally such changes are not propagated directly to the server but when the modified data is flushed to the server, analogous attribute changes are made on the server. When open delegation is in effect, the modified attributes may be returned to the server in the response to a CB_RECALL call.
クライアントは、サーバから取得したファイル属性をキャッシュし、その後のGETATTR要求を避けるためにそれらを使用することができます。このようなキャッシュは常に、サーバーへのリクエストによって行われた属性をファイルにその変更にライトスルーし、ローカルに実行され、キャッシュすべきではないです。この例外は密接にデータキャッシュに接続されている属性に変更されています。この変更は、すぐにサーバーに反映されずに、クライアント上で見られるようなので、ローカル・データ・キャッシュにデータを書き込むことで、ファイルを拡張するにはオブジェクト_に即座に反映されています。通常、このような変更は、サーバーに直接反映されませんが、変更されたデータをサーバーにフラッシュされたときに、類似した属性の変更は、サーバー上で行われています。開いている委譲が有効になっている場合には、変更された属性はCB_RECALLの呼び出しに応じてサーバに戻すことができます。
The result of local caching of attributes is that the attribute caches maintained on individual clients will not be coherent. Changes made in one order on the server may be seen in a different order on one client and in a third order on a different client.
属性のローカルキャッシュの結果は、個々のクライアント上で維持さ属性キャッシュがコヒーレントではないということです。サーバー上の1つの順序で行われた変更は1つのクライアントと異なるクライアント上の三ために、異なる順序で見ることができます。
The typical file system application programming interfaces do not provide means to atomically modify or interrogate attributes for multiple files at the same time. The following rules provide an environment where the potential incoherences mentioned above can be reasonably managed. These rules are derived from the practice of previous NFS protocols.
一般的なファイルシステムのアプリケーション・プログラミング・インタフェースは、アトミック、同時に複数のファイルの属性を変更したり、尋問するための手段を提供しません。次の規則は、前述した可能性incoherencesが合理的に管理することができる環境を提供します。これらの規則は、以前のNFSプロトコルの実施から導出されています。
o All attributes for a given file (per-fsid attributes excepted) are cached as a unit at the client so that no non-serializability can arise within the context of a single file.
何の非直列可能で、単一のファイルのコンテキスト内で発生しないことができるように、O、指定されたファイルのすべての属性は、（あたり-FSID属性は除く）クライアントでの単位としてキャッシュされます。
o An upper time boundary is maintained on how long a client cache entry can be kept without being refreshed from the server.
O上側の時間境界は、クライアントのキャッシュエントリは、サーバから更新されずに保持することができるどのくらいに維持されています。
o When operations are performed that change attributes at the server, the updated attribute set is requested as part of the containing RPC. This includes directory operations that update attributes indirectly. This is accomplished by following the modifying operation with a GETATTR operation and then using the results of the GETATTR to update the client's cached attributes.
操作は変更がサーバーに属性をすることを行っている場合には、O、更新された属性のセットが含まRPCの一部として要求されています。これは、その更新が間接的に属性ディレクトリ操作を含んでいます。これは、GETATTR操作で改質操作を次し、クライアントのキャッシュされた属性を更新するために、GETATTRの結果を使用することによって達成されます。
Note that if the full set of attributes to be cached is requested by READDIR, the results can be cached by the client on the same basis as attributes obtained via GETATTR.
キャッシュされる属性の完全なセットがREADDIRによって要求された場合、結果がGETATTRを介して取得した属性と同じ基準で、クライアントによってキャッシュされることに注意してください。
A client may validate its cached version of attributes for a file by fetching only the change attribute and assuming that if the change attribute has the same value as it did when the attributes were cached, then no attributes have changed. The possible exception is the attribute time_access.
クライアントは、変化属性を取得し、変化属性は、属性がキャッシュされた時にそれがなかったのと同じ値を持っている場合は、その後、何の属性が変更されていないことを仮定することにより、ファイルの属性のそのキャッシュされたバージョンを検証することができます。可能な例外は、属性time_accessです。
The results of LOOKUP and READDIR operations may be cached to avoid the cost of subsequent LOOKUP operations. Just as in the case of attribute caching, inconsistencies may arise among the various client caches. To mitigate the effects of these inconsistencies and given the context of typical file system APIs, the following rules should be followed:
LOOKUPとREADDIR操作の結果は、その後のLOOKUP操作のコストを回避するためにキャッシュされる場合があります。ただ、属性のキャッシングの場合のように、矛盾がさまざまなクライアントキャッシュ間生じる可能性があります。これらの不整合の影響を緩和し、一般的なファイルシステムAPIのコンテキストを与えるために、次の規則に従ってください。
o The results of unsuccessful LOOKUPs should not be cached, unless they are specifically reverified at the point of use.
これらは、具体的使用の時点で再検証されていない限り、O失敗したルックアップの結果は、キャッシュされるべきではありません。
o An upper time boundary is maintained on how long a client name cache entry can be kept without verifying that the entry has not been made invalid by a directory change operation performed by another client.
O上側の時間境界は、クライアント名のキャッシュエントリが、別のクライアントによって実行されるディレクトリの変更操作により無効にされていないことを確認せずに維持することができるどのくらいに維持されています。
When a client is not making changes to a directory for which there exist name cache entries, the client needs to periodically fetch attributes for that directory to ensure that it is not being modified. After determining that no modification has occurred, the expiration time for the associated name cache entries may be updated to be the current time plus the name cache staleness bound.
クライアントが名前のキャッシュエントリが存在するためにディレクトリを変更するされていない場合、クライアントは定期的にそれが修正されていないことを確認するために、そのディレクトリの属性を取得する必要があります。何も変更が発生していないことを決定した後、関連する名前のキャッシュエントリの有効期限は、現在の時刻プラスバインド名キャッシュ古さに更新することができます。
When a client is making changes to a given directory, it needs to determine whether there have been changes made to the directory by other clients. It does this by using the change attribute as reported before and after the directory operation in the associated change_info4 value returned for the operation. The server is able to communicate to the client whether the change_info4 data is provided atomically with respect to the directory operation. If the change values are provided atomically, the client is then able to compare the pre-operation change value with the change value in the client's name cache. If the comparison indicates that the directory was updated by another client, the name cache associated with the modified directory is purged from the client. If the comparison indicates no modification, the name cache can be updated on the client to reflect the directory operation and the associated timeout extended. The post-operation change value needs to be saved as the basis for future change_info4 comparisons.
クライアントが指定したディレクトリに変更を行っているとき、それは他のクライアントがディレクトリへの変更があったかどうかを決定する必要があります。これは、操作のために返される関連する変化_info4値のディレクトリ操作の前と後に報告されたように変化属性を使用してこれを行います。サーバは変化_info4データがディレクトリ動作に関してアトミックに設けられているかどうかをクライアントに通信することができます。変更値をアトミックに提供されている場合、クライアントは、クライアントの名前キャッシュに変更値が事前に動作変更値を比較することです。比較はディレクトリが別のクライアントによって更新されたことを示している場合、修正ディレクトリに関連付けられた名前のキャッシュは、クライアントからパージされます。比較は何も変更がないことを示す場合は、名前のキャッシュは、ディレクトリ操作を反映するために、クライアント上で更新することができ、関連するタイムアウトを延長しました。術後変化値は、将来の変化_info4比較のための基礎として保存する必要があります。
As demonstrated by the scenario above, name caching requires that the client revalidate name cache data by inspecting the change attribute of a directory at the point when the name cache item was cached. This requires that the server update the change attribute for directories when the contents of the corresponding directory is modified. For a client to use the change_info4 information appropriately and correctly, the server must report the pre and post operation change attribute values atomically. When the server is unable to report the before and after values atomically with respect to the directory operation, the server must indicate that fact in the change_info4 return value. When the information is not atomically reported, the client should not assume that other clients have not changed the directory.
上記のシナリオによって示されるように、名前のキャッシュは、クライアントが名前のキャッシュ項目がキャッシュされた時点で、ディレクトリの変更属性を調べることによって、名前のキャッシュデータを再検証する必要があります。これは、対応するディレクトリの内容が変更されたときに、サーバがディレクトリの変更属性を更新する必要があります。クライアントは、適切かつ正確に変化_info4情報を使用するには、サーバーは、前と後の動作の変更がアトミックに属性値を報告しなければなりません。サーバーは、ディレクトリ操作に関して原子論前後の値を報告することができない場合は、サーバーは変化_info4の戻り値であることを示す必要があります。情報がアトミックに報告されていない場合、クライアントは他のクライアントがディレクトリを変更していないことを仮定するべきではありません。
The results of READDIR operations may be used to avoid subsequent READDIR operations. Just as in the cases of attribute and name caching, inconsistencies may arise among the various client caches.
READDIR操作の結果は、その後のREADDIR操作を回避するために使用されてもよいです。ただ、属性と名前のキャッシュの例のように、矛盾がさまざまなクライアントキャッシュ間生じる可能性があります。
To mitigate the effects of these inconsistencies, and given the context of typical file system APIs, the following rules should be followed:
これらの不整合の影響を軽減し、一般的なファイルシステムAPIのコンテキストを与えるために、次の規則に従ってください。
o Cached READDIR information for a directory which is not obtained in a single READDIR operation must always be a consistent snapshot of directory contents. This is determined by using a GETATTR before the first READDIR and after the last of READDIR that contributes to the cache.
O単一READDIR操作で得られていないディレクトリのキャッシュREADDIR情報は常にディレクトリの内容の一貫性のあるスナップショットでなければなりません。これは最初のREADDIR前に、キャッシュに寄与することREADDIRの最後の後GETATTRを用いて決定されます。
o An upper time boundary is maintained to indicate the length of time a directory cache entry is considered valid before the client must revalidate the cached information.
O上側の時間境界は、クライアントがキャッシュされた情報を再検証する必要があります前に、ディレクトリキャッシュエントリが有効と考えられている時間の長さを示すために維持されています。
The revalidation technique parallels that discussed in the case of name caching. When the client is not changing the directory in question, checking the change attribute of the directory with GETATTR is adequate. The lifetime of the cache entry can be extended at these checkpoints. When a client is modifying the directory, the client needs to use the change_info4 data to determine whether there are other clients modifying the directory. If it is determined that no other client modifications are occurring, the client may update its directory cache to reflect its own changes.
名前キャッシュの場合で説明した再検証技術の緯線。クライアントがGETATTRとディレクトリの変更属性をチェックし、問題のディレクトリを変更していない場合は十分です。キャッシュエントリの寿命は、これらのチェックポイントに拡張することができます。クライアントがディレクトリを変更している場合は、クライアントがディレクトリを変更する他のクライアントが存在するかどうかを判断するために変化_info4データを使用する必要があります。他のクライアントの変更が発生していないと判断された場合、クライアントは自身の変更を反映するために、そのディレクトリキャッシュを更新することができます。
As demonstrated previously, directory caching requires that the client revalidate directory cache data by inspecting the change attribute of a directory at the point when the directory was cached. This requires that the server update the change attribute for directories when the contents of the corresponding directory is modified. For a client to use the change_info4 information appropriately and correctly, the server must report the pre and post operation change attribute values atomically. When the server is unable to report the before and after values atomically with respect to the directory operation, the server must indicate that fact in the change_info4 return value. When the information is not atomically reported, the client should not assume that other clients have not changed the directory.
以前に実証されているように、ディレクトリキャッシュは、クライアントがディレクトリがキャッシュされた時点でのディレクトリの変更属性を調べることによって、ディレクトリキャッシュデータを再検証する必要があります。これは、対応するディレクトリの内容が変更されたときに、サーバがディレクトリの変更属性を更新する必要があります。クライアントは、適切かつ正確に変化_info4情報を使用するには、サーバーは、前と後の動作の変更がアトミックに属性値を報告しなければなりません。サーバーは、ディレクトリ操作に関して原子論前後の値を報告することができない場合は、サーバーは変化_info4の戻り値であることを示す必要があります。情報がアトミックに報告されていない場合、クライアントは他のクライアントがディレクトリを変更していないことを仮定するべきではありません。
To address the requirement of an NFS protocol that can evolve as the need arises, the NFS version 4 protocol contains the rules and framework to allow for future minor changes or versioning.
必要に応じて進化することができるNFSプロトコルの要件に対処するために、NFSバージョン4プロトコルは、将来のマイナーな変更やバージョンを可能にする規則およびフレームワークを含んでいます。
The base assumption with respect to minor versioning is that any future accepted minor version must follow the IETF process and be documented in a standards track RFC. Therefore, each minor version number will correspond to an RFC. Minor version zero of the NFS version 4 protocol is represented by this RFC. The COMPOUND procedure will support the encoding of the minor version being requested by the client.
マイナーバージョンに関する基本仮定は、将来のマイナーバージョンIETFプロセスに従わなければなりませんし、標準トラックRFCに文書化することを受け入れたことです。したがって、各マイナーバージョン番号は、RFCに対応することになります。 NFSバージョン4プロトコルのマイナーバージョンゼロは、このRFCによって表されます。 COMPOUND手順は、クライアントによって要求されたマイナーバージョンのエンコーディングをサポートします。
The following items represent the basic rules for the development of minor versions. Note that a future minor version may decide to modify or add to the following rules as part of the minor version definition.
以下の項目は、マイナーバージョンの開発のための基本的なルールを表しています。将来のマイナーバージョンが変更またはマイナーバージョン定義の一部として、次のルールに追加することを決定することがあります。
1 Procedures are not added or deleted
1つの手順は、追加または削除されていません
To maintain the general RPC model, NFS version 4 minor versions
will not add or delete procedures from the NFS program.
2 Minor versions may add operations to the COMPOUND and CB_COMPOUND procedures.
2つのマイナーバージョンは、化合物とCB_COMPOUND手順に操作を追加することができます。
The addition of operations to the COMPOUND and CB_COMPOUND
procedures does not affect the RPC model.
2.1 Minor versions may append attributes to GETATTR4args, bitmap4, and GETATTR4res.
2.1マイナーバージョンはGETATTR4args、bitmap4、及びGETATTR4resに属性を追加することができます。
This allows for the expansion of the attribute model to allow
for future growth or adaptation.
2.2 Minor version X must append any new attributes after the last documented attribute.
2.2マイナーバージョンXは、最後の文書属性の後に任意の新しい属性を追加する必要があります。
Since attribute results are specified as an opaque array of
per-attribute XDR encoded results, the complexity of adding new
attributes in the midst of the current definitions will be too
burdensome.
3 Minor versions must not modify the structure of an existing operation's arguments or results.
3つのマイナーバージョンでは、既存のオペレーションの引数や結果の構造を変更してはなりません。
Again the complexity of handling multiple structure definitions
for a single operation is too burdensome. New operations should
be added instead of modifying existing structures for a minor
version.
This rule does not preclude the following adaptations in a minor version.
この規則は、マイナーバージョンでは、以下の適応を妨げるものではありません。
o adding bits to flag fields such as new attributes to GETATTR's bitmap4 data type
GETATTRのbitmap4データ型に新たな属性としてフラグフィールドにビットを追加O
o adding bits to existing attributes like ACLs that have flag words
Oフラグワードを有するACLのような既存の属性にビットを付加
o extending enumerated types (including NFS4ERR_*) with new values
新しい値で（NFS4ERR_ *を含む）列挙型を拡張するO
4 Minor versions may not modify the structure of existing attributes.
4つのマイナーバージョンは、既存の属性の構造を変更しなくてもよいです。
5 Minor versions may not delete operations.
5つのマイナーバージョンでは、操作を削除しないことがあります。
This prevents the potential reuse of a particular operation
"slot" in a future minor version.
6 Minor versions may not delete attributes.
6つのマイナーバージョンでは、属性を削除しないことがあります。
7 Minor versions may not delete flag bits or enumeration values.
7つのマイナーバージョンは、フラグビットまたは列挙値を削除しなくてもよいです。
8 Minor versions may declare an operation as mandatory to NOT implement.
8つのマイナーバージョンを実装しないために必須の動作を宣言することができます。
Specifying an operation as "mandatory to not implement" is
equivalent to obsoleting an operation. For the client, it means
that the operation should not be sent to the server. For the
server, an NFS error can be returned as opposed to "dropping"
the request as an XDR decode error. This approach allows for
the obsolescence of an operation while maintaining its structure
so that a future minor version can reintroduce the operation.
8.1 Minor versions may declare attributes mandatory to NOT implement.
8.1マイナーバージョンでは実装しないように必須属性を宣言してもよいです。
8.2 Minor versions may declare flag bits or enumeration values as mandatory to NOT implement.
8.2マイナーバージョンを実装しないことを必須としてフラグビットまたは列挙値を宣言することができます。
9 Minor versions may downgrade features from mandatory to recommended, or recommended to optional.
9つのマイナーバージョンは必須から推奨、または任意に推薦する機能をダウングレードしてもよいです。
10 Minor versions may upgrade features from optional to recommended or recommended to mandatory.
10のマイナーバージョンは、オプションからの推奨または必須に推奨する機能をアップグレードすることができます。
11 A client and server that support minor version X must support minor versions 0 (zero) through X-1 as well.
マイナーバージョンXをサポートする11クライアントとサーバは、同様に0（ゼロ）X-1を介してマイナーバージョンをサポートしなければなりません。
12 No new features may be introduced as mandatory in a minor version.
12何個の新機能は、マイナーバージョンで必須として導入することはできません。
This rule allows for the introduction of new functionality and
forces the use of implementation experience before designating a
feature as mandatory.
13 A client MUST NOT attempt to use a stateid, file handle, or similar returned object from the COMPOUND procedure with minor version X for another COMPOUND procedure with minor version Y, where X != Y.
13クライアントは、X！= Y.マイナーバージョンY、と別のCOMPOUND手順のためにマイナーバージョンXでCOMPOUND手順からのstateid、ファイルハンドル、または同様返されたオブジェクトを使用することを試みてはいけません
The primary issue in which NFS needs to deal with internationalization, or I18n, is with respect to file names and other strings as used within the protocol. The choice of string representation must allow reasonable name/string access to clients which use various languages. The UTF-8 encoding of the UCS as defined by [ISO10646] allows for this type of access and follows the policy described in "IETF Policy on Character Sets and Languages", [RFC2277]. This choice is explained further in the following.
NFSは、国際化、または国際化に対処する必要のある主な問題は、プロトコル内で使用される名前や他の文字列をファイルに関連しています。文字列表現の選択は、さまざまな言語を使用するクライアントへの合理的な名前/文字列へのアクセスを許可する必要があります。 UTF-8で定義されるようにUCSのエンコーディング[ISO10646]はこのタイプのアクセスを可能にし、「文字セットと言語でIETFポリシー」、[RFC2277]に記載されたポリシーに従います。この選択は、以下にさらに説明します。
[RFC1345] describes a table of 16 bit characters for many different languages (the bit encodings match Unicode, though of course RFC1345 is somewhat out of date with respect to current Unicode assignments). Each character from each language has a unique 16 bit value in the 16 bit character set. Thus this table can be thought of as a universal character set. [RFC1345] then talks about groupings of subsets of the entire 16 bit character set into "Charset Tables". For example one might take all the Greek characters from the 16 bit table (which are consecutively allocated), and normalize their offsets to a table that fits in 7 bits. Thus it is determined that "lower case alpha" is in the same position as "upper case a" in the US-ASCII table, and "upper case alpha" is in the same position as "lower case a" in the US-ASCII table.
[RFC1345]多くの異なる言語の16ビット文字のテーブルを記述する（ビットエンコーディングは、Unicodeに一致する、コースRFC1345のかかわらず、現在のUnicode割り当てに対して幾分時代遅れです）。各言語からの各文字は、16ビットの文字セットでユニークな16ビットの値を持っています。したがって、この表には、汎用文字セットと考えることができます。 [RFC1345]は、次いで、「文字セットテーブル」にセット全体の16ビット文字のサブセットのグループについて話します。例えば、一方は（連続的に割り当てられている）16ビットテーブルからすべてのギリシャ文字がかかることがあり、及び7ビットに収まるテーブルへのオフセットを正規化します。したがって、「小文字のアルファ」と同じ位置にあると判定された「大文字」US-ASCIIテーブル、および「大文字アルファ」に「小文字」にUS-ASCIIと同じ位置にありますテーブル。
These normalized subset character sets can be thought of as "local character sets", suitable for an operating system locale.
これらの正規化されたサブセットの文字セットは、オペレーティング・システムのロケールに適した「ローカル文字セット」と考えることができます。
Local character sets are not suitable for the NFS protocol. Consider someone who creates a file with a name in a Swedish character set. If someone else later goes to access the file with their locale set to the Swedish language, then there are no problems. But if someone in say the US-ASCII locale goes to access the file, the file name will look very different, because the Swedish characters in the 7 bit table will now be represented in US-ASCII characters on the display. It would be preferable to give the US-ASCII user a way to display the file name using Swedish glyphs. In order to do that, the NFS protocol would have to include the locale with the file name on each operation to create a file.
ローカル文字セットは、NFSプロトコルには適していません。スウェーデンの文字セットの名前のファイルを作成し、誰かを考えてみましょう。他の誰かが後でスウェーデン語へのロケールが設定されたファイルにアクセスするために行く場合は、問題はありません。言うの誰かがUS-ASCIIのロケールがファイルにアクセスするために行く場合は7ビットテーブルのスウェーデンの文字は今、ディスプレイ上のUS-ASCII文字で表現されますので、しかし、ファイル名が、非常に異なって見えるでしょう。 US-ASCIIのユーザーにスウェーデンのグリフを使用してファイル名を表示する方法を提供することが望ましいだろう。そのためには、NFSプロトコルは、ファイルを作成するために、各操作上のファイル名とロケールを含める必要があります。
But then what of the situation when there is a path name on the server like:
しかし、その後の状況のどのようなパス名は次のようにサーバー上にあります：
/component-1/component-2/component-3
/成分1 /成分2 /コンポーネント-3
Each component could have been created with a different locale. If one issues CREATE with multi-component path name, and if some of the leading components already exist, what is to be done with the existing components? Is the current locale attribute replaced with the user's current one? These types of situations quickly become too complex when there is an alternate solution.
各コンポーネントは、別のロケールで作成された可能性があります。 1つの問題は、多成分のパス名で作成して、主要なコンポーネントの一部がすでに存在する場合、どのように既存のコンポーネントで行われるのですか？場合現在のロケールの属性は、ユーザーの現在のものに置き換えられていますか？代替ソリューションがあるときの状況のこれらのタイプはすぐにあまりにも複雑になります。
If the NFS version 4 protocol used a universal 16 bit or 32 bit character set (or an encoding of a 16 bit or 32 bit character set into octets), then the server and client need not care if the locale of the user accessing the file is different than the locale of the user who created the file. The unique 16 bit or 32 bit encoding of the character allows for determination of what language the character is from and also how to display that character on the client. The server need not know what locales are used.
NFSバージョン4プロトコルはユニバーサル16ビットまたは32ビットの文字セット（またはオクテットに設定し、16ビットまたは32ビットの文字のエンコーディング）を使用した場合、ユーザーのロケールがファイルにアクセスする場合は、サーバとクライアントは気にする必要はありませんファイルを作成したユーザーのロケールと異なります。文字のユニークな16ビットまたは32ビットエンコーディングは、文字がクライアント上でその文字を表示する方法もあるから、どのような言語を決意することができます。サーバーは、ロケールが使用されているかを知る必要はありません。
The previous section makes a case for using a universal character set. This section makes the case for using UTF-8 as the specific universal character set for the NFS version 4 protocol.
前のセクションでは、汎用文字セットを使用するためのケースになります。このセクションでは、NFSバージョン4プロトコルのための具体的な汎用文字セットとしてUTF-8を使用するためのケースになります。
[RFC2279] discusses UTF-* (UTF-8 and other UTF-XXX encodings), Unicode, and UCS-*. There are two standards bodies managing universal code sets:
[RFC2279]は* UTF-*（UTF-8および他のUTF-XXXエンコーディング）、ユニコード、およびUCS-を論じています。ユニバーサルコードセットを管理する2つの標準化団体があります。
o ISO/IEC which has the standard 10646-1
標準10646-1を持っているO ISO / IEC
o Unicode which has the Unicode standard
Unicode標準を持っているのUnicode O
Both standards bodies have pledged to track each other's assignments of character codes.
どちらの標準化団体は、文字コードの互いの割り当てを追跡することを約束しています。
The following is a brief analysis of the various standards.
以下は、様々な規格の簡単な分析です。
UCS Universal Character Set. This is ISO/IEC 10646-1: "a multi-octet character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems."
UCSユニバーサル文字セット。これは、ISO / IEC 10646-1である：「世界の書記体系の大部分を含むユニバーサル文字セット（UCS）と呼ばれるマルチオクテット文字セット、」
UCS-2 a two octet per character encoding that addresses the first 2^16 characters of UCS. Currently there are no UCS characters beyond that range.
UCS-2 UCSの最初の2 ^ 16文字を扱う文字エンコーディングごとに2つのオクテット。現在、その範囲を超えていないUCS文字はありません。
UCS-4 a four octet per character encoding that permits the encoding of up to 2^31 characters.
UCS-4までの2 ^ 31文字のエンコーディングを許可する文字エンコーディングごとに4つのオクテット。
UTF UTF is an abbreviation of the term "UCS transformation format" and is used in the naming of various standards for encoding of UCS characters as described below.
UTFのUTFは、用語「UCS変換フォーマット」の略語であり、以下に説明するようにUCS文字の符号化のための様々な規格の命名に使用されます。
UTF-1 Only historical interest; it has been removed from 10646-1
UTF-1のみの歴史的な関心;それは10646-1から削除されました
UTF-7 Encodes the entire "repertoire" of UCS "characters using only octets with the higher order bit clear". [RFC2152] describes UTF-7. UTF-7 accomplishes this by reserving one of the 7bit US-ASCII characters as a "shift" character to indicate non-US-ASCII characters.
UTF-7は、「明確な上位ビットのみオクテットを使用して文字」UCSの全体の「レパートリー」をエンコードします。 [RFC2152]はUTF-7を記載しています。 UTF-7は非US-ASCII文字を示すために「シフト」の文字として7ビットUS-ASCII文字のいずれかを予約することによって、これを達成します。
UTF-8 Unlike UTF-7, uses all 8 bits of the octets. US-ASCII characters are encoded as before unchanged. Any octet with the high bit cleared can only mean a US-ASCII character. The high bit set means that a UCS character is being encoded.
UTF-8 UTF-7とは異なりは、オクテットの8ビットすべてを使用しています。 US-ASCII文字はそのまま以前のようにエンコードされます。クリア高ビットを持つ任意のオクテットは、US-ASCII文字を意味することができます。高ビット・セットは、UCSの文字がエンコードされていることを意味します。
UTF-16 Encodes UCS-4 characters into UCS-2 characters using a reserved range in UCS-2.
UTF-16はUCS-2で予約された範囲を使用して、UCS-2文字にUCS-4文字をエンコード。
Unicode Unicode and UCS-2 are the same; [RFC2279] states:
ユニコードユニコードとUCS-2は同一です。 [RFC2279]は述べています：
Up to the present time, changes in Unicode and amendments
to ISO/IEC 10646 have tracked each other, so that the
character repertoires and code point assignments have
remained in sync. The relevant standardization committees
have committed to maintain this very useful synchronism.
Adapting existing applications, and file systems to multi-octet schemes like UCS and Unicode can be difficult. A significant amount of code has been written to process streams of bytes. Also there are many existing stored objects described with 7 bit or 8 bit characters. Doubling or quadrupling the bandwidth and storage requirements seems like an expensive way to accomplish I18N.
UCSとUnicodeなどのマルチオクテットスキームに既存のアプリケーション、およびファイルシステムを適応させることは困難な場合があります。コードのかなりの量は、バイトのストリームを処理するように書かれています。また、7ビットまたは8ビット文字で記載されている多くの既存の格納されたオブジェクトが存在します。帯域幅とストレージ要件を倍増または四倍にすることはI18Nを達成するために高価な方法のように思えます。
UCS-2 and Unicode are "only" 16 bits long. That might seem to be enough but, according to [Unicode1], 49,194 Unicode characters are already assigned. According to [Unicode2] there are still more languages that need to be added.
UCS-2およびUnicodeは、 "のみ" 16ビット長です。それは[Unicode1]によると、49194のUnicode文字が既に割り当てられている、十分にあるように見えるかもしれませんが。 [Unicode2]によると、追加する必要がより多くの言語が残っています。
UTF-8 solves problems for NFS that exist with the use of UCS and Unicode. UTF-8 will encode 16 bit and 32 bit characters in a way that will be compact for most users. The encoding table from UCS-4 to UTF-8, as copied from [RFC2279]:
UTF-8はUCSとユニコードを使用して存在してNFSのための問題を解決します。 UTF-8は、ほとんどのユーザーのためにコンパクトであろうように16ビットおよび32ビット文字をコードします。 [RFC2279]からコピーとしてUTF-8 UCS-4から符号化テーブル：
UCS-4 range (hex.) UTF-8 octet sequence (binary) 0000 0000-0000 007F 0xxxxxxx 0000 0080-0000 07FF 110xxxxx 10xxxxxx 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx 0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0400 0000-7FFF FFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
UCS-4範囲（16進）UTF-8オクテット配列（バイナリ）0000 0000-0000 007F 0xxxxxxx 0000 0080から0000 07FF 110xxxxx 10xxxxxxに0000 0800から0000 FFFF 1110xxxx 10xxxxxxに10xxxxxxに0001 0000-001F FFFF 11110xxx 10xxxxxxに10xxxxxxに10xxxxxxに0020 0000-03FF FFFF 111110xx 10xxxxxxに10xxxxxxに10xxxxxxに10xxxxxxに0400 0000-7FFF FFFF 1111110x 10xxxxxxに10xxxxxxに10xxxxxxに10xxxxxxに10xxxxxxに
See [RFC2279] for precise encoding and decoding rules. Note because of UTF-16, the algorithm from Unicode/UCS-2 to UTF-8 needs to account for the reserved range between D800 and DFFF.
正確な符号化および復号化ルールのために[RFC2279]を参照。なぜならUTF-16（注）、UTF-8へのUnicode / UCS-2からアルゴリズムはD800とDFFFの間の予約された範囲を考慮する必要があります。
Note that the 16 bit UCS or Unicode characters require no more than 3 octets to encode into UTF-8
16ビットのUCSまたはUnicode文字がUTF-8に符号化するためにこれ以上3以下のオクテットを必要とすることに注意してください
Interestingly, UTF-8 has room to handle characters larger than 31 bits, because the leading octet of form:
興味深いことに、UTF-8形式の先頭オクテットので、31ビットよりも大きい文字を処理する余地があります。
1111111x
1111111x
is not defined. If needed, ISO could either use that octet to indicate a sequence of an encoded 8 octet character, or perhaps use 11111110 to permit the next octet to indicate an even more expandable character set.
定義されてない。必要に応じて、ISOは、エンコードされた8オクテット文字のシーケンスを示すために、そのオクテットを使用するか、おそらくそれ以上の拡張文字セットを示すために、次のオクテットを可能にするために、11111110を使用することができますどちらか。
So using UTF-8 to represent character encodings means never having to run out of room.
だから、文字エンコーディングを表すためにUTF-8を使用すると、部屋の外に実行する必要がないことを意味します。
The client and server operating environments may differ in their policies and operational methods with respect to character normalization (See [Unicode1] for a discussion of normalization forms). This difference may also exist between applications on the same client. This adds to the difficulty of providing a single normalization policy for the protocol that allows for maximal interoperability. This issue is similar to the character case issues where the server may or may not support case insensitive file name matching and may or may not preserve the character case when storing file names. The protocol does not mandate a particular behavior but allows for the various permutations.
クライアントとサーバーの動作環境は、（正規形の議論のための[Unicode1]を参照してください）文字の正規化に関して、彼らの政策や運用方法が異なることがあります。この違いは、同じクライアント上のアプリケーションの間に存在することができます。これが最大の相互運用性を可能にしたプロトコルのための単一の正規化ポリシーを提供することの難しさに追加されます。この問題は、サーバーが大文字小文字を区別しないか、ファイル名のマッチングをサポートしていない可能性があり、ファイル名を格納するときや文字ケースを保存しない場合があり、文字ケースの問題に似ています。プロトコルは、特定の行動を義務はなく、種々の順列を可能にしていません。
The NFS version 4 protocol does not mandate the use of a particular normalization form at this time. A later revision of this specification may specify a particular normalization form. Therefore, the server and client can expect that they may receive unnormalized characters within protocol requests and responses. If the operating environment requires normalization, then the implementation must normalize the various UTF-8 encoded strings within the protocol before presenting the information to an application (at the client) or local file system (at the server).
NFSバージョン4プロトコルは、この時点で特定の正規化形式を使用することを強制しません。本明細書の以降の改訂は、特定の正規化形式を指定することができます。そのため、サーバとクライアントは、彼らがプロトコルの要求と応答の中に正規化されていない文字を受け取ることができることを期待することができます。動作環境が正常化が必要な場合は、その実装は、（サーバーで）（クライアントで）アプリケーションまたはローカルファイルシステムに情報を提示する前に、プロトコル内の様々なUTF-8エンコードされた文字列を正規化しなければなりません。
NFS error numbers are assigned to failed operations within a 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エラー番号が複合要求の中に失敗した操作に割り当てられています。複合要求は化合物応答のシーケンスで、その結果を符号化されたNFS操作の数を含んでいます。成功した操作の結果は、動作の符号化された結果に続いNFS4_OK状態で構成されます。 NFS操作が失敗した場合、エラー状態は、返信に入力されますと、複合要求は終了します。
A description of each defined error follows:
各定義されたエラーの説明は次の通りです。
NFS4_OK Indicates the operation completed successfully.
NFS4_OKが正常に完了した操作を示します。
NFS4ERR_ACCES Permission denied. The caller does not have the correct permission to perform the requested operation. Contrast this with NFS4ERR_PERM, which restricts itself to owner or privileged user permission failures.
NFS4ERR_ACCESの権限が拒否されました。呼び出し側は、要求された操作を実行するための正しい権限がありません。所有者または特権ユーザー権限失敗に自分自身を制限NFS4ERR_PERM、とは対照的。
NFS4ERR_BADHANDLE Illegal NFS file handle. The file handle failed internal consistency checks.
NFS4ERR_BADHANDLE不正なNFSファイルハンドル。ファイルハンドルは、内部整合性チェックに失敗しました。
NFS4ERR_BADTYPE An attempt was made to create an object of a type not supported by the server.
NFS4ERR_BADTYPE試みは、サーバーでサポートされていないタイプのオブジェクトを作成しました。
NFS4ERR_BAD_COOKIE READDIR cookie is stale.
NFS4ERR_BAD_COOKIE READDIR Cookieが古くなっています。
NFS4ERR_BAD_SEQID The sequence number in a locking request is neither the next expected number or the last number processed.
NFS4ERR_BAD_SEQIDロック要求のシーケンス番号は、次の予想される数または最後に処理数でもありません。
NFS4ERR_BAD_STATEID A stateid generated by the current server instance, but which does not designate any locking state (either current or superseded) for a current lockowner-file pair, was used.
NFS4ERR_BAD_STATEID Aは、現在のサーバインスタンスによって生成されたのstateidが、使用された、現在のlockownerファイルペアに対して（現在または置き換えのいずれか）、任意のロック状態を指定しません。
NFS4ERR_CLID_INUSE The SETCLIENTID procedure has found that a client id is already in use by another client.
SETCLIENTID手順NFS4ERR_CLID_INUSEクライアントIDが別のクライアントによってすでに使用中であることを見出しました。
NFS4ERR_DELAY The server initiated the request, but was not able to complete it in a timely fashion. The client should wait and then try the request with a new RPC transaction ID. For example, this error should be returned from a server that supports hierarchical storage and receives a request to process a file that has been migrated. In this case, the server should start the immigration process and respond to client with this error. This error may also occur when a necessary delegation recall makes processing a request in a timely fashion impossible.
NFS4ERR_DELAYは、サーバは、要求を開始したが、タイムリーにそれを完了することができませんでした。クライアントが待機してから、新しいRPCのトランザクションIDとリクエストを試してみてください。たとえば、このエラーは、階層型ストレージをサポートし、移行されたファイルを処理するための要求を受けたサーバから返されるべきです。この場合、サーバは、移民プロセスを開始する必要があり、このエラーでクライアントに応答します。必要な委任のリコールが不可能にタイムリーに要求を処理して行ったときにも、このエラーが発生することがあります。
NFS4ERR_DENIED An attempt to lock a file is denied. Since this may be a temporary condition, the client is encouraged to retry the lock request until the lock is accepted.
拒否されたファイルをロックしようとする試みをNFS4ERR_DENIED。これは一時的な状態であるかもしれないので、クライアントはロックが受理されるまで、ロック要求を再試行することが奨励されます。
NFS4ERR_DQUOT Resource (quota) hard limit exceeded. The user's resource limit on the server has been exceeded.
NFS4ERR_DQUOTリソース（クオータ）ハードリミットを超えました。サーバー上のユーザーのリソース制限を超えました。
NFS4ERR_EXIST File exists. The file specified already exists.
NFS4ERR_EXISTファイルが存在します。指定されたファイルはすでに存在しています。
NFS4ERR_EXPIRED A lease has expired that is being used in the current procedure.
NFS4ERR_EXPIREDリースは、現在の手順で使用されている有効期限が切れています。
NFS4ERR_FBIG File too large. The operation would have caused a file to grow beyond the server's limit.
NFS4ERR_FBIGは、ファイルが大きすぎます。操作は、ファイルがサーバーの制限を超えて成長させただろう。
NFS4ERR_FHEXPIRED The file handle provided is volatile and has expired at the server.
提供されたファイルハンドルが揮発性であり、サーバーで期限切れになったNFS4ERR_FHEXPIRED。
NFS4ERR_GRACE The server is in its recovery or grace period which should match the lease period of the server.
NFS4ERR_GRACEサーバは、サーバのリース期間を一致させる必要があり、その回復または猶予期間にあります。
NFS4ERR_INVAL Invalid argument or unsupported argument for an operation. Two examples are attempting a READLINK on an object other than a symbolic link or attempting to SETATTR a time field on a server that does not support this operation.
NFS4ERR_INVAL無効な引数や操作のためにサポートされていない引数。二つの例は、シンボリックリンク以外のオブジェクトにREADLINKを試みるか、この操作をサポートしていないサーバー上の時間フィールドをSETATTRしようとしています。
NFS4ERR_IO I/O error. A hard error (for example, a disk error) occurred while processing the requested operation.
NFS4ERR_IO I / Oエラー。要求された操作を処理している間（例えば、ディスクエラー）ハードエラーが発生しました。
NFS4ERR_ISDIR Is a directory. The caller specified a directory in a non-directory operation.
NFS4ERR_ISDIRはディレクトリです。呼び出し側が非ディレクトリ操作でディレクトリを指定しました。
NFS4ERR_LEASE_MOVED A lease being renewed is associated with a file system that has been migrated to a new server.
新しいサーバに移行されたファイルシステムに関連付けられている更新されたリースをNFS4ERR_LEASE_MOVED。
NFS4ERR_LOCKED A read or write operation was attempted on a locked file.
NFS4ERR_LOCKED Aの読み取りまたは書き込み操作がロックされたファイルにしようとしました。
NFS4ERR_LOCK_RANGE A lock request is operating on a sub-range of a current lock for the lock owner and the server does not support this type of request.
NFS4ERR_LOCK_RANGE Aロック要求がロック所有者の現在のロックのサブ範囲で動作し、サーバは、要求のこのタイプをサポートしていません。
NFS4ERR_MINOR_VERS_MISMATCH The server has received a request that specifies an unsupported minor version. The server must return a COMPOUND4res with a zero length operations result array.
NFS4ERR_MINOR_VERS_MISMATCHサーバがサポートされていないマイナーバージョンを指定する要求を受信しました。サーバは、長さゼロの操作結果アレイとCOMPOUND4resを返さなければなりません。
NFS4ERR_MLINK Too many hard links.
NFS4ERR_MLINKあまりにも多くのハードリンク。
NFS4ERR_MOVED The filesystem which contains the current filehandle object has been relocated or migrated to another server. The client may obtain the new filesystem location by obtaining the "fs_locations" attribute for the current filehandle. For further discussion, refer to the section "Filesystem Migration or Relocation".
NFS4ERR_MOVED現在のファイルハンドルオブジェクトが含まれているファイルシステムは、移転または別のサーバーに移行されました。クライアントは、現在のファイルハンドルのための「fs_位置」属性を取得することによって、新しいファイルシステムの場所を得ることができます。さらなる議論については、「ファイルシステムの移行または再配置」を参照してください。
NFS4ERR_NAMETOOLONG The filename in an operation was too long.
操作でファイル名をNFS4ERR_NAMETOOLONGが長すぎました。
NFS4ERR_NODEV No such device.
NFS4ERR_NODEVそのようなデバイスはありません。
NFS4ERR_NOENT No such file or directory. The file or directory name specified does not exist.
NFS4ERR_NOENTそのようなファイルやディレクトリはありません。指定したファイルまたはディレクトリ名は存在しません。
NFS4ERR_NOFILEHANDLE The logical current file handle value has not been set properly. This may be a result of a malformed COMPOUND operation (i.e. no PUTFH or PUTROOTFH before an operation that requires the current file handle be set).
NFS4ERR_NOFILEHANDLE論理現在のファイルハンドル値が正しく設定されていません。これは、（現在のファイルが設定されて扱う必要とする操作の前に、すなわちないPUTFH又はPUTROOTFH）不正な複合操作の結果であり得ます。
NFS4ERR_NOSPC No space left on device. The operation would have caused the server's file system to exceed its limit.
NFS4ERR_NOSPCスペースがありませんが、デバイス上に残って。操作は、その限界を超えるサーバのファイルシステムを引き起こしているだろう。
NFS4ERR_NOTDIR Not a directory. The caller specified a non-directory in a directory operation.
NFS4ERR_NOTDIRないディレクトリ。呼び出し側はディレクトリ操作で非ディレクトリを指定しました。
NFS4ERR_NOTEMPTY An attempt was made to remove a directory that was not empty.
NFS4ERR_NOTEMPTYは試みが空ではなかったディレクトリを削除しました。
NFS4ERR_NOTSUPP Operation is not supported.
NFS4ERR_NOTSUPP操作がサポートされていません。
NFS4ERR_NOT_SAME This error is returned by the VERIFY operation to signify that the attributes compared were not the same as provided in the client's request.
NFS4ERR_NOT_SAMEこのエラーは、クライアントの要求で提供される比較の属性が同じではなかったことを意味するベリファイ動作によって返されます。
NFS4ERR_NXIO I/O error. No such device or address.
NFS4ERR_NXIO I / Oエラー。そのようなデバイスんまたはアドレス。
NFS4ERR_OLD_STATEID A stateid which designates the locking state for a lockowner-file at an earlier time was used.
NFS4ERR_OLD_STATEID早い時点でlockownerファイルのロック状態を指定するのstateidを使用しました。
NFS4ERR_PERM Not owner. The operation was not allowed because the caller is either not a privileged user (root) or not the owner of the target of the operation.
NFS4ERR_PERMない所有者。発呼者が特権ユーザ（ルート）であるか否か、操作の対象の所有者のいずれかではないため、操作は許可されませんでした。
NFS4ERR_READDIR_NOSPC The encoded response to a READDIR request exceeds the size limit set by the initial request.
NFS4ERR_READDIR_NOSPCはREADDIR要求に符号化された応答は、最初の要求により設定されたサイズ制限を超えています。
NFS4ERR_RESOURCE For the processing of the COMPOUND procedure, the server may exhaust available resources and can not continue processing procedures within the COMPOUND operation. This error will be returned from the server in those instances of resource exhaustion related to the processing of the COMPOUND procedure.
NFS4ERR_RESOURCEはCOMPOUND手順の処理のために、サーバは、利用可能なリソースを使い果たしてもよいし、複合操作内の処理手順を続行することができません。このエラーはCOMPOUND手順の処理に関連するリソースの枯渇のこれらの例では、サーバから返されます。
NFS4ERR_ROFS Read-only file system. A modifying operation was attempted on a read-only file system.
NFS4ERR_ROFSは、読み取り専用ファイルシステムを。変更操作は、読み取り専用ファイルシステム上で実行しようとしました。
NFS4ERR_SAME This error is returned by the NVERIFY operation to signify that the attributes compared were the same as provided in the client's request.
NFS4ERR_SAMEこのエラーは、クライアントの要求で提供される比べ属性が同じであったことを示すためにNVERIFY操作によって返されます。
NFS4ERR_SERVERFAULT An error occurred on the server which does not map to any of the legal NFS version 4 protocol error values. The client should translate this into an appropriate error. UNIX clients may choose to translate this to EIO.
法律上のNFSバージョン4つのプロトコルエラー値のいずれかにマップされないサーバー上で発生したエラーをNFS4ERR_SERVERFAULT。クライアントは、適切なエラーにこれを変換する必要があります。 UNIXクライアントがEIOにこれを翻訳することもできます。
NFS4ERR_SHARE_DENIED An attempt to OPEN a file with a share reservation has failed because of a share conflict.
シェア予約でファイルを開こうとしNFS4ERR_SHARE_DENIEDため、株式紛争のに失敗しました。
NFS4ERR_STALE Invalid file handle. The file handle given in the arguments was invalid. The file referred to by that file handle no longer exists or access to it has been revoked.
NFS4ERR_STALE無効なファイルハンドル。引数で指定したファイルハンドルが無効でした。そのファイルハンドルが参照するファイルもはや存在しないか、それへのアクセスが取り消されました。
NFS4ERR_STALE_CLIENTID A clientid not recognized by the server was used in a locking or SETCLIENTID_CONFIRM request.
NFS4ERR_STALE_CLIENTID Aはロック又はSETCLIENTID_CONFIRM要求で使用されたサーバーによって認識されないのClientID。
NFS4ERR_STALE_STATEID A stateid generated by an earlier server instance was used.
NFS4ERR_STALE_STATEID Aは、インスタンスを使用した以前のサーバによって生成のstateid。
NFS4ERR_SYMLINK The current file handle provided for a LOOKUP is not a directory but a symbolic link. Also used if the final component of the OPEN path is a symbolic link.
NFS4ERR_SYMLINKは、LOOKUPのために設けられた電流のファイルハンドルは、ディレクトリが、シンボリックリンクではありません。 OPENパスの最後の構成要素がシンボリックリンクである場合にも使用されます。
NFS4ERR_TOOSMALL Buffer or request is too
small.
NFS4ERR_WRONGSEC The security mechanism being used by the client for the procedure does not match the server's security policy. The client should change the security mechanism being used and retry the operation.
NFS4ERR_WRONGSECは、手続きのために、クライアントによって使用されているセキュリティ・メカニズムは、サーバーのセキュリティポリシーと一致していません。クライアントが使用されているセキュリティ・メカニズムを変更し、操作を再試行する必要があります。
NFS4ERR_XDEV Attempt to do a cross-device hard link.
NFS4ERR_XDEVは、クロスデバイスのハードリンクを行うことを試みます。
For the NFS version 4 RPC program, there are two traditional RPC procedures: NULL and COMPOUND. All other functionality is defined as a set of operations and these operations are defined in normal XDR/RPC syntax and semantics. However, these operations are encapsulated within the COMPOUND procedure. This requires that the client combine one or more of the NFS version 4 operations into a single request.
NULLとCOMPOUND：NFSバージョン4 RPCプログラムの場合は、2つの伝統的なRPCの手順があります。その他のすべての機能は、一連の操作として定義されており、これらの操作は、通常のXDR / RPCの構文およびセマンティクスで定義されています。しかし、これらの操作は、COMPOUNDプロシージャ内に封入されています。これにより、クライアントは単一の要求にNFSバージョン4のいずれかの操作を組み合わせることが必要です。
The NFS4_CALLBACK program is used to provide server to client signaling and is constructed in a similar fashion as the NFS version 4 program. The procedures CB_NULL and CB_COMPOUND are defined in the same way as NULL and COMPOUND are within the NFS program. The CB_COMPOUND request also encapsulates the remaining operations of the NFS4_CALLBACK program. There is no predefined RPC program number for the NFS4_CALLBACK program. It is up to the client to specify a program number in the "transient" program range. The program and port number of the NFS4_CALLBACK program are provided by the client as part of the SETCLIENTID operation and therefore is fixed for the life of the client instantiation.
NFS4_CALLBACKプログラムは、クライアント・シグナリングにサーバーを提供するために使用され、NFSバージョン4プログラムと同様の方法で構成されています。 NULLおよび化合物はNFSプログラム内にあるような手順CB_NULLとCB_COMPOUNDも同様に定義されます。 CB_COMPOUND要求もNFS4_CALLBACKプログラムの残りの操作をカプセル化します。 NFS4_CALLBACKプログラムには事前に定義されたRPCプログラム番号がありません。これは、「一時的な」プログラムの範囲でプログラム番号を指定するには、クライアント次第です。 NFS4_CALLBACKプログラムのプログラムとポート番号はSETCLIENTID操作の一部として、クライアントによって提供されるため、クライアントのインスタンス化の生活のために固定されています。
The COMPOUND procedure provides the opportunity for better performance within high latency networks. The client can avoid cumulative latency of multiple RPCs by combining multiple dependent operations into a single COMPOUND procedure. A compound operation may provide for protocol simplification by allowing the client to combine basic procedures into a single request that is customized for the client's environment.
COMPOUND手順は、高遅延ネットワーク内のパフォーマンス向上のための機会を提供します。クライアントは、単一の化合物の手順に複数の依存の操作を組み合わせることにより、複数のRPCの累積遅延を回避することができます。化合物の操作は、クライアントは、クライアントの環境に合わせてカスタマイズされた単一の要求に基本的な手順を組み合わせてできるようにすることで、プロトコルの簡素化を提供することができます。
The CB_COMPOUND procedure precisely parallels the features of COMPOUND as described above.
上記のようにCB_COMPOUND手順は正確化合物の機能に匹敵します。
The basics of the COMPOUND procedures construction is:
COMPOUND手順の構築の基本は次のとおりです。
+-----------+-----------+-----------+--
| op + args | op + args | op + args |
+-----------+-----------+-----------+--
and the reply looks like this:
そして、返事は次のようになります。
+------------+-----------------------+-----------------------+--
|last status | status + op + results | status + op + results |
+------------+-----------------------+-----------------------+--
The server will process the COMPOUND procedure by evaluating each of the operations within the COMPOUND procedure in order. Each component operation consists of a 32 bit operation code, followed by the argument of length determined by the type of operation. The results of each operation are encoded in sequence into a reply buffer. The results of each operation are preceded by the opcode and a status code (normally zero). If an operation results in a non-zero status code, the status will be encoded and evaluation of the compound sequence will halt and the reply will be returned. Note that evaluation stops even in the event of "non error" conditions such as NFS4ERR_SAME.
サーバは、注文中の化合物のプロシージャ内の各操作を評価することにより、化合物手続きを処理します。各コンポーネントの動作は、操作の種類によって決定される長さの引数に続く32ビットのオペコードからなります。各演算の結果が応答バッファ内に順に符号化されます。各演算の結果がオペコードとステータスコード（通常はゼロ）が先行しています。ゼロ以外のステータスコードの動作結果場合、ステータスは、符号化され、化合物配列の評価は停止し、応答が返されます。評価がさえ、このようなNFS4ERR_SAMEなどの「非エラー」の条件の場合に停止することに注意してください。
There are no atomicity requirements for the operations contained within the COMPOUND procedure. The operations being evaluated as part of a COMPOUND request may be evaluated simultaneously with other COMPOUND requests that the server receives.
COMPOUND手順内に含まれる操作にはアトミック要件はありません。複合要求の一部として評価されている操作は、サーバーが受信した他の化合物の要求と同時に評価することができます。
It is the client's responsibility for recovering from any partially completed COMPOUND procedure. Partially completed COMPOUND procedures may occur at any point due to errors such as NFS4ERR_RESOURCE and NFS4ERR_LONG_DELAY. This may occur even given an otherwise valid operation string. Further, a server reboot which occurs in the middle of processing a COMPOUND procedure may leave the client with the difficult task of determining how far COMPOUND processing has proceeded. Therefore, the client should avoid overly complex COMPOUND procedures in the event of the failure of an operation within the procedure.
これは、任意の部分的に完成されたCOMPOUND手順から回復するためのクライアントの責任です。部分的に完成したCOMPOUND手順は、NFS4ERR_RESOURCEとNFS4ERR_LONG_DELAYなどのエラーに起因する任意の時点で起こり得ます。これはさえそうでない場合は有効な操作文字列与え発生する可能性があります。さらに、COMPOUND手順の処理の途中で発生するサーバーの再起動がはるかCOMPOUND処理が進んでいるかを決定するのは困難な作業でクライアントを残すことができます。そのため、クライアントは、プロシージャ内の動作障害が発生した場合に、過度に複雑なCOMPOUND手順を避ける必要があります。
Each operation assumes a "current" and "saved" filehandle that is available as part of the execution context of the compound request. Operations may set, change, or return the current filehandle. The "saved" filehandle is used for temporary storage of a filehandle value and as operands for the RENAME and LINK operations.
各操作は、複合要求の実行コンテキストの一部として利用可能である「現在の」および「保存」ファイルハンドルをとります。操作は、設定変更、または現在のファイルハンドルを返すことがあります。 「保存」ファイルハンドルは、ファイルハンドルの値を一時的に保存するためにと名前を変更し、LINK操作のオペランドとして使用されています。
NFS version 4 operations that modify the file system are synchronous. When an operation is successfully completed at the server, the client can depend that any data associated with the request is now on stable storage (the one exception is in the case of the file data in a WRITE operation with the UNSTABLE option specified).
ファイルシステムを変更するNFSバージョン4つの操作が同期しています。操作が正常にサーバーに完了すると、クライアントは、要求に関連付けられたすべてのデータは、安定したストレージ上に今あることを依存することができます（唯一の例外は、指定されたUNSTABLEオプションとWRITE操作でファイルデータの場合です）。
This implies that any previous operations within the same compound request are also reflected in stable storage. This behavior enables the client's ability to recover from a partially executed compound request which may resulted from the failure of the server. For example, if a compound request contains operations A and B and the server is unable to send a response to the client, depending on the progress the server made in servicing the request the result of both operations may be reflected in stable storage or just operation A may be reflected. The server must not have just the results of operation B in stable storage.
これは、同じ化合物の要求内の任意の以前の動作も安定したストレージに反映されていることを意味します。この動作は、サーバの障害に起因して部分的に実行する複合要求から回復するためのクライアントの能力を可能にします。例えば、化合物の要求は、操作AおよびBを含み、サーバは、クライアントに応答を送信することができない、両方の操作の結果は、安定な保存または単に操作に反映させることができる要求をサービスの進捗に応じてサーバ場合反射されてもよいです。サーバーは安定したストレージに操作Bの結果だけを持っていなければなりません。
The operations encoded in the COMPOUND procedure are identified by operation values. To avoid overlap with the RPC procedure numbers, operations 0 (zero) and 1 are not defined. Operation 2 is not defined but reserved for future use with minor versioning.
COMPOUND手順で符号化操作は、操作値によって識別されます。 RPCプロシージャ番号の重複を避けるために、操作0（ゼロ）と1が定義されていません。操作2が定義されているがマイナーバージョンとの将来の使用のために予約されていません。
SYNOPSIS
SYNOPSIS
<null>
<NULL>
ARGUMENT
引数
void;
無効;
RESULT
結果
void;
無効;
DESCRIPTION
DESCRIPTION
Standard NULL procedure. Void argument, void response. This procedure has no functionality associated with it. Because of this it is sometimes used to measure the overhead of processing a service request. Therefore, the server should ensure that no unnecessary work is done in servicing this procedure.
標準NULL手続き。ボイド引数、無効応答。この手順は、それに関連付けられた機能を持っていません。このため、時々、サービス要求の処理のオーバーヘッドを測定するために使用されます。そのため、サーバは不要な作業は、この手順を整備中で行われていないことを確認する必要があります。
ERRORS
エラー
None.
無し。
SYNOPSIS
SYNOPSIS
compoundargs -> compoundres
compoundargs - > compoundres
ARGUMENT
引数
union nfs_argop4 switch (nfs_opnum4 argop) {
case <OPCODE>: <argument>;
...
}; struct COMPOUND4args {
utf8string tag;
uint32_t minorversion;
nfs_argop4 argarray<>;
};
RESULT
結果
union nfs_resop4 switch (nfs_opnum4 resop){
case <OPCODE>: <result>;
...
};
struct COMPOUND4res {
nfsstat4 status;
utf8string tag;
nfs_resop4 resarray<>;
};
DESCRIPTION
DESCRIPTION
The COMPOUND procedure is used to combine one or more of the NFS operations into a single RPC request. The main NFS RPC program has two main procedures: NULL and COMPOUND. All other operations use the COMPOUND procedure as a wrapper.
COMPOUND手順は、単一のRPC要求にNFS操作の1つまたは複数を組み合わせるために使用されます。 NULLとCOMPOUND：メインNFS RPCプログラムは、主に2つの手順があります。他のすべての操作は、ラッパーとしてCOMPOUNDプロシージャを使用します。
The COMPOUND procedure is used to combine individual operations into a single RPC request. The server interprets each of the operations in turn. If an operation is executed by the server and the status of that operation is NFS4_OK, then the next operation in the COMPOUND procedure is executed. The server continues this process until there are no more operations to be executed or one of the operations has a status value other than NFS4_OK.
COMPOUND手順は、単一のRPC要求に個々の操作を組み合わせるために使用されます。サーバは、順番にそれぞれの操作を解釈します。動作は、サーバによって実行され、その操作のステータスがNFS4_OKである場合、COMPOUND手順における次の動作が実行されます。が実行されるべきそれ以上の操作がされないかのいずれかの操作がNFS4_OK以外の状態値を有するまで、サーバは、このプロセスを継続します。
In the processing of the COMPOUND procedure, the server may find that it does not have the available resources to execute any or all of the operations within the COMPOUND sequence. In this case, the error NFS4ERR_RESOURCE will be returned for the particular operation within the COMPOUND procedure where the resource exhaustion occurred. This assumes that all previous operations within the COMPOUND sequence have been evaluated successfully. The results for all of the evaluated operations must be returned to the client.
COMPOUND手順の処理では、サーバはそれがCOMPOUND配列内の操作のいずれか、またはすべてを実行するために使用可能なリソースを持っていないことがあります。この場合、エラーNFS4ERR_RESOURCEは、リソースの枯渇が発生しCOMPOUNDプロシージャ内の特定の操作のために返されます。これは、化合物配列内のすべての以前の操作が正常に評価されていることを前提としています。評価したすべての操作の結果はクライアントに返さなければなりません。
The COMPOUND arguments contain a "minorversion" field. The initial and default value for this field is 0 (zero). This field will be used by future minor versions such that the client can communicate to the server what minor version is being requested.
COMPOUNDの引数は「MINORVERSION」フィールドが含まれています。このフィールドの初期およびデフォルト値は0（ゼロ）です。このフィールドは、クライアントが要求されているマイナーバージョンをサーバーに伝えることができるように、将来のマイナーバージョンによって使用されます。
If the server receives a COMPOUND procedure with a minorversion field value that it does not support, the server MUST return an error of NFS4ERR_MINOR_VERS_MISMATCH and a zero length resultdata array.
サーバがサポートしていないMINORVERSIONフィールド値を有する化合物の手続きを受信した場合、サーバはNFS4ERR_MINOR_VERS_MISMATCHの誤差とゼロ長resultdata配列を返さなければなりません。
Contained within the COMPOUND results is a "status" field. If the results array length is non-zero, this status must be equivalent to the status of the last operation that was executed within the COMPOUND procedure. Therefore, if an operation incurred an error then the "status" value will be the same error value as is being returned for the operation that failed.
COMPOUND結果に含まれる「状態」フィールドです。結果の配列の長さがゼロでない場合、このステータスはCOMPOUND手順の中で実行された最後の操作の状態と同等でなければなりません。操作がエラーを発生した場合、したがって、次に「状態」の値は、失敗した操作のために返される同じエラー値となります。
Note that operations, 0 (zero) and 1 (one) are not defined for the COMPOUND procedure. If the server receives an operation array with either of these included, an error of NFS4ERR_NOTSUPP must be returned. Operation 2 is not defined but reserved for future definition and use with minor versioning. If the server receives a operation array that contains operation 2 and the minorversion field has a value of 0 (zero), an error of NFS4ERR_NOTSUPP is returned. If an operation array contains an operation 2 and the minorversion field is non-zero and the server does not support the minor version, the server returns an error of NFS4ERR_MINOR_VERS_MISMATCH. Therefore, the NFS4ERR_MINOR_VERS_MISMATCH error takes precedence over all other errors.
操作、0（ゼロ）と1（1）はCOMPOUND手順のために定義されていないことに留意されたいです。サーバが含まれ、これらのいずれかで操作配列を受信した場合、NFS4ERR_NOTSUPPの誤りを返さなければなりません。操作2が定義されているが、将来の定義のために予約し、マイナーバージョンで使用されていません。サーバが動作2を含み、MINORVERSIONフィールドが0（ゼロ）の値を有する動作アレイを受信した場合、NFS4ERR_NOTSUPPのエラーが返されます。操作配列が操作2を含んでおり、MINORVERSIONフィールドがゼロでないと、サーバがマイナーバージョンをサポートしていない場合、サーバーはNFS4ERR_MINOR_VERS_MISMATCHのエラーを返します。したがって、NFS4ERR_MINOR_VERS_MISMATCHエラーは、他のすべてのエラーよりも優先されます。
IMPLEMENTATION
実装
Note that the definition of the "tag" in both the request and response are left to the implementor. It may be used to summarize the content of the compound request for the benefit of packet sniffers and engineers debugging implementations.
要求と応答の両方で「タグ」の定義は実装者に任されることに注意してください。パケットスニファおよび実装のデバッグ技術の利益のために化合物の要求の内容を要約するために使用することができます。
Since an error of any type may occur after only a portion of the operations have been evaluated, the client must be prepared to recover from any failure. If the source of an NFS4ERR_RESOURCE error was a complex or lengthy set of operations, it is likely that if the number of operations were reduced the server would be able to evaluate them successfully. Therefore, the client is responsible for dealing with this type of complexity in recovery.
操作の一部のみが評価された後、任意のタイプのエラーが発生する可能性があるので、クライアントは、任意の障害から回復するために用意されなければなりません。 NFS4ERR_RESOURCEエラーの原因が業務の複雑または長いセットした場合は、操作の数が減少した場合、サーバーが正常にそれらを評価することができるだろうと思われます。そのため、クライアントは回復における複雑さのこのタイプを扱うための責任があります。
ERRORS
エラー
All errors defined in the protocol
プロトコルで定義されたすべてのエラー
SYNOPSIS
SYNOPSIS
(cfh), accessreq -> supported, accessrights
（CFH）、accessreq - >サポート、て、AccessRights
ARGUMENT
引数
const ACCESS4_READ = 0x00000001;
const ACCESS4_LOOKUP = 0x00000002;
const ACCESS4_MODIFY = 0x00000004;
const ACCESS4_EXTEND = 0x00000008;
const ACCESS4_DELETE = 0x00000010;
const ACCESS4_EXECUTE = 0x00000020;
struct ACCESS4args {
/* CURRENT_FH: object */
uint32_t access;
};
RESULT
結果
struct ACCESS4resok {
uint32_t supported;
uint32_t access;
};
union ACCESS4res switch (nfsstat4 status) {
case NFS4_OK:
ACCESS4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
ACCESS determines the access rights that a user, as identified by the credentials in the RPC request, has with respect to the file system object specified by the current filehandle. The client encodes the set of access rights that are to be checked in the bit mask "access". The server checks the permissions encoded in the bit mask. If a status of NFS4_OK is returned, two bit masks are included in the response. The first, "supported", represents the access rights for which the server can verify reliably. The second, "access", represents the access rights available to the user for the filehandle provided. On success, the current filehandle retains its value.
ACCESSは、RPC要求に資格情報によって識別されるユーザは、現在のファイルハンドルに指定されたファイル・システム・オブジェクトに対して有するアクセス権を決定します。クライアントは、ビットマスク「アクセス」にチェックされるアクセス権のセットを符号化します。サーバはビットマスクで符号化権限をチェックします。 NFS4_OKのステータスが返された場合、2枚のビットマスクが応答に含まれています。 、まず、「サポート」は、サーバが確実に確認することができますするアクセス権を表します。二、「アクセス」、提供ファイルハンドルのためにユーザに利用可能なアクセス権を表します。成功すると、現在のファイルハンドルは、その値を保持します。
Note that the supported field will contain only as many values as was originally sent in the arguments. For example, if the client sends an ACCESS operation with only the ACCESS4_READ value set and the server supports this value, the server will return only ACCESS4_READ even if it could have reliably checked other values.
元々の引数に送られたとしてサポートフィールドだけのように多くの値が含まれていることに注意してください。クライアントは設定のみACCESS4_READ値にアクセス動作を送信し、サーバーがこの値をサポートしている場合たとえば、サーバーは、それが確実に他の値をチェックすることができた場合でも、唯一のACCESS4_READ戻ります。
The results of this operation are necessarily advisory in nature. A return status of NFS4_OK and the appropriate bit set in the bit mask does not imply that such access will be allowed to the file system object in the future. This is because access rights can be revoked by the server at any time.
この操作の結果は、自然の中で必然的に助言しています。 NFS4_OKの戻りステータスとビットマスクに設定された適切なビットは、そのようなアクセスは、将来的にファイル・システム・オブジェクトに許可されることを意味するものではありません。アクセス権限は、いつでもサーバーによって取り消すことができるからです。
The following access permissions may be requested:
以下のアクセス許可を要求することができます。
ACCESS4_READ Read data from file or read a directory.
ACCESS4_READ読むデータファイルまたはディレクトリをお読みください。
ACCESS4_LOOKUP Look up a name in a directory (no meaning for non-directory objects).
ACCESS4_LOOKUPディレクトリ（非ディレクトリオブジェクトのための意味無し）で名前を検索します。
ACCESS4_MODIFY Rewrite existing file data or modify existing directory entries.
既存のファイルのデータを書き換えたり、既存のディレクトリエントリを変更ACCESS4_MODIFY。
ACCESS4_EXTEND Write new data or add directory entries.
ACCESS4_EXTENDは、新しいデータを書き込むか、ディレクトリエントリを追加します。
ACCESS4_DELETE Delete an existing directory entry (no meaning for non-directory objects).
ACCESS4_DELETEは、既存のディレクトリエントリ（非ディレクトリオブジェクトのための意味しない）を削除します。
ACCESS4_EXECUTE Execute file (no meaning for a directory).
ACCESS4_EXECUTEは、ファイル（ディレクトリの意味無し）を実行します。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
For the NFS version 4 protocol, the use of the ACCESS procedure when opening a regular file is deprecated in favor of using OPEN.
NFSバージョン4プロトコルの場合、通常のファイルを開くアクセス手順の使用は、OPEN使用しての賛成で廃止されました。
In general, it is not sufficient for the client to attempt to deduce access permissions by inspecting the uid, gid, and mode fields in the file attributes or by attempting to interpret the contents of the ACL attribute. This is because the server may perform uid or gid mapping or enforce additional access control restrictions. It is also possible that the server may not be in the same ID space as the client. In these cases (and perhaps others), the client can not reliably perform an access check with only current file attributes.
クライアントがファイル属性でUID、GID、およびモードフィールドを検査することによって、またはACL属性の内容を解釈しようとすることで、アクセス権限を推測しようとするために一般的には、それは十分ではありません。サーバーは、UIDまたはGIDマッピングを実行するか、追加のアクセス制御制限を強制する可能性があるためです。サーバがクライアントと同じIDスペースにないかもしれないことも可能です。 （おそらく他）これらの例では、クライアントは確実にのみ、現在のファイル属性とアクセスチェックを実行することはできません。
In the NFS version 2 protocol, the only reliable way to determine whether an operation was allowed was to try it and see if it succeeded or failed. Using the ACCESS procedure in the NFS version 4 protocol, the client can ask the server to indicate whether or not one or more classes of operations are permitted. The ACCESS operation is provided to allow clients to check before doing a series of operations which will result in an access failure. The OPEN operation provides a point where the server can verify access to the file object and method to return that information to the client. The ACCESS operation is still useful for directory operations or for use in the case the UNIX API "access" is used on the client.
NFSバージョン2プロトコルでは、操作が許可されたかどうかを判断する唯一の確実な方法は、それを試してみて、それが成功したか失敗したかどうかを確認することでした。 NFSバージョン4プロトコルでアクセス手順を使用して、クライアントは操作の1つまたは複数のクラスが許可されているかどうかを示すために、サーバに依頼することができます。アクセス動作は、クライアントがアクセス障害につながる一連の操作を行う前にチェックできるようにするために提供されます。 OPEN操作はサーバがクライアントに情報を返すためにファイルオブジェクトとメソッドへのアクセスを確認することができますポイントを提供します。アクセス動作は、まだディレクトリ操作用またはUNIX用API「アクセス」は、クライアント上で使用する場合に使用するのに便利です。
The information returned by the server in response to an ACCESS call is not permanent. It was correct at the exact time that the server performed the checks, but not necessarily afterwards. The server can revoke access permission at any time.
アクセスの呼び出しに応じてサーバから返された情報は永久的ではありません。それは必ずしも必要ではないが、その後、サーバがチェックを行って正確な時間で正しかったです。サーバーは、いつでもアクセス許可を取り消すことができます。
The client should use the effective credentials of the user to build the authentication information in the ACCESS request used to determine access rights. It is the effective user and group credentials that are used in subsequent read and write operations.
クライアントは、アクセス権を決定するために使用するアクセス要求で認証情報を構築するために、ユーザーの効果的な資格情報を使用する必要があります。これは、その後の読み取りおよび書き込み操作に使用されている有効なユーザおよびグループの資格情報です。
Many implementations do not directly support the ACCESS4_DELETE permission. Operating systems like UNIX will ignore the ACCESS4_DELETE bit if set on an access request on a non-directory object. In these systems, delete permission on a file is determined by the access permissions on the directory in which the file resides, instead of being determined by the permissions of the file itself. Therefore, the mask returned enumerating which access rights can be determined will have the ACCESS4_DELETE value set to 0. This indicates to the client that the server was unable to check that particular access right. The ACCESS4_DELETE bit in the access mask returned will then be ignored by the client.
多くの実装では、直接ACCESS4_DELETE許可をサポートしていません。非ディレクトリ・オブジェクトに対するアクセス要求に設定した場合、UNIXのようなオペレーティングシステムはACCESS4_DELETEビットを無視します。これらのシステムでは、ファイルのアクセス許可を削除する代わりに、ファイル自体の権限によって決定されるのファイルが存在するディレクトリへのアクセス権限によって決定されます。そのため、マスクは、これは、サーバーがその特定のアクセス権を確認することができなかったことをクライアントに指示する0に設定ACCESS4_DELETE値を持つことになります判断することができる権利にアクセス列挙を返しました。返されたアクセスマスクでACCESS4_DELETEビットは、クライアントによって無視されます。
ERRORS
エラー
NFS4ERR_ACCES
NFS4ERR_BADHANDLE
NFS4ERR_DELAY
NFS4ERR_FHEXPIRED
NFS4ERR_IO
NFS4ERR_MOVED
NFS4ERR_NOFILEHANDLE
NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT
NFS4ERR_STALE
NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), seqid, stateid -> stateid
（CFH）、SEQID、のstateid - >のstateid
ARGUMENT
引数
struct CLOSE4args {
/* CURRENT_FH: object */
seqid4 seqid
stateid4 stateid;
};
RESULT
結果
union CLOSE4res switch (nfsstat4 status) {
case NFS4_OK:
stateid4 stateid;
default:
void;
};
DESCRIPTION
DESCRIPTION
The CLOSE operation releases share reservations for the file as specified by the current filehandle. The share reservations and other state information released at the server as a result of this CLOSE is only associated with the supplied stateid. The sequence id provides for the correct ordering. State associated with other OPENs is not affected.
現在のファイルハンドルで指定されCLOSE操作は、ファイルの共有の予約を解放します。共有予約このCLOSEの結果としてサーバで放出他の状態情報のみ供給のstateidと関連しています。シーケンスIDは、正しい順序付けのために用意されています。他のOPENsに関連した状態は影響を受けません。
If record locks are held, the client SHOULD release all locks before issuing a CLOSE. The server MAY free all outstanding locks on CLOSE but some servers may not support the CLOSE of a file that still has record locks held. The server MUST return failure if any locks would exist after the CLOSE.
レコードロックが保持されている場合、クライアントはCLOSEを発行する前に、すべてのロックを解除しなければなりません。サーバーは、CLOSE上のすべての未解決のロックを解放するかもしれませんが、いくつかのサーバは、まだ開催されたレコードロックを持っているファイルのCLOSEをサポートしていないかもしれません。すべてのロックは、CLOSEの後に存在するならば、サーバーは失敗を返さなければなりません。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_BAD_SEQID NFS4ERR_BAD_STATEID NFS4ERR_DELAY
NFS4ERR_BADHANDLE NFS4ERR_BAD_SEQID NFS4ERR_BAD_STATEID NFS4ERR_DELAY
NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_ISDIR NFS4ERR_LEASE_MOVED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID
NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_ISDIR NFS4ERR_LEASE_MOVED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID
SYNOPSIS
SYNOPSIS
(cfh), offset, count -> verifier
（CFH）、オフセット、カウント - >検証
ARGUMENT
引数
struct COMMIT4args {
/* CURRENT_FH: file */
offset4 offset;
count4 count;
};
RESULT
結果
struct COMMIT4resok {
verifier4 writeverf;
};
union COMMIT4res switch (nfsstat4 status) {
case NFS4_OK:
COMMIT4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The COMMIT operation forces or flushes data to stable storage for the file specified by the current file handle. The flushed data is that which was previously written with a WRITE operation which had the stable field set to UNSTABLE4.
現在のファイルハンドルで指定されたファイルのために安定したストレージに操作力やフラッシュのデータをコミットします。フラッシュされたデータは、以前UNSTABLE4に安定したフィールドのセットを持っていたWRITE操作で書かれたものです。
The offset specifies the position within the file where the flush is to begin. An offset value of 0 (zero) means to flush data starting at the beginning of the file. The count specifies the number of bytes of data to flush. If count is 0 (zero), a flush from offset to the end of the file is done.
オフセットは、フラッシュが開始するファイル内の位置を指定します。 0（ゼロ）のオフセット値は、ファイルの先頭からデータをフラッシュすることを意味します。カウントは、フラッシュへのデータのバイト数を指定します。カウントが0（ゼロ）の場合、ファイルの最後にオフセットからのフラッシュが行われます。
The server returns a write verifier upon successful completion of the COMMIT. The write verifier is used by the client to determine if the server has restarted or rebooted between the initial WRITE(s) and the COMMIT. The client does this by comparing the write verifier returned from the initial writes and the verifier returned by the COMMIT procedure. The server must vary the value of the write verifier at each server event or instantiation that may lead to a loss of uncommitted data. Most commonly this occurs when the server is rebooted; however, other events at the server may result in uncommitted data loss as well.
サーバーは、COMMITが正常に完了すると、書き込みベリファイアを返します。書き込みベリファイアは、サーバが再起動または初期WRITE（S）とCOMMITの間再起動しているかどうかを決定するためにクライアントによって使用されます。クライアントは、最初の書き込みとCOMMITプロシージャによって返された検証者から返された書き込みベリファイアを比較することによって、これを行います。サーバは、コミットされていないデータの損失につながる可能性があり、各サーバイベントまたはインスタンスに書き込み検証の値を変更しなければなりません。サーバーが再起動されたときに最も一般的には、これは発生します。ただし、サーバーで他のイベントも同様にコミットされていないデータが失われることがあります。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
The COMMIT procedure is similar in operation and semantics to the POSIX fsync(2) system call that synchronizes a file's state with the disk (file data and metadata is flushed to disk or stable storage). COMMIT performs the same operation for a client, flushing any unsynchronized data and metadata on the server to the server's disk or stable storage for the specified file. Like fsync(2), it may be that there is some modified data or no modified data to synchronize. The data may have been synchronized by the server's normal periodic buffer synchronization activity. COMMIT should return NFS4_OK, unless there has been an unexpected error.
COMMIT手順は、POSIX FSYNCディスクにファイルの状態を同期させる（ファイルデータとメタデータがディスクまたは安定記憶にフラッシュされる）、（2）システムコールの動作と意味論に類似しています。 COMMIT指定されたファイルは、サーバーのディスクにサーバーまたは安定したストレージ上の任意の非同期のデータとメタデータをフラッシュする、クライアントのために同じ操作を実行します。 FSYNCように（2）、それはいくつかの変更されたデータ又は同期させる無修正されたデータが存在することであってもよいです。データは、サーバーの正常な周期的なバッファ同期活動で同期されている可能性があります。予期せぬエラーがあった場合を除き、NFS4_OKを返す必要がCOMMIT。
COMMIT differs from fsync(2) in that it is possible for the client to flush a range of the file (most likely triggered by a buffer-reclamation scheme on the client before file has been completely written).
クライアントがファイルの範囲を（ファイルが完全に書き込まれる前に、最も可能性の高いクライアント上のバッファ・再生スキームによってトリガ）フラッシュすることが可能であるという点ではfsync（2）とは異なるがCOMMIT。
The server implementation of COMMIT is reasonably simple. If the server receives a full file COMMIT request, that is starting at offset 0 and count 0, it should do the equivalent of fsync()'ing the file. Otherwise, it should arrange to have the cached data in the range specified by offset and count to be flushed to stable storage. In both cases, any metadata associated with the file must be flushed to stable storage before returning. It is not an error for there to be nothing to flush on the server. This means that the data and metadata that needed to be flushed have already been flushed or lost during the last server failure.
COMMITのサーバの実装は合理的に簡単です。サーバーは、完全なファイルがCOMMIT要求を受けた場合は0をオフセットし、0カウントで、それが開始され、それはFSYNCの同等の（） 'ファイルをINGのを行う必要があります。それ以外の場合は、offsetで指定した範囲のキャッシュされたデータを持っており、安定したストレージにフラッシュされるようにカウントするように手配しなければなりません。どちらの場合も、ファイルに関連付けられたすべてのメタデータが戻る前に、安定したストレージにフラッシュする必要があります。サーバー上で洗い流すことは何もないことはエラーではありません。これはフラッシュするために必要なデータおよびメタデータがすでに最後のサーバ障害時のフラッシュまたは失われていることを意味します。
The client implementation of COMMIT is a little more complex. There are two reasons for wanting to commit a client buffer to stable storage. The first is that the client wants to reuse a buffer. In this case, the offset and count of the buffer are sent to the server in the COMMIT request. The server then flushes any cached data based on the offset and count, and flushes any metadata associated with the file. It then returns the status of the flush and the write verifier. The other reason for the client to generate a COMMIT is for a full file flush, such as may be done at close. In this case, the client would gather all of the buffers for this file that contain uncommitted data, do the COMMIT operation with an offset of 0 and count of 0, and then free all of those buffers. Any other dirty buffers would be sent to the server in the normal fashion.
COMMITのクライアントの実装はもう少し複雑です。安定したストレージにクライアントバッファをコミットしたいのための2つの理由があります。最初は、クライアントがバッファを再利用したいということです。この場合、オフセットおよびバッファのカウントがCOMMITリクエストでサーバーに送信されます。次に、サーバーはオフセットとカウントに基づいてキャッシュされたデータをフラッシュし、ファイルに関連付けられたすべてのメタデータをフラッシュします。その後、フラッシュやライト・ベリファイアの状態を返します。 COMMITを生成するためのクライアントのための他の理由は、近くで行うことができるよう、完全なファイルのフラッシュのためです。この場合、クライアントは0の0カウントのオフセット、およびそれらのバッファをすべて、その後自由にCOMMIT操作を行い、コミットされていないデータが含まれているこのファイルのバッファのすべてを収集します。その他のダーティバッファは、通常の方法でサーバに送信されます。
After a buffer is written by the client with the stable parameter set to UNSTABLE4, the buffer must be considered as modified by the client until the buffer has either been flushed via a COMMIT operation or written via a WRITE operation with stable parameter set to FILE_SYNC4 or DATA_SYNC4. This is done to prevent the buffer from being freed and reused before the data can be flushed to stable storage on the server.
バッファがUNSTABLE4に設定され、安定したパラメータを用いてクライアントによって書き込まれた後にクライアントによって修正され、バッファがFILE_SYNC4に安定したパラメータセットとWRITE動作を介して操作または書き込みをCOMMITまたは介しフラッシュされたかまで、バッファを考慮しなければなりませんDATA_SYNC4。これは、データはサーバー上の安定したストレージにフラッシュする前に解放され、再利用されることから、バッファを防止するために行われます。
When a response is returned from either a WRITE or a COMMIT operation and it contains a write verifier that is different than previously returned by the server, the client will need to retransmit all of the buffers containing uncommitted cached data to the server. How this is to be done is up to the implementor. If there is only one buffer of interest, then it should probably be sent back over in a WRITE request with the appropriate stable parameter. If there is more than one buffer, it might be worthwhile retransmitting all of the buffers in WRITE requests with the stable parameter set to UNSTABLE4 and then retransmitting the COMMIT operation to flush all of the data on the server to stable storage. The timing of these retransmissions is left to the implementor.
応答がWRITEかCOMMIT操作のいずれかから返されると、それは以前にサーバから返されたと異なる書き込み検証が含まれている場合、クライアントはサーバーにコミットされていないキャッシュされたデータを含む全てのバッファを再送信する必要があります。これを実行する方法を実装までです。関心の一つだけのバッファが存在する場合、それはおそらく、適切な安定したパラメータを使用してWRITE要求に背を超える送信する必要があります。複数のバッファが存在する場合、それはUNSTABLE4に設定し、安定したパラメータでWRITE要求内のバッファのすべてを再送して、安定したストレージにサーバー上のすべてのデータをフラッシュするCOMMIT操作を再送信する価値があるかもしれません。これらの再送信のタイミングは、実装者に任されています。
The above description applies to page-cache-based systems as well as buffer-cache-based systems. In those systems, the virtual memory system will need to be modified instead of the buffer cache.
上記の説明は、ページキャッシュベースのシステムと同様に、バッファ・キャッシュベースのシステムに適用されます。これらのシステムでは、仮想メモリシステムは、バッファ・キャッシュの代わりに変更する必要があります。
ERRORS
エラー
NFS4ERR_ACCES
NFS4ERR_BADHANDLE
NFS4ERR_FHEXPIRED
NFS4ERR_IO
NFS4ERR_ISDIR NFS4ERR_LOCKED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_ISDIR NFS4ERR_LOCKED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), name, type -> (cfh), change_info
（CFH）、名前、タイプ - >（CFH）、change_info
ARGUMENT
引数
union createtype4 switch (nfs_ftype4 type) {
case NF4LNK:
linktext4 linkdata;
case NF4BLK:
case NF4CHR:
specdata4 devdata;
case NF4SOCK:
case NF4FIFO:
case NF4DIR:
void;
};
struct CREATE4args {
/* CURRENT_FH: directory for creation */
component4 objname;
createtype4 objtype;
};
RESULT
結果
struct CREATE4resok {
change_info4 cinfo;
};
union CREATE4res switch (nfsstat4 status) {
case NFS4_OK:
CREATE4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The CREATE operation creates a non-regular file object in a directory with a given name. The OPEN procedure MUST be used to create a regular file.
CREATE操作は、指定した名前のディレクトリにある非正規ファイルオブジェクトを作成します。 OPEN手順は、通常のファイルを作成するために使用しなければなりません。
The objname specifies the name for the new object. If the objname has a length of 0 (zero), the error NFS4ERR_INVAL will be returned. The objtype determines the type of object to be created: directory, symlink, etc.
objnameには、新しいオブジェクトの名前を指定します。 objnameには0（ゼロ）の長さを有している場合、エラーNFS4ERR_INVALが返されます。ディレクトリ、シンボリックリンクなど：OBJTYPEは、作成するオブジェクトの種類を決定します
If an object of the same name already exists in the directory, the server will return the error NFS4ERR_EXIST.
同じ名前のオブジェクトがすでにディレクトリに存在する場合、サーバーはエラーNFS4ERR_EXISTを返します。
For the directory where the new file object was created, the server returns change_info4 information in cinfo. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the file object creation.
新しいファイルオブジェクトが作成されたディレクトリのために、サーバはcinfoの変化_info4情報を返します。前と後の変更属性はファイルオブジェクトの作成に関して原子論が得られた場合には変化_info4構造体の原子分野、意志が示すサーバ。
If the objname has a length of 0 (zero), or if objname does not obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned.
objnameには、UTF-8定義に従わない場合objnameには0（ゼロ）の長さを有する場合、または、エラーNFS4ERR_INVALが返されます。
The current filehandle is replaced by that of the new object.
現在のファイルハンドルは、新しいオブジェクトのものに置き換えられます。
IMPLEMENTATION
実装
If the client desires to set attribute values after the create, a SETATTR operation can be added to the COMPOUND request so that the appropriate attributes will be set.
クライアントが作成した後、属性値を設定したい場合、適切な属性が設定されるように、SETATTR操作はCOMPOUND要求に追加することができます。
ERRORS
エラー
NFS4ERR_ACCES
NFS4ERR_BADHANDLE
NFS4ERR_BADTYPE
NFS4ERR_DQUOT
NFS4ERR_EXIST
NFS4ERR_FHEXPIRED
NFS4ERR_INVAL
NFS4ERR_IO
NFS4ERR_MOVED
NFS4ERR_NAMETOOLONG
NFS4ERR_NOFILEHANDLE
NFS4ERR_NOSPC
NFS4ERR_NOTDIR
NFS4ERR_NOTSUPP
NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
clientid ->
ClientIDを - >
ARGUMENT
引数
struct DELEGPURGE4args {
clientid4 clientid;
};
RESULT
結果
struct DELEGPURGE4res {
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
Purges all of the delegations awaiting recovery for a given client. This is useful for clients which do not commit delegation information to stable storage to indicate that conflicting requests need not be delayed by the server awaiting recovery of delegation information.
与えられたクライアントのための回復を待っている代表団のすべてを消去します。これは矛盾する要求が委任情報の回復を待って、サーバーによって遅延される必要がないことを示すために、安定したストレージへの委任情報をコミットしていないクライアントのために有用です。
This operation should be used by clients that record delegation information on stable storage on the client. In this case, DELEGPURGE should be issued immediately after doing delegation recovery on all delegations know to the client. Doing so will notify the server that no additional delegations for the client will be recovered allowing it to free resources, and avoid delaying other clients who make requests that conflict with the unrecovered delegations. The set of delegations known to the server and the client may be different. The reason for this is that a client may fail after making a request which resulted in delegation but before it received the results and committed them to the client's stable storage.
この操作は、クライアント上の安定したストレージに記録委任情報というクライアントによって使用されなければなりません。この場合、DELEGPURGEはすぐにすべての代表団に委任リカバリを実行した後に発行されなければならないクライアントに知っています。そうすることで、クライアントのための追加の代表団は、リソースを解放することが可能に回復されませんサーバーに通知し、その未回収の代表団との競合要求を行う他のクライアントを遅らせる避けることができます。サーバとクライアントに知られている代表団のセットが異なる場合があります。この理由は、クライアントが委任が生じたが、それは結果を受信し、クライアントの安定した記憶領域にそれらをコミットする前に要求を行った後、失敗する可能性があることです。
ERRORS
エラー
NFS4ERR_RESOURCE
NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT NFS4ERR_STALE_CLIENTID
NFS4ERR_SERVERFAULT NFS4ERR_STALE_CLIENTID
SYNOPSIS
SYNOPSIS
stateid ->
stateid - >
ARGUMENT
引数
struct DELEGRETURN4args {
stateid4 stateid;
};
RESULT
結果
struct DELEGRETURN4res {
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
Returns the delegation represented by the given stateid.
与えられたstateidで表さ委任を返します。
ERRORS
エラー
NFS4ERR_BAD_STATEID
NFS4ERR_OLD_STATEID
NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT
NFS4ERR_STALE_STATEID
SYNOPSIS
SYNOPSIS
(cfh), attrbits -> attrbits, attrvals
（CFH）、attrbits - > attrbits、attrvals
ARGUMENT
引数
struct GETATTR4args {
/* CURRENT_FH: directory or file */
bitmap4 attr_request;
};
RESULT
結果
struct GETATTR4resok {
fattr4 obj_attributes;
};
union GETATTR4res switch (nfsstat4 status) {
case NFS4_OK:
GETATTR4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The GETATTR operation will obtain attributes for the file system object specified by the current filehandle. The client sets a bit in the bitmap argument for each attribute value that it would like the server to return. The server returns an attribute bitmap that indicates the attribute values for which it was able to return, followed by the attribute values ordered lowest attribute number first.
GETATTR操作は、現在のファイルハンドルで指定されたファイル・システム・オブジェクトの属性を取得します。クライアントは、サーバーが返すしたい各属性値のビットマップ引数のビットを設定します。サーバーは、最初に最低の属性番号を注文した属性値に続いて、それを返すことができた対象の属性値を示す属性ビットマップを返します。
The server must return a value for each attribute that the client requests if the attribute is supported by the server. If the server does not support an attribute or cannot approximate a useful value then it must not return the attribute value and must not set the attribute bit in the result bitmap. The server must return an error if it supports an attribute but cannot obtain its value. In that case no attribute values will be returned.
属性は、サーバーによってサポートされている場合、サーバーはクライアントの要求する各属性の値を返す必要があります。サーバーが属性をサポートしていないか、有益な値に近づけることができない場合、それは属性値を返さなければならないと、結果のビットマップ内の属性ビットを設定してはいけません。それは属性をサポートしていますが、その値を取得できない場合、サーバーはエラーを返す必要があります。その場合には何の属性値が返されません。
All servers must support the mandatory attributes as specified in the section "File Attributes".
セクション「ファイル属性」に指定されているすべてのサーバーが必須属性をサポートしている必要があります。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
ERRORS
エラー
NFS4ERR_ACCES
NFS4ERR_BADHANDLE
NFS4ERR_DELAY
NFS4ERR_FHEXPIRED
NFS4ERR_INVAL
NFS4ERR_IO
NFS4ERR_MOVED
NFS4ERR_NOFILEHANDLE
NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT
NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh) -> filehandle
（CFH） - >ファイルハンドル
ARGUMENT
引数
/* CURRENT_FH: */
void;
RESULT
結果
struct GETFH4resok {
nfs_fh4 object;
};
union GETFH4res switch (nfsstat4 status) {
case NFS4_OK:
GETFH4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
This operation returns the current filehandle value.
この操作は、現在のファイルハンドル値を返します。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
Operations that change the current filehandle like LOOKUP or CREATE do not automatically return the new filehandle as a result. For instance, if a client needs to lookup a directory entry and obtain its filehandle then the following request is needed.
LOOKUPのような現在のファイルハンドルを変更したり、CREATE操作は、自動的に結果として新しいファイルハンドルを返しません。例えば、クライアントがディレクトリエントリを検索し、次の要求が必要とされ、そのファイルハンドルを取得する必要がある場合。
PUTFH (directory filehandle)
LOOKUP (entry name)
GETFH
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED
NFS 4 Err_bdhandleのNAFの4 Err_fekspired
NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(sfh), (cfh), newname -> (cfh), change_info
（SFH）、（CFH）、NEWNAME - >（CFH）、change_info
ARGUMENT
引数
struct LINK4args {
/* SAVED_FH: source object */
/* CURRENT_FH: target directory */
component4 newname;
};
RESULT
結果
struct LINK4resok {
change_info4 cinfo;
};
union LINK4res switch (nfsstat4 status) {
case NFS4_OK:
LINK4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The LINK operation creates an additional newname for the file represented by the saved filehandle, as set by the SAVEFH operation, in the directory represented by the current filehandle. The existing file and the target directory must reside within the same file system on the server. On success, the current filehandle will continue to be the target directory.
現在のファイルハンドルによって表されるディレクトリに、SAVEFH操作によって設定されたLINK操作は、保存されたファイルハンドルによって表されるファイルのための追加NEWNAMEを作成します。既存のファイルとターゲット・ディレクトリは、サーバー上の同じファイルシステム内に存在する必要があります。成功すると、現在のファイルハンドルは、ターゲットディレクトリであり続けるだろう。
For the target directory, the server returns change_info4 information in cinfo. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the link creation.
ターゲットディレクトリの場合、サーバはcinfoの変化_info4情報を返します。前と後の変更属性がリンク作成に関して原子論が得られた場合には変化_info4構造体の原子分野、意志が示すサーバ。
If the newname has a length of 0 (zero), or if newname does not obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned.
NEWNAMEがUTF-8定義に従わない場合NEWNAMEは0（ゼロ）の長さを有する場合、または、エラーNFS4ERR_INVALが返されます。
IMPLEMENTATION
実装
Changes to any property of the "hard" linked files are reflected in all of the linked files. When a link is made to a file, the attributes for the file should have a value for numlinks that is one greater than the value before the LINK operation.
「ハード」リンクされたファイルの任意のプロパティを変更すると、リンクされたファイルのすべてに反映されています。リンクをファイルにするとき、ファイルの属性はLINK操作前の値より1大きいnumlinksの値を持つ必要があります。
The comments under RENAME regarding object and target residing on the same file system apply here as well. The comments regarding the target name applies as well.
同じファイルシステム上に存在するオブジェクトとターゲットに関するRENAME下のコメントはここにも適用されます。ターゲット名に関するコメントも同様に適用されます。
Note that symbolic links are created with the CREATE operation.
シンボリックリンクが作成操作で作成されていることに注意してください。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_DQUOT NFS4ERR_EXIST NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_ISDIR NFS4ERR_MLINK NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_NOTDIR NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC NFS4ERR_XDEV
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_DQUOT NFS4ERR_EXIST NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_ISDIR NFS4ERR_MLINK NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_NOTDIR NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC NFS4ERR_XDEV
SYNOPSIS
SYNOPSIS
(cfh) type, seqid, reclaim, stateid, offset, length -> stateid, access
（CFH）タイプ、SEQID、再利用、のstateid、オフセット、長さ - >のstateid、アクセス
ARGUMENT
引数
enum nfs4_lock_type {
READ_LT = 1,
WRITE_LT = 2,
READW_LT = 3, /* blocking read */
WRITEW_LT = 4 /* blocking write */ };
struct LOCK4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
seqid4 seqid;
bool reclaim;
stateid4 stateid;
offset4 offset; length4 length; };
RESULT
結果
struct LOCK4denied {
nfs_lockowner4 owner;
offset4 offset;
length4 length; };
union LOCK4res switch (nfsstat4 status) {
case NFS4_OK:
stateid4 stateid;
case NFS4ERR_DENIED:
LOCK4denied denied;
default:
void; };
DESCRIPTION
DESCRIPTION
The LOCK operation requests a record lock for the byte range specified by the offset and length parameters. The lock type is also specified to be one of the nfs4_lock_types. If this is a reclaim request, the reclaim parameter will be TRUE;
LOCK操作は、オフセットと長さのパラメータで指定されたバイト範囲のレコードロックを要求します。ロックタイプもnfs4_lock_typesの一つであることが指定されています。これは再利用要求がある場合は、再利用パラメータがTRUEになります。
Bytes in a file may be locked even if those bytes are not currently allocated to the file. To lock the file from a specific offset through the end-of-file (no matter how long the file actually is) use a length field with all bits set to 1 (one). To lock the entire file, use an offset of 0 (zero) and a length with all bits set to 1. A length of 0 is reserved and should not be used.
それらのバイトが現在のファイルに割り当てられていない場合でも、ファイル内のバイトをロックすることができます。ファイルの終わりを介して特定のオフセット（ファイルが実際にどのくらいの時間に関係なく）からファイルをロックするには1（1）に設定されたすべてのビットと長さフィールドを使用します。ファイル全体をロックするには、0（ゼロ）のオフセットと1 0の長さを設定されたすべてのビットの長さが確保され、使用されるべきではないを使用。
In the case that the lock is denied, the owner, offset, and length of a conflicting lock are returned.
ロックが拒否された場合に、競合するロックの所有者、オフセット、および長さが返されます。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
If the server is unable to determine the exact offset and length of the conflicting lock, the same offset and length that were provided in the arguments should be returned in the denied results. The File Locking section contains a full description of this and the other file locking operations.
サーバは競合ロックの正確なオフセットと長さを決定することができない場合は、引数に与えたのと同じオフセットと長さが拒否された結果で返されるべきです。ファイルのロックセクションでは、このの完全な説明や操作をロックし、他のファイルが含まれています。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_SEQID
NFS 4 Err_aksesのNAFの4 Err_bdhandleのNAFの4 Err_bad_sekind
NFS4ERR_BAD_STATEID NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_ISDIR NFS4ERR_LEASE_MOVED NFS4ERR_LOCK_RANGE NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_CLIENTID NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
NFS4ERR_BAD_STATEID NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_ISDIR NFS4ERR_LEASE_MOVED NFS4ERR_LOCK_RANGE NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_CLIENTID NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh) type, owner, offset, length -> {void, NFS4ERR_DENIED -> owner}
（CFH）タイプ、所有者、オフセット、長さ - > {ボイド、NFS4ERR_DENIED - >所有者}
ARGUMENT
引数
struct LOCKT4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
nfs_lockowner4 owner;
offset4 offset;
length4 length; };
RESULT
結果
union LOCKT4res switch (nfsstat4 status) {
case NFS4ERR_DENIED:
LOCK4denied denied;
case NFS4_OK:
void;
default:
void; };
DESCRIPTION
DESCRIPTION
The LOCKT operation tests the lock as specified in the arguments. If a conflicting lock exists, the owner, offset, and length of the conflicting lock are returned; if no lock is held, nothing other than NFS4_OK is returned.
LOCKT操作は、引数で指定されたロックをテストします。競合するロックが存在する場合、所有者は、オフセット、および競合ロックの長さが返されます。何もロックが保持されていない場合、NFS4_OK以外何も返されません。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
If the server is unable to determine the exact offset and length of the conflicting lock, the same offset and length that were provided in the arguments should be returned in the denied results. The File Locking section contains further discussion of the file locking mechanisms.
サーバは競合ロックの正確なオフセットと長さを決定することができない場合は、引数に与えたのと同じオフセットと長さが拒否された結果で返されるべきです。ファイルのロックセクションでは、ファイルロック機構のさらなる議論が含まれています。
LOCKT uses nfs_lockowner4 instead of a stateid4, as LOCK does, to identify the owner so that the client does not have to open the file to test for the existence of a lock.
LOCKTはLOCKがするように、クライアントはロックが存在するかどうかをテストするためのファイルを開く必要がないように、所有者を識別するために、stateid4の代わりにnfs_lockowner4使用しています。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_ISDIR NFS4ERR_LEASE_MOVED NFS4ERR_LOCK_RANGE NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_CLIENTID NFS4ERR_WRONGSEC
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_ISDIR NFS4ERR_LEASE_MOVED NFS4ERR_LOCK_RANGE NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_CLIENTID NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh) type, seqid, stateid, offset, length -> stateid
（CFH）タイプ、SEQID、のstateid、オフセット、長さ - >のstateid
ARGUMENT
引数
struct LOCKU4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
seqid4 seqid;
stateid4 stateid;
offset4 offset;
length4 length;
};
RESULT
結果
union LOCKU4res switch (nfsstat4 status) { case NFS4_OK:
組合LOCKU4resは（nfsstat4状態）{ケースNFS4_OKを切り替えます。
stateid4 stateid;
default:
void;
};
DESCRIPTION
DESCRIPTION
The LOCKU operation unlocks the record lock specified by the parameters.
LOCKU操作は、パラメータで指定されたレコードのロックを解除します。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
The File Locking section contains a full description of this and the other file locking procedures.
ファイルのロックセクションでは、このの完全な説明とその他のファイルのロック手順が含まれています。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_SEQID NFS4ERR_BAD_STATEID NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_LOCK_RANGE NFS4ERR_LEASE_MOVED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_CLIENTID NFS4ERR_STALE_STATEID
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_SEQID NFS4ERR_BAD_STATEID NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_LOCK_RANGE NFS4ERR_LEASE_MOVED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_CLIENTID NFS4ERR_STALE_STATEID
SYNOPSIS
SYNOPSIS
(cfh), filenames -> (cfh)
（CFH）、ファイル名 - >（CFH）
ARGUMENT
引数
struct LOOKUP4args {
/* CURRENT_FH: directory */ pathname4 path;
};
RESULT
結果
struct LOOKUP4res {
/* CURRENT_FH: object */
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
This operation LOOKUPs or finds a file system object starting from the directory specified by the current filehandle. LOOKUP evaluates the pathname contained in the array of names and obtains a new current filehandle from the final name. All but the final name in the list must be the names of directories.
この操作ルックアップまたは現在のファイルハンドルによって指定されたディレクトリから開始ファイル・システム・オブジェクトを見つけます。 LOOKUPは、名前の配列に含まれるパス名を評価し、最終的な名前から新しい現在のファイルハンドルを取得します。リストのすべてが、最終的な名前は、ディレクトリの名前でなければなりません。
If the pathname cannot be evaluated either because a component does not exist or because the client does not have permission to evaluate a component of the path, then an error will be returned and the current filehandle will be unchanged.
コンポーネントが存在しないため、パス名のいずれかを評価することができないか、クライアントがパスの構成要素を評価する権限を持っていないため、エラーが返され、現在のファイルハンドルは変更されません。場合
If the path is a zero length array, if any component does not obey the UTF-8 definition, or if any component in the path is of zero length, the error NFS4ERR_INVAL will be returned.
任意成分は、UTF-8定義に従わない場合、パスは長さゼロの配列である場合、パス内の任意の成分はゼロ長である場合、又は、エラーNFS4ERR_INVALが返されます。
IMPLEMENTATION
実装
If the client prefers a partial evaluation of the path then a sequence of LOOKUP operations can be substituted e.g.
クライアントがパスの部分評価を好む場合、LOOKUP操作のシーケンスは、例えば、置換されていてもよいです
PUTFH (directory filehandle)
LOOKUP "pub" "foo" "bar"
GETFH
or, if the client wishes to obtain the intermediate filehandles
または、クライアントが中間ファイルハンドルを取得したい場合
PUTFH (directory filehandle)
LOOKUP "pub"
GETFH
LOOKUP "foo"
GETFH
LOOKUP "bar"
GETFH
NFS version 4 servers depart from the semantics of previous NFS versions in allowing LOOKUP requests to cross mountpoints on the server. The client can detect a mountpoint crossing by comparing the fsid attribute of the directory with the fsid attribute of the directory looked up. If the fsids are different then the new directory is a server mountpoint. Unix clients that detect a mountpoint crossing will need to mount the server's filesystem. This needs to be done to maintain the file object identity checking mechanisms common to Unix clients.
NFSバージョン4台のサーバは、LOOKUP要求がサーバー上でマウントポイントを横断できるようにするには、以前のNFSバージョンの意味論から出発します。ディレクトリのFSID属性を持つディレクトリのFSID属性を比較することにより、マウントポイントの交差を検出することができ、クライアントは見上げました。 fsidsが異なる場合は、新しいディレクトリがサーバマウントポイントです。マウントポイントの交差点を検出するUNIXクライアントは、サーバのファイルシステムをマウントする必要があります。これは、UNIXクライアントに共通のメカニズムをチェックするファイルオブジェクトのアイデンティティを維持するために行われる必要があります。
Servers that limit NFS access to "shares" or "exported" filesystems should provide a pseudo-filesystem into which the exported filesystems can be integrated, so that clients can browse the server's name space. The clients view of a pseudo filesystem will be limited to paths that lead to exported filesystems.
クライアントは、サーバーの名前空間を参照することができるように、「株式」または「エクスポート」ファイルシステムへのNFSアクセスを制限するサーバーは、エクスポートされたファイルシステムを統合することができますその中に擬似ファイルシステムを提供する必要があります。擬似ファイルシステムのクライアントビューは、エクスポートファイルシステムに至る経路に限定されるであろう。
Note: previous versions of the protocol assigned special semantics to the names "." and "..". NFS version 4 assigns no special semantics to these names. The LOOKUPP operator must be used to lookup a parent directory.
注意：名前に特別な意味を割り当てるプロトコルの以前のバージョン「」そして、 ".."。 NFSバージョン4は、これらの名前に特別な意味を割り当てません。 LOOKUPP演算子は、親ディレクトリを検索するために使用する必要があります。
Note that this procedure does not follow symbolic links. The client is responsible for all parsing of filenames including filenames that are modified by symbolic links encountered during the lookup process.
この手順は、シンボリックリンクをたどらないことに注意してください。クライアントは、ルックアップ・プロセス中に遭遇したシンボリックリンクで変更されたファイル名を含むファイル名のすべての解析を担当しています。
If the current file handle supplied is not a directory but a symbolic link, the error NFS4ERR_SYMLINK is returned as the error. For all other non-directory file types, the error NFS4ERR_NOTDIR is returned.
供給される電流のファイルハンドルがディレクトリが、シンボリックリンクではない場合は、エラーNFS4ERR_SYMLINKはエラーとして返されます。他のすべてのディレクトリ以外のファイルタイプの場合は、エラーNFS4ERR_NOTDIRが返されます。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_SYMLINK NFS4ERR_WRONGSEC
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_SYMLINK NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh) -> (cfh)
（CFH） - >（CFH）
ARGUMENT
引数
/* CURRENT_FH: object */
void;
RESULT
結果
struct LOOKUPP4res {
/* CURRENT_FH: directory */
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
The current filehandle is assumed to refer to a regular directory or a named attribute directory. LOOKUPP assigns the filehandle for its parent directory to be the current filehandle. If there is no parent directory an NFS4ERR_ENOENT error must be returned. Therefore, NFS4ERR_ENOENT will be returned by the server when the current filehandle is at the root or top of the server's file tree.
現在のファイルハンドルは通常のディレクトリや名前付き属性のディレクトリを参照すると想定されます。 LOOKUPPは、現在のファイルハンドルであることを、その親ディレクトリのファイルハンドルを割り当てます。親ディレクトリが存在しない場合NFS4ERR_ENOENTエラーが返されなければなりません。現在のファイルハンドルは、ルートまたはサーバーのファイルツリーの最上部にあるときにそのため、NFS4ERR_ENOENTは、サーバーによって返されます。
IMPLEMENTATION
実装
As for LOOKUP, LOOKUPP will also cross mountpoints.
LOOKUPについては、LOOKUPもマウントポイントを横切ることになります。
If the current filehandle is not a directory or named attribute directory, the error NFS4ERR_NOTDIR is returned.
現在のファイルハンドルがディレクトリまたは名前付き属性ディレクトリでない場合は、エラーNFS4ERR_NOTDIRが返されます。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT
NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), fattr -> -
（CFH）、fattr - > -
ARGUMENT
引数
struct NVERIFY4args {
/* CURRENT_FH: object */
fattr4 obj_attributes;
};
RESULT
結果
struct NVERIFY4res {
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
This operation is used to prefix a sequence of operations to be performed if one or more attributes have changed on some filesystem object. If all the attributes match then the error NFS4ERR_SAME must be returned.
この操作は、1つ以上の属性は、いくつかのファイルシステムオブジェクトに変更した場合に実行する一連の操作の前に付けるために使用されます。すべての属性が一致した場合、エラーNFS4ERR_SAMEを返さなければなりません。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
This operation is useful as a cache validation operator. If the object to which the attributes belong has changed then the following operations may obtain new data associated with that object. For instance, to check if a file has been changed and obtain new data if it has:
この操作は、キャッシュ検証オペレーターとして有用です。属性が所属するオブジェクトが変更された場合は、以下の操作は、そのオブジェクトに関連付けられた新しいデータを得ることができます。たとえば、ファイルが変更されているかどうかを確認し、それが持っている場合、新たなデータを取得します：
PUTFH (public)
LOOKUP "pub" "foo" "bar"
NVERIFY attrbits attrs
READ 0 32767
In the case that a recommended attribute is specified in the NVERIFY operation and the server does not support that attribute for the file system object, the error NFS4ERR_NOTSUPP is returned to the client.
推奨属性がNVERIFY操作で指定され、サーバがファイル・システム・オブジェクトのためにその属性をサポートしていない場合は、エラーNFS4ERR_NOTSUPPがクライアントに返されます。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_SAME NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_SAME NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), claim, openhow, owner, seqid, access, deny -> (cfh), stateid, cinfo, rflags, open_confirm, delegation
（CFH）、請求、openhow、所有者、SEQID、アクセスは、拒否 - >（CFH）のstateid、CINFO、RFLAGS、オープン_CONFIRM、委任
ARGUMENT
引数
struct OPEN4args {
open_claim4 claim;
openflag4 openhow;
nfs_lockowner4 owner;
seqid4 seqid;
uint32_t share_access;
uint32_t share_deny;
};
enum createmode4 { UNCHECKED4 = 0, GUARDED4 = 1, EXCLUSIVE4 = 2 };
列挙createmode4 {UNCHECKED4 = 0、GUARDED4 = 1、EXCLUSIVE4 = 2}。
union createhow4 switch (createmode4 mode) {
case UNCHECKED4:
case GUARDED4:
fattr4 createattrs;
case EXCLUSIVE4:
verifier4 createverf;
}; enum opentype4 {
OPEN4_NOCREATE = 0,
OPEN4_CREATE = 1
};
union openflag4 switch (opentype4 opentype) {
case OPEN4_CREATE:
createhow4 how;
default:
void;
};
/* Next definitions used for OPEN delegation */
enum limit_by4 {
NFS_LIMIT_SIZE = 1,
NFS_LIMIT_BLOCKS = 2
/* others as needed */
};
struct nfs_modified_limit4 {
uint32_t num_blocks;
uint32_t bytes_per_block;
};
union nfs_space_limit4 switch (limit_by4 limitby) {
/* limit specified as file size */
case NFS_LIMIT_SIZE:
uint64_t filesize;
/* limit specified by number of blocks */
case NFS_LIMIT_BLOCKS:
nfs_modified_limit4 mod_blocks;
} ;
enum open_delegation_type4 { OPEN_DELEGATE_NONE = 0, OPEN_DELEGATE_READ = 1, OPEN_DELEGATE_WRITE = 2 };
列挙open_delegation_type4 {OPEN_DELEGATE_NONE = 0、OPEN_DELEGATE_READ = 1、OPEN_DELEGATE_WRITE = 2}。
enum open_claim_type4 { CLAIM_NULL = 0, CLAIM_PREVIOUS = 1, CLAIM_DELEGATE_CUR = 2, CLAIM_DELEGATE_PREV = 3 };
列挙open_claim_type4 {CLAIM_NULL = 0、CLAIM_PREVIOUS = 1、CLAIM_DELEGATE_CUR = 2、CLAIM_DELEGATE_PREV = 3}。
struct open_claim_delegate_cur4 {
pathname4 file; stateid4 delegate_stateid;
};
union open_claim4 switch (open_claim_type4 claim) {
/*
* No special rights to file. Ordinary OPEN of the specified file.
*/
case CLAIM_NULL:
/* CURRENT_FH: directory */
pathname4 file;
/*
* Right to the file established by an open previous to server
* reboot. File identified by filehandle obtained at that time
* rather than by name.
*/
case CLAIM_PREVIOUS:
/* CURRENT_FH: file being reclaimed */
uint32_t delegate_type;
/*
* Right to file based on a delegation granted by the server.
* File is specified by name.
*/
case CLAIM_DELEGATE_CUR:
/* CURRENT_FH: directory */
open_claim_delegate_cur4 delegate_cur_info;
/* Right to file based on a delegation granted to a previous boot
* instance of the client. File is specified by name.
*/
case CLAIM_DELEGATE_PREV:
/* CURRENT_FH: directory */
pathname4 file_delegate_prev;
};
RESULT
結果
struct open_read_delegation4 {
stateid4 stateid; /* Stateid for delegation*/
bool recall; /* Pre-recalled flag for
delegations obtained
by reclaim
(CLAIM_PREVIOUS) */
nfsace4 permissions; /* Defines users who don't
need an ACCESS call to
open for read */
}; struct open_write_delegation4 {
stateid4 stateid; /* Stateid for delegation*/
bool recall; /* Pre-recalled flag for
delegations obtained
by reclaim
(CLAIM_PREVIOUS) */
nfs_space_limit4 space_limit; /* Defines condition that
the client must check to
determine whether the
file needs to be flushed
to the server on close.
*/
nfsace4 permissions; /* Defines users who don't
need an ACCESS call as
part of a delegated
open. */
};
union open_delegation4
switch (open_delegation_type4 delegation_type) {
case OPEN_DELEGATE_NONE:
void;
case OPEN_DELEGATE_READ:
open_read_delegation4 read;
case OPEN_DELEGATE_WRITE:
open_write_delegation4 write;
};
const OPEN4_RESULT_MLOCK = 0x00000001;
const OPEN4_RESULT_CONFIRM= 0x00000002;
struct OPEN4resok {
stateid4 stateid; /* Stateid for open */
change_info4 cinfo; /* Directory Change Info */
uint32_t rflags; /* Result flags */
verifier4 open_confirm; /* OPEN_CONFIRM verifier */
open_delegation4 delegation; /* Info on any open
delegation */
};
union OPEN4res switch (nfsstat4 status) {
case NFS4_OK:
/* CURRENT_FH: opened file */
OPEN4resok resok4;
default:
void;
};
WARNING TO CLIENT IMPLEMENTORS
クライアント実装者へ警告
OPEN resembles LOOKUP in that it generates a filehandle for the client to use. Unlike LOOKUP though, OPEN creates server state on the filehandle. In normal circumstances, the client can only release this state with a CLOSE operation. CLOSE uses the current filehandle to determine which file to close. Therefore the client MUST follow every OPEN operation with a GETFH operation in the same COMPOUND procedure. This will supply the client with the filehandle such that CLOSE can be used appropriately.
OPEN似ているが、それは、クライアントが使用するファイルハンドルを生成するルックアップ。しかしLOOKUPとは異なり、OPENはファイルハンドルの上にサーバの状態を作成します。通常の状況では、クライアントはCLOSE操作で、この状態を解除することができます。 CLOSEは閉鎖するファイルを決定するために、現在のファイルハンドルを使用しています。そのため、クライアントは同じCOMPOUND手順でGETFH操作ですべてのOPEN操作に従わなければなりません。これは、CLOSEを適切に使用することができるように、ファイルハンドルをクライアントに提供します。
Simply waiting for the lease on the file to expire is insufficient because the server may maintain the state indefinitely as long as another client does not attempt to make a conflicting access to the same file.
サーバが無期限に限り、別のクライアントが同じファイルへの競合アクセスを作るしようとしないような状態を維持することができるので、単純に期限切れにするファイルのリースを待っていることは不十分です。
DESCRIPTION
DESCRIPTION
The OPEN operation creates and/or opens a regular file in a directory with the provided name. If the file does not exist at the server and creation is desired, specification of the method of creation is provided by the openhow parameter. The client has the choice of three creation methods: UNCHECKED, GUARDED, or EXCLUSIVE.
OPEN操作が作成および/または提供された名前のディレクトリにある通常のファイルを開きます。ファイルがサーバーに存在しないと作成を希望する場合、作成方法の指定は、openhowパラメータによって提供されます。 UNCHECKED、GUARDED、またはEXCLUSIVE：クライアントが3つの作成方法の選択肢を持っています。
UNCHECKED means that the file should be created if a file of that name does not exist and encountering an existing regular file of that name is not an error. For this type of create, createattrs specifies the initial set of attributes for the file. The set of attributes may includes any writable attribute valid for regular files. When an UNCHECKED create encounters an existing file, the attributes specified by createattrs is not used, except that when an object_size of zero is specified, the existing file is truncated. If GUARDED is specified, the server checks for the presence of a duplicate object by name before performing the create. If a duplicate exists, an error of NFS4ERR_EXIST is returned as the status. If the object does not exist, the request is performed as described for UNCHECKED.
UNCHECKEDは、その名前のファイルが存在しないと、その名前の既存の通常のファイルに遭遇してもエラーではありませんない場合、ファイルが作成されなければならないことを意味しています。作成のこのタイプのため、createattrsは、ファイルの属性の初期セットを指定します。属性のセットは、通常のファイルに有効な任意の書き込み可能な属性を含んでいることがあります。 UNCHECKEDは、既存のファイルの出会いを作成すると、createattrsによって指定された属性は、ゼロのオブジェクト_が指定されている場合、既存のファイルが切り捨てられることを除いて、使用されていません。 GUARDEDを作成実行する前に、名前の重複したオブジェクトが存在するサーバーのチェックを指定された場合。重複が存在する場合は、NFS4ERR_EXISTの誤差がステータスとして返されます。オブジェクトが存在しない場合は、オフのために記載したように、要求が行われます。
EXCLUSIVE specifies that the server is to follow exclusive creation semantics, using the verifier to ensure exclusive creation of the target. The server should check for the presence of a duplicate object by name. If the object does not exist, the server creates the object and stores the verifier with the object. If the object does exist and the stored verifier matches the client provided verifier, the server uses the existing object as the newly created object. If the stored verifier does not match, then an error of NFS4ERR_EXIST is returned. No attributes may be provided in this case, since the server may use an attribute of the target object to store the verifier.
EXCLUSIVEは、サーバがターゲットの排他的な作成を確保するために検証を使用して、排他的な作成のセマンティクスに従うことであることを指定します。サーバーは名前で重複したオブジェクトが存在するかどうかをチェックする必要があります。オブジェクトが存在しない場合は、サーバーはオブジェクトを作成し、オブジェクトに検証を保存します。オブジェクトが存在しないと保存された検証がクライアントに提供ベリファイアと一致した場合、サーバーは、新しく作成されたオブジェクトとして既存のオブジェクトを使用しています。保存された検証が一致しない場合は、NFS4ERR_EXISTのエラーが返されます。サーバーが検証を保存するために、ターゲットオブジェクトの属性を使用することができるので、何の属性が、この場合に設けなくてもよいです。
For the target directory, the server returns change_info4 information in cinfo. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the link creation.
ターゲットディレクトリの場合、サーバはcinfoの変化_info4情報を返します。前と後の変更属性がリンク作成に関して原子論が得られた場合には変化_info4構造体の原子分野、意志が示すサーバ。
Upon successful creation, the current filehandle is replaced by that of the new object.
作成に成功すると、現在のファイルハンドルは、新しいオブジェクトのものに置き換えられます。
The OPEN procedure provides for DOS SHARE capability with the use of the access and deny fields of the OPEN arguments. The client specifies at OPEN the required access and deny modes. For clients that do not directly support SHAREs (i.e. Unix), the expected deny value is DENY_NONE. In the case that there is a existing SHARE reservation that conflicts with the OPEN request, the server returns the error NFS4ERR_DENIED. For a complete SHARE request, the client must provide values for the owner and seqid fields for the OPEN argument. For additional discussion of SHARE semantics see the section on 'Share Reservations'.
OPEN手順は、アクセスを使用したDOSのSHARE機能を提供し、OPEN引数のフィールドを否定します。クライアントがOPENに必要なアクセスを指定し、モードを拒否します。直接株（すなわち、Unixの）をサポートしていないクライアントの場合、期待値はDENY_NONEで否定しています。 OPEN要求と競合する既存のSHAREの予約がある場合には、サーバがエラーNFS4ERR_DENIEDを返します。完全SHARE要求の場合、クライアントがOPEN引数の所有者およびSEQIDフィールドの値を指定する必要があります。 SHARE意味論の追加の議論については「共有予約」に関するセクションを参照してください。
In the case that the client is recovering state from a server failure, the reclaim field of the OPEN argument is used to signify that the request is meant to reclaim state previously held.
クライアントがサーバー障害から状態を回復している場合には、OPEN引数の再利用フィールドは、要求が以前に開催された状態を取り戻すことを意図していることを意味するために使用されます。
The "claim" field of the OPEN argument is used to specify the file to be opened and the state information which the client claims to possess. There are four basic claim types which cover the various situations for an OPEN. They are as follows:
OPEN引数の「主張」フィールドがオープンするファイルとクライアントが持っていると主張する状態情報を指定するために使用されます。 OPENのための様々な状況をカバーする四つの基本的な要求の種類があります。それらは次の通りです：
CLAIM_NULL For the client, this is a new OPEN request and there is no previous state associate with the file for the client.
クライアントの場合CLAIM_NULLが、これは新しいOPENのリクエストで、クライアント用のファイルとは以前の状態に関連付けはありません。
CLAIM_PREVIOUS The client is claiming basic OPEN state for a file that was held previous to a server reboot. Generally used when a server is returning persistent file handles; the client may not have the file name to reclaim the OPEN.
CLAIM_PREVIOUSは、クライアントはサーバーの再起動に以前開催されたファイルのための基本的なOPEN状態を主張しています。サーバーは持続的ファイルハンドルを返すときに一般的に使用。クライアントは、OPENを取り戻すために、ファイル名を持っていないかもしれません。
CLAIM_DELEGATE_CUR The client is claiming a delegation for OPEN as granted by the server. Generally this is done as part of recalling a delegation.
サーバによって付与されたようCLAIM_DELEGATE_CURは、クライアントがOPENのための委任を主張しています。一般に、これは代表団をリコールの一部として行われます。
CLAIM_DELEGATE_PREV The client is claiming a delegation granted to a previous client instance; used after the client reboots.
CLAIM_DELEGATE_PREVは、クライアントは、以前のクライアントインスタンスに付与された委任を主張しています。クライアントの再起動後に使用。
For OPEN requests whose claim type is other than CLAIM_PREVIOUS (i.e. requests other than those devoted to reclaiming opens after a server reboot) that reach the server during its grace or lease expiration period, the server returns an error of NFS4ERR_GRACE.
その猶予又はリース満了期間中にサーバに到達し、そのクレームタイプCLAIM_PREVIOUS以外である（すなわち、再利用に専念以外の要求サーバーの再起動後に開く）OPEN要求の場合、サーバはNFS4ERR_GRACEのエラーを返します。
For any OPEN request, the server may return an open delegation, which allows further opens and closes to be handled locally on the client as described in the section Open Delegation. Note that delegation is up to the server to decide. The client should never assume that delegation will or will not be granted in a particular instance. It should always be prepared for either case. A partial exception is the reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed. In this case, delegation will always be granted, although the server may specify an immediate recall in the delegation structure.
任意のOPEN要求の場合、サーバーはさらに可能に開き、セクションオープン委任で説明したように、クライアント上でローカルに処理されるように閉じ、開いている委譲を返すことがあります。代表団が決定するサーバー次第であることに注意してください。クライアントは、代表団は、または特定のインスタンスで付与されないだろうと想定してはいけません。それは、常にどちらかの場合のために準備する必要があります。部分的な例外は、委譲タイプが記載されて再利用（CLAIM_PREVIOUS）場合、です。サーバが委任構造で即時リコールを指定することもできますが、この場合には、代表団は常に、付与されます。
The rflags returned by a successful OPEN allow the server to return information governing how the open file is to be handled. OPEN4_RESULT_MLOCK indicates to the caller that mandatory locking is in effect for this file and the client should act appropriately with regard to data cached on the client. OPEN4_RESULT_CONFIRM indicates that the client MUST execute an OPEN_CONFIRM operation before using the open file.
成功OPENによって返さRFLAGSは、サーバが開いているファイルを処理する方法を規定する情報を返すことができます。 OPEN4_RESULT_MLOCKは強制ロックは、このファイルのために有効であることを呼び出し側に示し、クライアントは、クライアント上にキャッシュされたデータに関連して、適切に行動すべきです。 OPEN4_RESULT_CONFIRMは、クライアントが開いているファイルを使用する前に、オープン_CONFIRM操作を実行しなければならないことを示しています。
If the file is a zero length array, if any component does not obey the UTF-8 definition, or if any component in the path is of zero length, the error NFS4ERR_INVAL will be returned.
任意成分は、UTF-8定義に従わない場合、ファイルはゼロ長の配列である場合、パス内の任意の成分はゼロ長である場合、又は、エラーNFS4ERR_INVALが返されます。
When an OPEN is done and the specified lockowner already has the resulting filehandle open, the result is to "OR" together the new share and deny status together with the existing status. In this case, only a single CLOSE need be done, even though multiple OPEN's were completed.
OPENが行われ、指定されたlockownerが既に開いたファイルハンドルを持っている場合は、その結果が「OR」一緒に新しい共有され、既存のステータスと一緒に状況を否定します。この場合、単一のCLOSEは、複数のOPENのが完了したにもかかわらず、行われる必要があります。
IMPLEMENTATION
実装
The OPEN procedure contains support for EXCLUSIVE create. The mechanism is similar to the support in NFS version 3 [RFC1813]. As in NFS version 3, this mechanism provides reliable exclusive creation. Exclusive create is invoked when the how parameter is EXCLUSIVE. In this case, the client provides a verifier that can reasonably be expected to be unique. A combination of a client identifier, perhaps the client network address, and a unique number generated by the client, perhaps the RPC transaction identifier, may be appropriate.
OPEN手順はEXCLUSIVEを作成するためのサポートが含まれています。機構は、NFSバージョン3 [RFC1813]でサポートと同様です。 NFSバージョン3のように、このメカニズムは、信頼できる排他的な創造を提供します。独占は、どのようにパラメータがEXCLUSIVEときに呼び出されます作成します。この場合、クライアントは、合理的に一意であることが期待できる検証を提供します。クライアント識別子の組み合わせ、恐らくクライアントネットワークアドレス、およびクライアントによって生成された固有の番号、恐らくRPCトランザクション識別子は、適切であり得ます。
If the object does not exist, the server creates the object and stores the verifier in stable storage. For file systems that do not provide a mechanism for the storage of arbitrary file attributes, the server may use one or more elements of the object meta-data to store the verifier. The verifier must be stored in stable storage to prevent erroneous failure on retransmission of the request. It is assumed that an exclusive create is being performed because exclusive semantics are critical to the application. Because of the expected usage, exclusive CREATE does not rely solely on the normally volatile duplicate request cache for storage of the verifier. The duplicate request cache in volatile storage does not survive a crash and may actually flush on a long network partition, opening failure windows. In the UNIX local file system environment, the expected storage location for the verifier on creation is the meta-data (time stamps) of the object. For this reason, an exclusive object create may not include initial attributes because the server would have nowhere to store the verifier.
オブジェクトが存在しない場合は、サーバーはオブジェクトを作成し、安定したストレージに検証を保存します。任意のファイル属性を格納するためのメカニズムを提供しないファイルシステムでは、サーバは、検証を格納するオブジェクトのメタデータの1つの以上の要素を使用することができます。検証者は、要求の再送に誤った故障を防ぐために、安定したストレージに格納されなければなりません。排他的な意味はアプリケーションに不可欠であるため、排他が行われて作成することを想定しています。そのため、予想される使用法の、排他的な検証の記憶のため、通常は揮発性の重複要求キャッシュのみに依存しませんCREATE。揮発性記憶装置内の重複要求キャッシュは、クラッシュを存続しないと、実際に障害の窓を開け、長いネットワークパーティションにフラッシュすることがあります。 UNIXローカルファイルシステム環境では、作成時に検証のための予想された場所は、オブジェクトのメタデータ（タイムスタンプ）です。このため、排他的なオブジェクトは、サーバには、検証を保存する場所がないでしょう、したがって、初期の属性を含まないかもしれません。
If the server can not support these exclusive create semantics, possibly because of the requirement to commit the verifier to stable storage, it should fail the OPEN request with the error, NFS4ERR_NOTSUPP.
サーバーは、これらの排他的で安定したストレージに検証をコミットする可能性があるための要件の、セマンティクスを作成サポートできない場合は、エラー、NFS4ERR_NOTSUPPとOPEN要求を失敗するはずです。
During an exclusive CREATE request, if the object already exists, the server reconstructs the object's verifier and compares it with the verifier in the request. If they match, the server treats the request as a success. The request is presumed to be a duplicate of an earlier, successful request for which the reply was lost and that the server duplicate request cache mechanism did not detect. If the verifiers do not match, the request is rejected with the status, NFS4ERR_EXIST.
オブジェクトがすでに存在する場合、排他的、CREATE要求の間に、サーバーは、オブジェクトの検証を再構築し、要求で検証とそれを比較します。それらが一致した場合、サーバは成功として要求を処理します。要求は応答が失われたとサーバーの重複要求キャッシュメカニズムが検出されなかったことをそのため、以前、成功した要求の重複であると推定されます。検証が一致しない場合、要求はステータス、NFS4ERR_EXISTで拒否されます。
Once the client has performed a successful exclusive create, it must issue a SETATTR to set the correct object attributes. Until it does so, it should not rely upon any of the object attributes, since the server implementation may need to overload object meta-data to store the verifier. The subsequent SETATTR must not occur in the same COMPOUND request as the OPEN. This separation will guarantee that the exclusive create mechanism will continue to function properly in the face of retransmission of the request.
クライアントが作成した排他的な成功を行った後、それが正しいオブジェクトの属性を設定するSETATTRを発行する必要があります。それはそうするまで、サーバの実装は、検証を保存するために、オブジェクトのメタデータをオーバーロードする必要があるかもしれないので、それは、オブジェクトの属性のいずれかに頼るべきではありません。その後のSETATTRはOPENと同じCOMPOUND要求で発生してはなりません。この分離は、排他的な作成メカニズムは、要求の再送信の顔に適切に機能し続けることを保証します。
Use of the GUARDED attribute does not provide exactly-once semantics. In particular, if a reply is lost and the server does not detect the retransmission of the request, the procedure can fail with NFS4ERR_EXIST, even though the create was performed successfully.
守ら属性の使用は、正確にワンスセマンティクスを提供していません。回答が失われ、サーバが要求の再送信を検出しない場合は特に、手順が正常に実行されました作成していても、NFS4ERR_EXISTで失敗する可能性があります。
For SHARE reservations, the client must specify a value for access that is one of READ, WRITE, or BOTH. For deny, the client must specify one of NONE, READ, WRITE, or BOTH. If the client fails to do this, the server must return NFS4ERR_INVAL.
SHAREのご予約は、クライアントがREADの1、WRITE、またはBOTHであるアクセスのための値を指定する必要があります。以下のためのクライアントが読み取り、書き込み、またはBOTH、NONEのいずれかを指定する必要があり、否定します。クライアントはこれを行うに失敗した場合、サーバーはNFS4ERR_INVALを返さなければなりません。
If the final component provided to OPEN is a symbolic link, the error NFS4ERR_SYMLINK will be returned to the client. If an intermediate component of the pathname provided to OPEN is a symbolic link, the error NFS4ERR_NOTDIR will be returned to the client.
OPENに提供最後のコンポーネントがシンボリックリンクの場合、エラーNFS4ERR_SYMLINKがクライアントに返されます。 OPENに提供されるパス名の中間構成要素がシンボリックリンクである場合は、エラーNFS4ERR_NOTDIRがクライアントに返されます。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BAD_SEQID NFS4ERR_DELAY NFS4ERR_DQUOT NFS4ERR_EXIST NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_IO NFS4ERR_ISDIR NFS4ERR_LEASE_MOVED NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_NOTDIR NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_SHARE_DENIED NFS4ERR_STALE_CLIENTID NFS4ERR_SYMLINK
NFS4ERR_ACCES NFS4ERR_BAD_SEQID NFS4ERR_DELAY NFS4ERR_DQUOT NFS4ERR_EXIST NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_IO NFS4ERR_ISDIR NFS4ERR_LEASE_MOVED NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_NOTDIR NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_SHARE_DENIED NFS4ERR_STALE_CLIENTID NFS4ERR_SYMLINK
SYNOPSIS
SYNOPSIS
(cfh) -> (cfh)
（CFH） - >（CFH）
ARGUMENT
引数
/* CURRENT_FH: file or directory */
void;
RESULT
結果
struct OPENATTR4res {
/* CURRENT_FH: name attr directory*/
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
The OPENATTR operation is used to obtain the filehandle of the named attribute directory associated with the current filehandle. The result of the OPENATTR will be a filehandle to an object of type NF4ATTRDIR. From this filehandle, READDIR and LOOKUP procedures can be used to obtain filehandles for the various named attributes associated with the original file system object. Filehandles returned within the named attribute directory will have a type of NF4NAMEDATTR.
OPENATTR操作は、現在のファイルハンドルに関連付けられた名前の属性ディレクトリのファイルハンドルを取得するために使用されます。 OPENATTRの結果は、タイプNF4ATTRDIRのオブジェクトへのファイルハンドルであろう。このファイルハンドルから、READDIRとLOOKUP手順は、元のファイル・システム・オブジェクトに関連付けられた種々の名前属性のファイルハンドルを取得するために使用することができます。ファイルハンドルはNF4NAMEDATTRの種類がありますという名前の属性ディレクトリに戻りました。
IMPLEMENTATION
実装
If the server does not support named attributes for the current filehandle, an error of NFS4ERR_NOTSUPP will be returned to the client.
サーバは、現在のファイルハンドルの名前が付いた属性をサポートしていない場合は、NFS4ERR_NOTSUPPのエラーがクライアントに返されます。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP NFS4ERR_RESOURCE
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP NFS4ERR_RESOURCE
NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), seqid, open_confirm-> stateid
（CFH）、SEQID、open_confirm->のstateid
ARGUMENT
引数
struct OPEN_CONFIRM4args {
/* CURRENT_FH: opened file */
seqid4 seqid;
verifier4 open_confirm; /* OPEN_CONFIRM verifier */
};
RESULT
結果
struct OPEN_CONFIRM4resok {
stateid4 stateid;
};
union OPEN_CONFIRM4res switch (nfsstat4 status) {
case NFS4_OK:
OPEN_CONFIRM4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
This operation is used to confirm the sequence id usage for the first time that a nfs_lockowner is used by a client. The OPEN operation returns a opaque confirmation verifier that is then passed to this operation along with the next sequence id for the nfs_lockowner. The sequence id passed to the OPEN_CONFIRM must be 1 (one) greater than the seqid passed to the OPEN operation from which the open_confirm value was obtained. If the server receives an unexpected sequence id with respect to the original open, then the server assumes that the client will not confirm the original OPEN and all state associated with the original OPEN is released by the server.
この操作はnfs_lockownerのは、クライアントによって使用される最初の時間のためのシーケンスIDの使用状況を確認するために使用されます。 OPEN操作は、その後のnfs_lockownerのための次のシーケンスIDとともに、この操作に渡される不透明な確認検証を返します。オープン_CONFIRMに渡されたシーケンス番号は、オープン_CONFIRM値が得られたOPEN操作に渡さSEQIDより1（1）大きくなければなりません。サーバは、元のオープンに関して予想外シーケンスIDを受信した場合、サーバは、クライアントがサーバーによって解放され、元のOPENと元OPENに関連するすべての状態を確認しないことを前提としています。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
A given client might generate many nfs_lockowner data structures for a given clientid. The client will periodically either dispose of its nfs_lockowners or stop using them for indefinite periods of time. The latter situation is why the NFS version 4 protocol does not have a an explicit operation to exit an nfs_lockowner: such an operation is of no use in that situation. Instead, to avoid unbounded memory use, the server needs to implement a strategy for disposing of nfs_lockowners that have no current lock, open, or delegation state for any files and have not been used recently. The time period used to determine when to dispose of nfs_lockowners is an implementation choice. The time period should certainly be no less than the lease time plus any grace period the server wishes to implement beyond a lease time. The OPEN_CONFIRM operation allows the server to safely dispose of unused nfs_lockowner data structures.
与えられたクライアントは、与えられたclientidのために多くのnfs_lockownerデータ構造を生成することがあります。クライアントは、定期的にどちらかのnfs_lockownersを処分または無期限の期間のためにそれらを使用して停止します。このような動作は、そのような状況では役に立たない：NFSバージョン4プロトコルはnfs_lockownerのを終了するために明示的な操作を持っていない理由後者の状況です。代わりに、無限のメモリ使用を避けるために、サーバはすべてのファイルには現在のロック、オープン、または委任状態を持っていないし、最近使用されていないnfs_lockownersの処分のための戦略を実装する必要があります。ときnfs_lockownersの処分を決定するために使用される期間は、実装の選択です。期間は確かにリース時間を加えたサーバがリース時間を超えて実施することを希望する任意の猶予期間よりも少なくないはずです。オープン_CONFIRM操作は、サーバーが安全に使用されていないのnfs_lockownerデータ構造を処分することができます。
In the case that a client issues an OPEN operation and the server no longer has a record of the nfs_lockowner, the server needs ensure that this is a new OPEN and not a replay or retransmission.
クライアントがOPENオペレーションを発行しないと、サーバーは、もはやnfs_lockownerの記録を持っている場合は、サーバーのニーズは、これは新しいOPENしていない再生または再送信であることを確認してください。
A lazy server implementation might require confirmation for every nfs_lockowner for which it has no record. However, this is not necessary until the server records the fact that it has disposed of one nfs_lockowner for the given clientid.
怠惰なサーバーの実装は、それが記録されていないいるため、すべてのnfs_lockownerの確認が必要な場合があります。サーバは、それが与えられたclientidのために1つのnfs_lockownerを処分したという事実を記録するまでしかし、これは必要ありません。
The server must hold unconfirmed OPEN state until one of three events occur. First, the client sends an OPEN_CONFIRM request with the appropriate sequence id and confirmation verifier within the lease period. In this case, the OPEN state on the server goes to confirmed, and the nfs_lockowner on the server is fully established.
3つのイベントのいずれかが発生するまで、サーバは未確認OPEN状態を保持しなければなりません。まず、クライアントはリース期間内の適切なシーケンス番号と確認検証とオープン_CONFIRM要求を送信します。この場合、サーバー上のOPEN状態を確認に行くと、サーバー上のnfs_lockownerは完全に確立されています。
Second, the client sends another OPEN request with a sequence id that is incorrect for the nfs_lockowner (out of sequence). In this case, the server assumes the second OPEN request is valid and the first one is a replay. The server cancels the OPEN state of the first OPEN request, establishes an unconfirmed OPEN state for the second OPEN request, and responds to the second OPEN request with an indication that an OPEN_CONFIRM is needed. The process then repeats itself. While there is a potential for a denial of service attack on the client, it is mitigated if the client and server require the use of a security flavor based on Kerberos V5, LIPKEY, or some other flavor that uses cryptography.
第二に、クライアントは、（シーケンスのうち）nfs_lockownerのために間違っているシーケンスIDを持つ別のOPEN要求を送信します。この場合、サーバは、2番目のOPEN要求が有効であるとみなし、最初のものはリプレイです。サーバは、最初のOPEN要求のOPEN状態を解除する第二のOPEN要求の未確認OPEN状態を確立し、オープン_CONFIRMが必要であるという指示を有する第二OPEN要求に応答します。プロセスはその後、自分自身を繰り返します。クライアント上のサービス拒否攻撃の可能性がある一方で、クライアントとサーバーがKerberos V5、LIPKEY、または暗号を使用して、いくつかの他のフレーバーに基づくセキュリティ風味を使用する必要があれば、それが軽減されます。
What if the server is in the unconfirmed OPEN state for a given nfs_lockowner, and it receives an operation on the nfs_lockowner that has a stateid but the operation is not OPEN, or it is OPEN_CONFIRM but with the wrong confirmation verifier? Then, even if the seqid is correct, the server returns NFS4ERR_BAD_STATEID, because the server assumes the operation is a replay: if the server has no established OPEN state, then there is no way, for example, a LOCK operation could be valid.
どのサーバが与えられたnfs_lockownerのため未確認OPEN状態にあり、それはたstateidを持っていますが、操作が開いていない、またはそれがオープン_CONFIRMあるnfs_lockownerのではなく、間違った確認検証を使用して操作を受信した場合？サーバが何の確立OPEN状態を持っていない場合、方法はありません、例えば、LOCK操作が有効である可能性：SEQIDが正しい場合でも、サーバーは操作がリプレイであると仮定しているため、その後、サーバは、NFS4ERR_BAD_STATEIDを返します。
Third, neither of the two aforementioned events occur for the nfs_lockowner within the lease period. In this case, the OPEN state is cancelled and disposal of the nfs_lockowner can occur.
第三に、上記の2つのイベントのどちらもリース期間内にnfs_lockownerのために起こります。この場合、OPEN状態が解除されるとのnfs_lockownerの廃棄が発生する可能性があります。
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_BAD_SEQID NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_MOVED NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_BADHANDLE NFS4ERR_BAD_SEQID NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_MOVED NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), stateid, seqid, access, deny -> stateid
（CFH）、のstateid、SEQID、アクセス、拒否 - >のstateid
ARGUMENT
引数
struct OPEN_DOWNGRADE4args {
/* CURRENT_FH: opened file */
stateid4 stateid;
seqid4 seqid;
uint32_t share_access;
uint32_t share_deny;
};
RESULT struct OPEN_DOWNGRADE4resok {
stateid4 stateid;
};
union OPEN_DOWNGRADE4res switch(nfsstat4 status) {
case NFS4_OK:
OPEN_DOWNGRADE4resok resok4;
default:
void;
};
This operation is used to adjust the access and deny bits for a given open. This is necessary when a given lockowner opens the same file multiple times with different access and deny flags. In this situation, a close of one of the open's may change the appropriate access and deny flags to remove bits associated with open's no longer in effect.
この動作は、アクセスを調整し、所定の開放のためのビットを拒否するために使用されます。与えられたlockownerは異なるアクセス権を持つ複数回、同じファイルを開くとフラグを否定するときに必要です。このような状況では、オープンのの1の近くには、適切なアクセス権を変更して、開いているのはもはや有効で関連付けられたビットを削除するには、フラグを拒否することができます。
The access and deny bits specified in this operation replace the current ones for the specified open file. If either the access or the deny mode specified includes bits not in effect for the open, the error NFS4ERR_INVAL should be returned. Since access and deny bits are subsets of those already granted, it is not possible for this request to be denied because of conflicting share reservations.
この操作で指定されたアクセスと拒否ビットが指定されたオープンファイルの現在のものを交換してください。アクセスまたは指定拒否モードのいずれかが開に有効ビットがない含まれている場合、エラーNFS4ERR_INVALが返さなければなりません。アクセスと拒否ビットが既に許可されたもののサブセットであるため、この要求が原因で矛盾シェアの予約を拒否されるため、それは不可能です。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_BAD_SEQID NFS4ERR_BAD_STATEID NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID
NFS4ERR_BADHANDLE NFS4ERR_BAD_SEQID NFS4ERR_BAD_STATEID NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID
SYNOPSIS
SYNOPSIS
filehandle -> (cfh)
ファイルハンドル - >（CFH）
ARGUMENT
引数
struct PUTFH4args { nfs4_fh object; };
構造体PUTFH4args {nfs4_fhオブジェクト。 }。
RESULT
結果
struct PUTFH4res {
構造体PUTFH4res {
/* CURRENT_FH: */
nfsstat4 status; };
DESCRIPTION
DESCRIPTION
Replaces the current filehandle with the filehandle provided as an argument.
引数として与えられたファイルハンドルと、現在のファイルハンドルを置き換えます。
IMPLEMENTATION
実装
Commonly used as the first operator in an NFS request to set the context for following operations.
一般的操作を以下のコンテキストを設定するために、NFS要求の最初の演算子として使用しました。
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_MOVED NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_MOVED NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
- -> (cfh)
- - >（CFH）
ARGUMENT
引数
void;
無効;
RESULT
結果
struct PUTPUBFH4res {
/* CURRENT_FH: public fh */
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
Replaces the current filehandle with the filehandle that represents the public filehandle of the server's name space. This filehandle may be different from the "root" filehandle which may be associated with some other directory on the server.
サーバーの名前空間の公開ファイルハンドルを表し、ファイルハンドルと、現在のファイルハンドルを置き換えます。このファイルハンドルは、サーバー上の他のディレクトリに関連付けすることができる「ルート」ファイルハンドルは異なる場合があります。
IMPLEMENTATION
実装
Used as the first operator in an NFS request to set the context for following operations.
動作を以下のコンテキストを設定するために、NFS要求の最初の演算子として使用。
ERRORS
エラー
NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_WRONGSEC
NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
- -> (cfh)
- - >（CFH）
ARGUMENT
引数
void;
無効;
RESULT
結果
struct PUTROOTFH4res {
/* CURRENT_FH: root fh */
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
Replaces the current filehandle with the filehandle that represents the root of the server's name space. From this filehandle a LOOKUP operation can locate any other filehandle on the server. This filehandle may be different from the "public" filehandle which may be associated with some other directory on the server.
サーバーの名前空間のルートを表すファイルハンドルと、現在のファイルハンドルを置き換えます。このファイルハンドルからLOOKUP操作は、サーバー上の他のファイルハンドルを見つけることができます。このファイルハンドルは、サーバー上の他のディレクトリに関連付けすることができる「パブリック」ファイルハンドルは異なる場合があります。
IMPLEMENTATION
実装
Commonly used as the first operator in an NFS request to set the context for following operations.
一般的操作を以下のコンテキストを設定するために、NFS要求の最初の演算子として使用しました。
ERRORS
エラー
NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_WRONGSEC
NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), offset, count, stateid -> eof, data
（CFH）、カウント、オフセット、のstateid - > EOF、データ
ARGUMENT
引数
struct READ4args {
/* CURRENT_FH: file */
stateid4 stateid;
offset4 offset;
count4 count;
};
RESULT
結果
struct READ4resok {
bool eof;
opaque data<>;
};
union READ4res switch (nfsstat4 status) {
case NFS4_OK:
READ4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The READ operation reads data from the regular file identified by the current filehandle.
READ操作は、現在のファイルハンドルで識別される通常のファイルからデータを読み込みます。
The client provides an offset of where the READ is to start and a count of how many bytes are to be read. An offset of 0 (zero) means to read data starting at the beginning of the file. If offset is greater than or equal to the size of the file, the status, NFS4_OK, is returned with a data length set to 0 (zero) and eof is set to TRUE. The READ is subject to access permissions checking.
クライアントはREADが開始することで、どのように多くのバイト数を読み取ることがどこのオフセットを提供します。 0（ゼロ）のオフセットをファイルの先頭から始まるデータを読み取ることを意味します。オフセットがより大きいかまたはファイルのサイズに等しい場合、ステータス、NFS4_OKは、TRUEに設定されている0（ゼロ）とEOFに設定されたデータ長と戻されます。 READは、チェックアクセス許可の対象となります。
If the client specifies a count value of 0 (zero), the READ succeeds and returns 0 (zero) bytes of data again subject to access permissions checking. 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.
クライアントは、0（ゼロ）のカウント値を指定した場合、READは成功し、アクセス権限をチェックするために、再度対象データの0（ゼロ）バイトを返します。サーバーは、クライアントによって指定されたよりも少ないバイト数を返すように選択することができます。クライアントは、この状態を確認し、適切な条件を処理する必要があります。
The stateid value for a READ request represents a value returned from a previous record lock or share reservation request. Used by the server to verify that the associated lock is still valid and to update lease timeouts for the client.
READ要求のためのstateid値は、前のレコードロックまたは共有の予約要求から返された値を表します。関連するロックがまだ有効であることを確認するために、クライアントのリースのタイムアウトを更新するためにサーバによって使用されます。
If the read ended at the end-of-file (formally, in a correctly formed READ request, if offset + count is equal to the size of the file), or the read request extends beyond the size of the file (if offset + count is greater than the size of the file), eof is returned as TRUE; otherwise it is FALSE. A successful READ of an empty file will always return eof as TRUE.
オフセットが（ファイルの終わりで終了読み取り（オフセット+回数場合、正しく形成さREAD要求で、正式には、ファイルのサイズと同じである）、または読み取り要求はファイルのサイズを超えて拡張する場合+カウントは、EOFがTRUEとして返され、）ファイルのサイズよりも大きいです。それ以外の場合はFALSEです。空のファイルの成功READは常にEOFとしてTRUEを返します。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
It is possible for the server to return fewer than count bytes of data. If the server returns less than the count requested and eof set to FALSE, the client should issue another READ to get the remaining data. A server may return less data than requested under several circumstances. The file may have been truncated by another client or perhaps on the server itself, changing the file size from what the requesting client believes to be the case. This would reduce the actual amount of data available to the client. It is possible that the server may back off the transfer size and reduce the read request return. Server resource exhaustion may also occur necessitating a smaller read return.
サーバーがデータのバイト数を数えるよりも少ない数を返すことが可能です。サーバは、カウント要求とEOF FALSEに設定未満を返した場合、クライアントは残りのデータを取得するために別のREADを発行する必要があります。サーバーには、いくつかの状況下で要求されたよりも少ないデータを返すことがあります。ファイルが要求しているクライアントは、ケースのように信じているから、ファイルサイズを変更し、別のクライアントによって、またはおそらく、サーバー自体に切り捨てられている可能性があります。これは、クライアントが利用可能なデータの実際の量を減少させるであろう。サーバーが転送サイズをバックオフし、読み出し要求リターンを減らすことが可能です。また、サーバリソース疲労困憊は、より小さな読み取りリターンを必要と発生する可能性があります。
If the file is locked the server will return an NFS4ERR_LOCKED error. Since the lock may be of short duration, the client may choose to retransmit the READ request (with exponential backoff) until the operation succeeds.
ファイルがロックされている場合、サーバはNFS4ERR_LOCKEDエラーを返します。ロックが短期間であってもよいので、クライアントは、操作が成功するまで（指数バックオフを有する）リード要求を再送信することを選択することができます。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_LOCKED NFS4ERR_LEASE_MOVED NFS4ERR_MOVED
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_EXPIRED NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_LOCKED NFS4ERR_LEASE_MOVED NFS4ERR_MOVED
NFS4ERR_NOFILEHANDLE NFS4ERR_NXIO NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
NFS4ERR_NOFILEHANDLE NFS4ERR_NXIO NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), cookie, cookieverf, dircount, maxcount, attrbits -> cookieverf { cookie, filename, attrbits, attributes }
（CFH）、クッキー、にcookieverf、dircount、MAXCOUNT、attrbits - >にcookieverf {クッキー、ファイル名、attrbitsは、属性}
ARGUMENT
引数
struct READDIR4args {
/* CURRENT_FH: directory */
nfs_cookie4 cookie;
verifier4 cookieverf;
count4 dircount;
count4 maxcount;
bitmap4 attr_request;
};
RESULT
結果
struct entry4 {
nfs_cookie4 cookie;
component4 name;
fattr4 attrs;
entry4 *nextentry;
};
struct dirlist4 {
entry4 *entries;
bool eof;
};
struct READDIR4resok {
verifier4 cookieverf;
dirlist4 reply;
};
union READDIR4res switch (nfsstat4 status) {
組合READDIR4resスイッチ（nfsstat4状態）{
case NFS4_OK:
READDIR4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The READDIR operation retrieves a variable number of entries from a file system directory and returns client requested attributes for each entry along with information to allow the client to request additional directory entries in a subsequent READDIR.
READDIR操作は、ファイル・システム・ディレクトリのエントリの可変数を取得し、クライアントは、クライアントがその後のREADDIRに追加のディレクトリエントリを要求することを可能にする情報とともに、各エントリの属性を要求返します。
The arguments contain a cookie value that represents where the READDIR should start within the directory. A value of 0 (zero) for the cookie is used to start reading at the beginning of the directory. For subsequent READDIR requests, the client specifies a cookie value that is provided by the server on a previous READDIR request.
引数はREADDIRがディレクトリ内の開始すべき場所を表すクッキー値が含まれています。 Cookieの0（ゼロ）の値は、ディレクトリの始めに読み始めるために使用されます。その後のREADDIR要求の場合、クライアントは前のREADDIR要求にサーバーによって提供されたクッキーの値を指定します。
The cookieverf value should be set to 0 (zero) when the cookie value is 0 (zero) (first directory read). On subsequent requests, it should be a cookieverf as returned by the server. The cookieverf must match that returned by the READDIR in which the cookie was acquired.
クッキー値が0（ゼロ）である場合にcookieverf値（最初のディレクトリは、読み取り）0（ゼロ）に設定されるべきです。後続の要求では、サーバで返すようにcookieverfでなければなりません。 cookieverfはクッキーが取得されたREADDIRによって返されたものと一致する必要があります。
The dircount portion of the argument is a hint of the maximum number of bytes of directory information that should be returned. This value represents the length of the names of the directory entries and the cookie value for these entries. This length represents the XDR encoding of the data (names and cookies) and not the length in the native format of the server. The server may return less data.
引数のdircount部分が返されるべきであるディレクトリ情報のバイトの最大数のヒントです。この値は、ディレクトリエントリとこれらのエントリのクッキー値の名前の長さを表しています。この長さは、XDRデータ（名前およびクッキー）の符号化ではなく、サーバのネイティブフォーマットにおける長さを表します。サーバーは、少ないデータを返すことがあります。
The maxcount value of the argument is the maximum number of bytes for the result. This maximum size represents all of the data being returned and includes the XDR overhead. The server may return less data. If the server is unable to return a single directory entry within the maxcount limit, the error NFS4ERR_READDIR_NOSPC will be returned to the client.
引数のMAXCOUNT値は、結果の最大バイト数です。この最大サイズは、返されるすべてのデータを表し、XDRオーバーヘッドを含みます。サーバーは、少ないデータを返すことがあります。サーバがMAXCOUNT限度内の単一のディレクトリエントリを返すことができない場合は、エラーNFS4ERR_READDIR_NOSPCがクライアントに返されます。
Finally, attrbits represents the list of attributes to be returned for each directory entry supplied by the server.
最後に、attrbitsは、サーバによって供給される各ディレクトリエントリのために返される属性のリストを表します。
On successful return, the server's response will provide a list of directory entries. Each of these entries contains the name of the directory entry, a cookie value for that entry, and the associated attributes as requested.
成功のリターンで、サーバの応答は、ディレクトリエントリのリストを提供します。要求に応じてこれらの各エントリには、ディレクトリエントリ、そのエントリのクッキー値、および関連する属性の名前が含まれています。
The cookie value is only meaningful to the server and is used as a "bookmark" for the directory entry. As mentioned, this cookie is used by the client for subsequent READDIR operations so that it may continue reading a directory. The cookie is similar in concept to a READ offset but should not be interpreted as such by the client. Ideally, the cookie value should not change if the directory is modified since the client may be caching these values.
クッキー値は、サーバーにのみ意味があり、ディレクトリエントリの「しおり」として使用されています。前述のように、それはディレクトリを読み続けることができるように、このクッキーは、その後のREADDIR操作のためにクライアントによって使用されます。クッキーは、オフセットREADの概念と似ていますが、クライアントによってそのように解釈すべきではありません。ディレクトリが変更された場合、クライアントは、これらの値をキャッシュすることができるので、理想的には、クッキーの値は変更しないでください。
In some cases, the server may encounter an error while obtaining the attributes for a directory entry. Instead of returning an error for the entire READDIR operation, the server can instead return the attribute 'fattr4_rdattr_error'. With this, the server is able to communicate the failure to the client and not fail the entire operation in the instance of what might be a transient failure. Obviously, the client must request the fattr4_rdattr_error attribute for this method to work properly. If the client does not request the attribute, the server has no choice but to return failure for the entire READDIR operation.
ディレクトリエントリの属性を取得しながら、いくつかのケースでは、サーバがエラーが発生することがあります。代わりに、全体のREADDIR操作のためのエラーを返すので、サーバーではなく、属性「fattr4_rdattr_error」を返すことができます。これにより、サーバはクライアントに障害が発生して通信し、一時的な障害であるかもしれないもののインスタンスで全体の動作を失敗しないことが可能です。もちろん、クライアントは正常に動作するために、このメソッドのfattr4_rdattr_error属性を要求する必要があります。クライアントが属性を要求しない場合、サーバは全体のREADDIR操作のために失敗を返すしかありません。
For some file system environments, the directory entries "." and ".." have special meaning and in other environments, they may not. If the server supports these special entries within a directory, they should not be returned to the client as part of the READDIR response. To enable some client environments, the cookie values of 0, 1, and 2 are to be considered reserved. Note that the Unix client will use these values when combining the server's response and local representations to enable a fully formed Unix directory presentation to the application.
いくつかのファイルシステム環境では、ディレクトリエントリ「」そして、「..」は特別な意味を持っており、他の環境では、彼らはないかもしれません。サーバーは、ディレクトリ内のこれらの特別項目をサポートしている場合、彼らはREADDIR応答の一部としてクライアントに返すべきではありません。いくつかのクライアント環境を有効にするには、0、1、および2のクッキー値は、予約された考慮されるべきです。アプリケーションに完全に形成されたUnixのディレクトリプレゼンテーションを可能にするために、サーバーの応答とローカルの表現を組み合わせたときのUNIXクライアントは、これらの値を使用することに注意してください。
For READDIR arguments, cookie values of 1 and 2 should not be used and for READDIR results cookie values of 0, 1, and 2 should not returned.
READDIRの引数の場合、1と2のクッキー値を使用すべきではないとREADDIR 0のクッキー値、結果は1、及び2を返すべきではありません。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
The server's file system directory representations can differ greatly. A client's programming interfaces may also be bound to the local operating environment in a way that does not translate well into the NFS protocol. Therefore the use of the dircount and maxcount fields are provided to allow the client the ability to provide guidelines to the server. If the client is aggressive about attribute collection during a READDIR, the server has an idea of how to limit the encoded response. The dircount field provides a hint on the number of entries based solely on the names of the directory entries. Since it is a hint, it may be possible that a dircount value is zero. In this case, the server is free to ignore the dircount value and return directory information based on the specified maxcount value.
サーバのファイルシステムのディレクトリ表現は大きく異なることができます。クライアントのプログラミング・インタフェースは、NFSプロトコルにうまく変換されないように、ローカルの動作環境に結合させることができます。したがってdircountとMAXCOUNTフィールドの使用は、クライアントにサーバーへの指針を提供する能力を可能にするために提供されています。クライアントは、READDIR時の属性コレクションについて積極的である場合、サーバーはエンコードされた応答を制限する方法のアイデアを持っています。 dircountフィールドは、単にディレクトリエントリの名前に基づいてエントリの数にヒントを提供します。それはヒントなので、dircount値がゼロであることが可能であってもよいです。この場合、サーバはdircount値を無視し、指定されたMAXCOUNT値に基づいて、ディレクトリ情報を返すために自由です。
The cookieverf may be used by the server to help manage cookie values that may become stale. It should be a rare occurrence that a server is unable to continue properly reading a directory with the provided cookie/cookieverf pair. The server should make every effort to avoid this condition since the application at the client may not be able to properly handle this type of failure.
cookieverfは古くなる可能性がクッキー値の管理を支援するためにサーバが使用することができます。これは、サーバーが提供するクッキー/にcookieverfペアでディレクトリを読み、適切に継続することができないまれな出来事でなければなりません。サーバーは、クライアントのアプリケーションが正常にこのタイプの障害を処理することができない場合がありますので、この状態を回避するためにあらゆる努力をする必要があります。
The use of the cookieverf will also protect the client from using READDIR cookie values that may be stale. For example, if the file system has been migrated, the server may or may not be able to use the same cookie values to service READDIR as the previous server used. With the client providing the cookieverf, the server is able to provide the appropriate response to the client. This prevents the case where the server may accept a cookie value but the underlying directory has changed and the response is invalid from the client's context of its previous READDIR.
cookieverfの使用も古いかもしれREADDIRクッキー値を使用してからクライアントを保護します。ファイルシステムが移行された場合、例えば、サーバは、または使用前サーバーとしてREADDIRにサービスを提供するために、同じクッキー値を使用することであってもなくてもよいです。クライアントがにcookieverfを提供すると、サーバはクライアントに適切な応答を提供することができます。これは、サーバがクッキー値を受け入れるかもしれませんが、基本となるディレクトリが変更されたとの応答がその前のREADDIRのクライアントの文脈から無効である場合を防ぎます。
Since some servers will not be returning "." and ".." entries as has been done with previous versions of the NFS protocol, the client that requires these entries be present in READDIR responses must fabricate them.
いくつかのサーバは戻ることはありませんので、「」そして、「..」エントリNFSプロトコルの以前のバージョンで行われているように、これらのエントリはREADDIR応答に存在することが必要とするクライアントは、それらを製作しなければなりません。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_COOKIE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_NOTSUPP NFS4ERR_READDIR_NOSPC NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_TOOSMALL NFS4ERR_WRONGSEC
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_COOKIE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_NOTSUPP NFS4ERR_READDIR_NOSPC NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_TOOSMALL NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh) -> linktext
（CFH） - >リンクテキスト
ARGUMENT
引数
/* CURRENT_FH: symlink */
void;
RESULT
結果
struct READLINK4resok {
linktext4 link;
};
union READLINK4res switch (nfsstat4 status) {
case NFS4_OK:
READLINK4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
READLINK reads the data associated with a symbolic link. The data is a UTF-8 string that is opaque to the server. That is, whether created by an NFS client or created locally on the server, the data in a symbolic link is not interpreted when created, but is simply stored.
READLINKは、シンボリックリンクに関連付けられたデータを読み込みます。データはサーバに不透明であるUTF-8文字列です。これは、作成した際に、NFSクライアントによって作成されたか、サーバー上でローカルに作成されたかどうか、シンボリックリンクのデータは解釈されないが、単純に保存されています。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
A symbolic link is nominally a pointer to another file. The data is not necessarily interpreted by the server, just stored in the file. It is possible for a client implementation to store a path name that is not meaningful to the server operating system in a symbolic link. A READLINK operation returns the data to the client for interpretation. If different implementations want to share access to symbolic links, then they must agree on the interpretation of the data in the symbolic link.
シンボリックリンクは、名目上は別のファイルへのポインタです。データは必ずしも単にファイルに保存され、サーバーによって解釈されていません。クライアントの実装がシンボリックリンクで、サーバーのオペレーティングシステムには意味がありませんパス名を保存することが可能です。 READLINK操作は、解釈のために、クライアントにデータを返します。異なる実装がシンボリックリンクへのアクセスを共有したい場合は、それらはシンボリックリンクでのデータの解釈に同意しなければなりません。
The READLINK operation is only allowed on objects of type NF4LNK. The server should return the error, NFS4ERR_INVAL, if the object is not of type, NF4LNK.
READLINK操作は、タイプがNF4LNKのオブジェクトに許可されています。オブジェクトは、種類のNF4LNKでない場合、サーバーは、エラー、NFS4ERR_INVALを返す必要があります。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), filename -> change_info
（CFH）、ファイル名 - > change_info
ARGUMENT
引数
struct REMOVE4args {
/* CURRENT_FH: directory */
component4 target;
};
RESULT
結果
struct REMOVE4resok { change_info4 cinfo; }
構造体REMOVE4resok {変化_info4のCINFO。 }
union REMOVE4res switch (nfsstat4 status) {
case NFS4_OK:
REMOVE4resok resok4;
default:
void;
}
DESCRIPTION
DESCRIPTION
The REMOVE operation removes (deletes) a directory entry named by filename from the directory corresponding to the current filehandle. If the entry in the directory was the last reference to the corresponding file system object, the object may be destroyed.
REMOVE操作は、現在のファイルハンドルに対応するディレクトリからファイル名で指定されたディレクトリエントリを削除（消去します）。ディレクトリ内のエントリは、対応するファイル・システム・オブジェクトへの最後の参照であった場合、オブジェクトが破棄されてもよいです。
For the directory where the filename was removed, the server returns change_info4 information in cinfo. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the removal.
ファイル名が削除されたディレクトリのために、サーバはcinfoの変化_info4情報を返します。前と後の変更属性が除去に関して原子論が得られた場合には変化_info4構造体の原子分野、意志が示すサーバ。
If the target has a length of 0 (zero), or if target does not obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned.
ターゲットがUTF-8定義に従わない場合、ターゲットは0（ゼロ）の長さを有する場合、または、エラーNFS4ERR_INVALが返されます。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
NFS versions 2 and 3 required a different operator RMDIR for directory removal. NFS version 4 REMOVE can be used to delete any directory entry independent of its file type.
NFSバージョン2と3は、ディレクトリを除去するための別のオペレータRMDIRが必要。 NFSバージョン4 REMOVEは、そのファイルの種類のいずれかのディレクトリエントリの独立を削除するために使用することができます。
The concept of last reference is server specific. However, if the numlinks field in the previous attributes of the object had the value 1, the client should not rely on referring to the object via a file handle. Likewise, the client should not rely on the resources (disk space, directory entry, and so on) formerly associated with the object becoming immediately available. Thus, if a client needs to be able to continue to access a file after using REMOVE to remove it, the client should take steps to make sure that the file will still be accessible. The usual mechanism used is to RENAME the file from its old name to a new hidden name.
最後の参照の概念は、サーバ固有のものです。オブジェクトの前の属性でnumlinksフィールドが値1を持っていた場合は、クライアントがファイルハンドルを経由してオブジェクトを参照するに頼るべきではありません。同様に、クライアントは以前すぐに利用可能になってきたオブジェクトに関連付けられたリソース（ディスク容量、ディレクトリエントリなど）に依存しないでください。クライアントは、それを削除するREMOVEを使用した後、ファイルへのアクセスを継続できるようにする必要がある場合はこのように、クライアントは、ファイルがまだアクセス可能になることを確認する手順を実行する必要があります。使用される通常のメカニズムは、新しい隠された名前に古い名前からファイルの名前を変更することです。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_NOTEMPTY NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_NOTEMPTY NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT
NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(sfh), oldname (cfh), newname -> source_change_info, target_change_info
（SFH）、OLDNAME（CFH）、NEWNAME - > source_change_info、target_change_info
ARGUMENT
引数
struct RENAME4args {
/* SAVED_FH: source directory */
component4 oldname;
/* CURRENT_FH: target directory */
component4 newname;
};
RESULT
結果
struct RENAME4resok {
change_info4 source_cinfo;
change_info4 target_cinfo;
};
union RENAME4res switch (nfsstat4 status) {
case NFS4_OK:
RENAME4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The RENAME operation renames the object identified by oldname in the source directory corresponding to the saved filehandle, as set by the SAVEFH operation, to newname in the target directory corresponding to the current filehandle. The operation is required to be atomic to the client. Source and target directories must reside on the same file system on the server. On success, the current filehandle will continue to be the target directory.
現在のファイルハンドルに対応するターゲットディレクトリにnewnameに、SAVEFH操作によって設定さRENAME操作は、保存されたファイルハンドルに対応するソースディレクトリにOLDNAMEによって識別されたオブジェクトの名前を変更します。操作は、クライアント原子であることが必要です。ソースとターゲットのディレクトリには、サーバー上の同じファイルシステム上に存在する必要があります。成功すると、現在のファイルハンドルは、ターゲットディレクトリであり続けるだろう。
If the target directory already contains an entry with the name, newname, the source object must be compatible with the target: either both are non-directories or both are directories and the target must be empty. If compatible, the existing target is removed before the rename occurs. If they are not compatible or if the target is a directory but not empty, the server will return the error, NFS4ERR_EXIST.
ターゲットディレクトリが既に名前、newnameの持つエントリが含まれている場合は、ソースオブジェクトがターゲットと互換性がなければならない：両方が非ディレクトリであるか、両方のディレクトリであり、ターゲットは空である必要があります。互換性のある場合は、名前変更が発生する前に、既存のターゲットが削除されます。彼らは互換性がないか、対象がディレクトリであるが、空でない場合、サーバは、NFS4ERR_EXISTをエラーが返されます。
If oldname and newname both refer to the same file (they might be hard links of each other), then RENAME should perform no action and return success.
OLDNAMEとnewnameの両方が同じファイルを参照する場合は、何もアクションを実行しないと成功を返す必要がありRENAME（彼らはお互いのハードリンクであるかもしれません）。
For both directories involved in the RENAME, the server returns change_info4 information. With the atomic field of the change_info4 struct, the server will indicate if the before and after change attributes were obtained atomically with respect to the rename.
RENAMEにかかわる両方のディレクトリの場合、サーバーは変化_info4情報を返します。前と後の変更属性が名前の変更に関して原子論が得られた場合には変化_info4構造体の原子分野、意志が示すサーバ。
If the oldname or newname has a length of 0 (zero), or if oldname or newname does not obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned.
OLDNAMEまたはNEWNAMEが0（ゼロ）の長さを有する場合、またはOLDNAMEまたはNEWNAMEがUTF-8定義に従わない場合、エラーNFS4ERR_INVALが返されます。
IMPLEMENTATION
実装
The RENAME operation must be atomic to the client. The statement "source and target directories must reside on the same file system on the server" means that the fsid fields in the attributes for the directories are the same. If they reside on different file systems, the error, NFS4ERR_XDEV, is returned.
RENAME操作はクライアントにアトミックでなければなりません。声明「ソースとターゲットのディレクトリサーバー上の同じファイルシステム上に存在する必要があり、」ディレクトリの属性におけるFSIDフィールドが同じであることを意味します。彼らは異なるファイルシステム上に存在する場合は、エラー、NFS4ERR_XDEVは、返されます。
A filehandle may or may not become stale or expire on a rename. However, server implementors are strongly encouraged to attempt to keep file handles from becoming stale or expiring in this fashion.
ファイルハンドルは、あるいは陳腐化や名前の変更には有効期限が切れていない場合があります。ただし、サーバーの実装を強く古くなってきたり、この方法で期限切れからファイルハンドルを維持しようとすることが奨励されています。
On some servers, the filenames, "." and "..", are illegal as either oldname or newname. In addition, neither oldname nor newname can be an alias for the source directory. These servers will return the error, NFS4ERR_INVAL, in these cases.
一部のサーバーでは、ファイル名、「」そして、「..」、OLDNAMEまたはnewnameのいずれかとして違法です。また、OLDNAMEもnewnameのどちらがソースディレクトリのエイリアスすることができます。これらのサーバーは、これらのケースでは、エラー、NFS4ERR_INVALを返します。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_DQUOT NFS4ERR_EXIST NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_ISDIR NFS4ERR_MOVED NFS4ERR_NAMETOOLONG
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_DQUOT NFS4ERR_EXIST NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_ISDIR NFS4ERR_MOVED NFS4ERR_NAMETOOLONG
NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_NOTDIR NFS4ERR_NOTEMPTY NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC NFS4ERR_XDEV
NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_NOTDIR NFS4ERR_NOTEMPTY NFS4ERR_NOTSUPP NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC NFS4ERR_XDEV
SYNOPSIS
SYNOPSIS
stateid -> ()
stateid - >（）
ARGUMENT
引数
struct RENEW4args {
stateid4 stateid;
};
RESULT
結果
struct RENEW4res {
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
The RENEW operation is used by the client to renew leases which it currently holds at a server. In processing the RENEW request, the server renews all leases associated with the client. The associated leases are determined by the client id provided via the SETCLIENTID procedure.
RENEW操作は、それが現在のサーバで保持しているリースを更新するために、クライアントによって使用されます。 RENEW要求を処理するには、サーバーは、クライアントに関連付けられているすべてのリースを更新します。関連リースはSETCLIENTID手順を介して提供されるクライアントIDによって決定されます。
The stateid for RENEW may not be one of the special stateids consisting of all bits 0 (zero) or all bits 1.
RENEWのためのstateidはすべてのビット0（ゼロ）または全ビット1からなる特別のstateidsの一つではないかもしれません。
IMPLEMENTATION
実装
ERRORS
エラー
NFS4ERR_BAD_STATEID NFS4ERR_EXPIRED
NFS4ERR_BAD_STATEID NFS4ERR_EXPIRED
NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_LEASE_MOVED NFS4ERR_MOVED NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_LEASE_MOVED NFS4ERR_MOVED NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(sfh) -> (cfh)
（SFH） - >（CFH）
ARGUMENT
引数
/* SAVED_FH: */
void;
RESULT
結果
struct RESTOREFH4res {
/* CURRENT_FH: value of saved fh */
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
Set the current filehandle to the value in the saved filehandle. If there is no saved filehandle then return an error NFS4ERR_NOFILEHANDLE.
保存されたファイルハンドルの値に現在のファイルハンドルを設定します。何も保存されたファイルハンドルがない場合、エラーNFS4ERR_NOFILEHANDLEを返します。
IMPLEMENTATION
実装
Operations like OPEN and LOOKUP use the current filehandle to represent a directory and replace it with a new filehandle. Assuming the previous filehandle was saved with a SAVEFH operator, the previous filehandle can be restored as the current filehandle. This is commonly used to obtain post-operation attributes for the directory, e.g.
OPENとLOOKUPのような操作は、ディレクトリを表し、新しいファイルハンドルでそれを置き換えるために、現在のファイルハンドルを使用します。 SAVEFH演算子で保存された前回のファイルハンドルを仮定すると、以前のファイルハンドルは、現在のファイルハンドルとして復元することができます。これは、一般的に、例えば、ディレクトリのポスト操作属性を取得するために使用されます
PUTFH (directory filehandle)
SAVEFH
GETATTR attrbits (pre-op dir attrs)
CREATE optbits "foo" attrs
GETATTR attrbits (file attributes)
RESTOREFH GETATTR attrbits (post-op dir attrs)
RESTOREFH GETATTRのattrbits（術後ますattrsに）
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh) -> (sfh)
（CFH） - >（SFH）
ARGUMENT
引数
/* CURRENT_FH: */
void;
RESULT
結果
struct SAVEFH4res {
/* SAVED_FH: value of current fh */
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
Save the current filehandle. If a previous filehandle was saved then it is no longer accessible. The saved filehandle can be restored as the current filehandle with the RESTOREFH operator.
現在のファイルハンドルを保存します。以前のファイルハンドルを保存した場合、それはアクセスできなくなります。保存されたファイルハンドルはRESTOREFH演算子で、現在のファイルハンドルとして復元することができます。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE
NFS4 ERR_BADHANDLE NFS4 ERR_FHEXPIRED NFS4 ERR_MOVED NFS4 ERR_NOFILEHANDLE
NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), name -> { secinfo }
（CFH）、名前 - > {} SECINFO
ARGUMENT
引数
struct SECINFO4args {
/* CURRENT_FH: */
component4 name;
};
RESULT
結果
enum rpc_gss_svc_t { RPC_GSS_SVC_NONE = 1, RPC_GSS_SVC_INTEGRITY = 2, RPC_GSS_SVC_PRIVACY = 3 };
列挙rpc_gss_svc_t {RPC_GSS_SVC_NONE = 1、RPC_GSS_SVC_INTEGRITY = 2、RPC_GSS_SVC_PRIVACY = 3}。
struct rpcsec_gss_info {
sec_oid4 oid;
qop4 qop;
rpc_gss_svc_t service;
};
struct secinfo4 {
uint32_t flavor;
opaque flavor_info<>; /* null for AUTH_SYS, AUTH_NONE;
contains rpcsec_gss_info for
RPCSEC_GSS. */
};
typedef secinfo4 SECINFO4resok<>;
typedefのsecinfo4 SECINFO4resok <>。
union SECINFO4res switch (nfsstat4 status) {
case NFS4_OK:
SECINFO4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The SECINFO operation is used by the client to obtain a list of valid RPC authentication flavors for a specific file handle, file name pair. The result will contain an array which represents the security mechanisms available. The array entries are represented by the secinfo4 structure. The field 'flavor' will contain a value of AUTH_NONE, AUTH_SYS (as defined in [RFC1831]), or RPCSEC_GSS (as defined in [RFC2203]).
SECINFO操作は、ファイル名のペア、特定のファイルハンドルの有効なRPC認証フレーバのリストを取得するために、クライアントによって使用されます。結果は、利用可能なセキュリティメカニズムを表す配列を含むであろう。アレイエントリはsecinfo4構造によって表されます。フィールド '風味'（[RFC2203]で定義されるように）AUTH_NONE、AUTH_SYS（[RFC1831]で定義される）の値を含む、またはRPCSEC_GSSう。
For the flavors, AUTH_NONE, and AUTH_SYS no additional security information is returned. For a return value of RPCSEC_GSS, a security triple is returned that contains the mechanism object id (as defined in [RFC2078]), the quality of protection (as defined in [RFC2078]) and the service type (as defined in [RFC2203]). It is possible for SECINFO to return multiple entries with flavor equal to RPCSEC_GSS with different security triple values.
味については、AUTH_NONE、およびAUTH_SYSは、追加のセキュリティ情報が返されません。 RPCSEC_GSSの戻り値を、三重セキュリティは機構のオブジェクトID（[RFC2078]で定義されるように）、保護の品質（[RFC2078]で定義されるように）とサービスタイプを（[RFC2203]で定義されるように含まれる返されます）。 SECINFOが異なるセキュリティトリプル値のRPCSEC_GSSと等しい味で複数のエントリを返すことが可能です。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
The SECINFO operation is expected to be used by the NFS client when the error value of NFS4ERR_WRONGSEC is returned from another NFS operation. This signifies to the client that the server's security policy is different from what the client is currently using. At this point, the client is expected to obtain a list of possible security flavors and choose what best suits its policies.
SECINFO操作はNFS4ERR_WRONGSECのエラー値が別のNFS操作から返されたNFSクライアントによって使用されることが期待されます。これは、サーバーのセキュリティポリシーは、クライアントが現在使用しているものと異なっていることをクライアントに示します。この時点で、クライアントが可能なセキュリティ風味のリストを取得し、最高のは、そのポリシーに合ったものを選択することが期待されています。
It is recommended that the client issue the SECINFO call protected by a security triple that uses either rpc_gss_svc_integrity or rpc_gss_svc_privacy service. The use of rpc_gss_svc_none would allow an attacker in the middle to modify the SECINFO results such that the client might select a weaker algorithm in the set allowed by server, making the client and/or server vulnerable to further attacks.
それは推奨されているクライアントの問題rpc_gss_svc_integrityまたはrpc_gss_svc_privacyサービスのいずれかを使用して、セキュリティで保護されたトリプルSECINFOコール。 rpc_gss_svc_noneの使用は、さらなる攻撃へのクライアントおよび/またはサーバが脆弱作り、真ん中の攻撃者は、クライアントがサーバーによって許可されたセットの中の弱いアルゴリズムを選択するかもしれないようにSECINFO結果を変更することができます。
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT
NFS4ERR_BADHANDLE NFS4ERR_FHEXPIRED NFS4ERR_MOVED NFS4ERR_NAMETOOLONG NFS4ERR_NOENT NFS4ERR_NOFILEHANDLE NFS4ERR_NOTDIR NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT
NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), attrbits, attrvals -> -
（CFH）、attrbits、attrvals - > -
ARGUMENT
引数
struct SETATTR4args {
/* CURRENT_FH: target object */
stateid4 stateid;
fattr4 obj_attributes;
};
RESULT
結果
struct SETATTR4res {
nfsstat4 status;
bitmap4 attrsset;
};
DESCRIPTION
DESCRIPTION
The SETATTR operation changes one or more of the attributes of a file system object. The new attributes are specified with a bitmap and the attributes that follow the bitmap in bit order.
SETATTR操作は、ファイル・システム・オブジェクトの属性の一つ以上を変更します。新しい属性は、ビットマップとビット順にビットマップに従った属性で指定されています。
The stateid is necessary for SETATTRs that change the size of a file (modify the attribute object_size). This stateid represents a record lock, share reservation, or delegation which must be valid for the SETATTR to modify the file data. A valid stateid would always be specified. When the file size is not changed, the special stateid consisting of all bits 0 (zero) should be used.
stateidは（属性オブジェクト_を変更）ファイルのサイズを変更SETATTRsするために必要です。これのstateidはSETATTRは、ファイルのデータを修正するために有効である必要がありますレコードロック、共有予約、または委任を表します。有効なstateidは常に指定されます。ファイルサイズが変更されていない場合、すべてのビットが0（ゼロ）から成る特別のstateidを使用すべきです。
On either success or failure of the operation, the server will return the attrsset bitmask to represent what (if any) attributes were successfully set.
属性正常に設定された（もしあれば）は、操作の成功または失敗のいずれかで、サーバが何を表現するためにattrssetビットマスクを返します。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
The file size attribute is used to request changes to the size of a file. A value of 0 (zero) causes the file to be truncated, a value less than the current size of the file causes data from new size to the end of the file to be discarded, and a size greater than the current size of the file causes logically zeroed data bytes to be added to the end of the file. Servers are free to implement this using holes or actual zero data bytes. Clients should not make any assumptions regarding a server's implementation of this feature, beyond that the bytes returned will be zeroed. Servers must support extending the file size via SETATTR.
ファイルサイズ属性は、ファイルのサイズの変更を要求するのに使用されます。 0（ゼロ）の値は、ファイルがファイルの現在のサイズより小さい値を廃棄するファイルの末尾に新たなサイズのデータを生じ、切り捨て、およびさせるファイルの現在のサイズよりも大きいサイズ論理的にファイルの末尾に追加されるデータのバイト数をゼロになります。サーバはこの使用して穴や実際のゼロデータのバイト数を自由に実装できます。クライアントは、返されたバイトがゼロにされることを超えて、この機能のサーバの実装に関するいかなる仮定を行うべきではありません。サーバはSETATTRを経由してファイルサイズを拡張サポートしている必要があります。
SETATTR is not guaranteed atomic. A failed SETATTR may partially change a file's attributes.
SETATTRは原子保証されません。失敗したSETATTRは、部分的にファイルの属性を変更することがあります。
Changing the size of a file with SETATTR indirectly changes the time_modify. A client must account for this as size changes can result in data deletion.
SETATTRとファイルのサイズを変更すると、間接的にtime_modifyを変更します。サイズの変更は、データの削除につながることができますように、クライアントは、このことを考慮しなければなりません。
If server and client times differ, programs that compare client time to file times can break. A time maintenance protocol should be used to limit client/server time skew.
サーバーとクライアントの時間が異なる場合は、時間をファイルにクライアントの時間を比較するプログラムが壊れることができます。タイムメンテナンスプロトコルは、クライアント/サーバ時間スキューを制限するために使用する必要があります。
If the server cannot successfully set all the attributes it must return an NFS4ERR_INVAL error. If the server can only support 32 bit offsets and sizes, a SETATTR request to set the size of a file to larger than can be represented in 32 bits will be rejected with this same error.
サーバーが正常にすべての属性を設定することができない場合には、NFS4ERR_INVALエラーを返さなければなりません。サーバーは、32ビットのオフセットとサイズをサポートできる場合、32ビットで表現することができるよりも大きなにファイルのサイズを設定するSETATTR要求は、この同じエラーで拒否されます。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_DQUOT NFS4ERR_EXPIRED NFS4ERR_FBIG NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_NOTSUPP NFS4ERR_OLD_STATEID NFS4ERR_PERM NFS4ERR_RESOURCE NFS4ERR_ROFS
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_DQUOT NFS4ERR_EXPIRED NFS4ERR_FBIG NFS4ERR_FHEXPIRED NFS4ERR_GRACE NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_NOTSUPP NFS4ERR_OLD_STATEID NFS4ERR_PERM NFS4ERR_RESOURCE NFS4ERR_ROFS
NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
client, callback -> clientid, setclientid_confirm
クライアントコールバック - >のClientID、SETCLIENTID_CONFIRM
ARGUMENT
引数
struct SETCLIENTID4args {
nfs_client_id4 client;
cb_client4 callback;
};
RESULT
結果
struct SETCLIENTID4resok {
clientid4 clientid;
verifier4 setclientid_confirm;
};
union SETCLIENTID4res switch (nfsstat4 status) {
case NFS4_OK:
SETCLIENTID4resok resok4;
case NFS4ERR_CLID_INUSE:
clientaddr4 client_using;
default:
void;
};
DESCRIPTION
DESCRIPTION
The SETCLIENTID operation introduces the ability of the client to notify the server of its intention to use a particular client identifier and verifier pair. Upon successful completion the server will return a clientid which is used in subsequent file locking requests and a confirmation verifier. The client will use the SETCLIENTID_CONFIRM operation to return the verifier to the server. At that point, the client may use the clientid in subsequent operations that require an nfs_lockowner.
SETCLIENTID操作は、特定のクライアント識別子と検証ペアを使用する意向をサーバに通知するクライアントの能力を導入します。正常に完了すると、サーバーは、後続のファイルのロック要求と確認検証に使用されているのClientIDを返します。クライアントは、サーバーに検証を返すためにSETCLIENTID_CONFIRM操作を使用します。その時点で、クライアントはnfs_lockownerのを必要とする後続の操作でのClientIDを使用することができます。
The callback information provided in this operation will be used if the client is provided an open delegation at a future point. Therefore, the client must correctly reflect the program and port numbers for the callback program at the time SETCLIENTID is used.
クライアントは、将来の時点で開いている委譲を提供する場合は、この操作で提供されるコールバック情報が使用されます。したがって、クライアントが正しくSETCLIENTIDが使用されている時にコールバックプログラムのためのプログラムとポート番号を反映しなければなりません。
IMPLEMENTATION
実装
The server takes the verifier and client identification supplied in the nfs_client_id4 and searches for a match of the client identification. If no match is found the server saves the principal/uid information along with the verifier and client identification and returns a unique clientid that is used as a shorthand reference to the supplied information.
サーバは、クライアント識別の一致のためのnfs_client_id4と検索に供給し、検証し、クライアント識別をとります。一致が見つからない場合、サーバは、検証およびクライアント識別と共に主/ UID情報を保存し、供給された情報に速記参照として使用される一意のClientIDを返します。
If the server finds matching client identification and a corresponding match in principal/uid, the server releases all locking state for the client and returns a new clientid.
サーバは、クライアントの識別および主要/ UIDに対応するマッチに一致が見つかった場合、サーバ・リリースは、すべてのクライアントの状態をロックし、新しいクライアントIDを返します。
The principal, or principal to user-identifier mapping is taken from the credential presented in the RPC. As mentioned, the server will use the credential and associated principal for the matching with existing clientids. If the client is a traditional host-based client like a Unix NFS client, then the credential presented may be the host credential. If the client is a user level client or lightweight client, the credential used may be the end user's credential. The client should take care in choosing an appropriate credential since denial of service attacks could be attempted by a rogue client that has access to the credential.
ユーザ識別子へのマッピングプリンシパル、またはプリンシパルはRPCに提示資格から取られます。上述したように、サーバは、既存のClientIDとのマッチングのための資格および関連するプリンシパルを使用します。クライアントがUNIXのNFSクライアントのような伝統的なホストベースのクライアントである場合には、提示資格は、ホスト資格かもしれません。クライアントは、ユーザーレベルのクライアントや軽量クライアントである場合は、使用する資格は、エンドユーザーの資格情報かもしれません。クライアントは、サービス拒否攻撃が資格へのアクセス権を持つ不正なクライアントによって試みられる可能性があるので、適切な資格情報を選択する際に注意する必要があります。
ERRORS
エラー
NFS4ERR_CLID_INUSE NFS4ERR_INVAL NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT
NFS4ERR_CLID_INUSE NFS4ERR_INVAL NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT
SYNOPSIS
SYNOPSIS
setclientid_confirm -> -
SETCLIENTID確認 - > -
ARGUMENT
引数
struct SETCLIENTID_CONFIRM4args {
verifier4 setclientid_confirm;
};
RESULT
結果
struct SETCLIENTID_CONFIRM4res {
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
This operation is used by the client to confirm the results from a previous call to SETCLIENTID. The client provides the server supplied (from a SETCLIENTID response) opaque confirmation verifier. The server responds with a simple status of success or failure.
この操作は、SETCLIENTIDへの以前の呼び出しからの結果を確認するために、クライアントによって使用されます。クライアントは、（SETCLIENTID応答から）提供されるサーバの不透明な確認検証を提供します。サーバーは、成功か失敗かの簡単な状況で応答します。
IMPLEMENTATION
実装
The client must use the SETCLIENTID_CONFIRM operation to confirm its use of client identifier. If the server is holding state for a client which has presented a new verifier via SETCLIENTID, then the state will not be released, as described in the section "Client Failure and Recovery", until a valid SETCLIENTID_CONFIRM is received. Upon successful confirmation the server will release the previous state held on behalf of the client. The server should choose a confirmation cookie value that is reasonably unique for the client.
クライアントは、クライアント識別子の使用を確認するためにSETCLIENTID_CONFIRM操作を使用する必要があります。サーバがSETCLIENTIDを経由して、新たな検証を提示したクライアントの状態を保持している場合は、「クライアントの障害および回復」で説明したように、有効なSETCLIENTID_CONFIRMが受信されるまで、その状態が、解放されません。成功確認すると、サーバはクライアントに代わって開催された以前の状態を解放します。サーバは、クライアントのために合理的にユニークな確認Cookieの値を選択する必要があります。
ERRORS
エラー
NFS4ERR_CLID_INUSE NFS4ERR_INVAL NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE_CLIENTID
NFS4ERR_CLID_INUSE NFS4ERR_INVAL NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE_CLIENTID
SYNOPSIS
SYNOPSIS
(cfh), fattr -> -
（CFH）、fattr - > -
ARGUMENT
引数
struct VERIFY4args {
/* CURRENT_FH: object */
fattr4 obj_attributes;
};
RESULT
結果
struct VERIFY4res {
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
The VERIFY operation is used to verify that attributes have a value assumed by the client before proceeding with following operations in the compound request. If any of the attributes do not match then the error NFS4ERR_NOT_SAME must be returned. The current filehandle retains its value after successful completion of the operation.
ベリファイ動作は、属性が複合要求に次の操作に進む前に、クライアントが想定値を有することを確認するために使用されます。属性のいずれかが一致しない場合は、エラーNFS4ERR_NOT_SAMEを返さなければなりません。現在のファイルハンドルは、操作が正常に完了した後にその値を保持します。
IMPLEMENTATION
実装
One possible use of the VERIFY operation is the following compound sequence. With this the client is attempting to verify that the file being removed will match what the client expects to be removed. This sequence can help prevent the unintended deletion of a file.
ベリファイ動作の一つの可能な用途は、以下の化合物配列です。これにより、クライアントは削除されたファイルは、クライアントが削除されることを想定しているものと一致することを検証しようとしています。このシーケンスは、ファイルの意図しない削除を防ぐことができます。
PUTFH (directory filehandle)
LOOKUP (file name)
VERIFY (filehandle == fh)
PUTFH (directory filehandle)
REMOVE (file name)
This sequence does not prevent a second client from removing and creating a new file in the middle of this sequence but it does help avoid the unintended result.
このシーケンスは、このシーケンスの途中で新しいファイルを削除し、作成から2番目のクライアントを防ぐことはできませんが、それは予期しない結果を回避するのに役立つん。
In the case that a recommended attribute is specified in the VERIFY operation and the server does not support that attribute for the file system object, the error NFS4ERR_NOTSUPP is returned to the client.
推奨属性がVERIFY操作で指定され、サーバがファイル・システム・オブジェクトのためにその属性をサポートしていない場合は、エラーNFS4ERR_NOTSUPPがクライアントに返されます。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_DELAY NFS4ERR_FHEXPIRED NFS4ERR_INVAL NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOTSUPP
NFS4ERR_NOT_SAME NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
NFS4ERR_NOT_SAME NFS4ERR_RESOURCE NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_WRONGSEC
SYNOPSIS
SYNOPSIS
(cfh), offset, count, stability, stateid, data -> count, committed, verifier
（CFH）、オフセット数え、安定性、のstateid、データ - >数、コミットし、検証
ARGUMENT
引数
enum stable_how4 { UNSTABLE4 = 0, DATA_SYNC4 = 1, FILE_SYNC4 = 2 };
列挙stable_how4 {UNSTABLE4 = 0、DATA_SYNC4 = 1、FILE_SYNC4 = 2}。
struct WRITE4args {
/* CURRENT_FH: file */
stateid4 stateid;
offset4 offset;
stable_how4 stable;
opaque data<>;
};
RESULT
結果
struct WRITE4resok {
count4 count;
stable_how4 committed;
verifier4 writeverf;
};
union WRITE4res switch (nfsstat4 status) {
case NFS4_OK:
WRITE4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The WRITE operation is used to write data to a regular file. The target file is specified by the current filehandle. The offset specifies the offset where the data should be written. An offset of 0 (zero) specifies that the write should start at the beginning of the file. The count represents the number of bytes of data that are to be written. If the count is 0 (zero), the WRITE will succeed and return a count of 0 (zero) subject to permissions checking. The server may choose to write fewer bytes than requested by the client.
WRITE操作は、通常のファイルにデータを書き込むために使用されます。対象のファイルは、現在のファイルハンドルで指定されています。オフセットは、データが書き込まれるべき場所オフセットを指定します。 0（ゼロ）のオフセットを書き込み、ファイルの先頭から開始することを指定します。カウントが書き込まれるデータのバイト数を表します。カウントが0（ゼロ）の場合、WRITEは成功し、チェック権限に0（ゼロ）は、被験者の数を返します。サーバは、クライアントから要求されたよりも少ないバイトを書くことを選んでもよいです。
Part of the write request is a specification of how the write is to be performed. The client specifies with the stable parameter the method of how the data is to be processed by the server. If stable is FILE_SYNC4, the server must commit the data written plus all file system metadata to stable storage before returning results. This corresponds to the NFS version 2 protocol semantics. Any other behavior constitutes a protocol violation. If stable is DATA_SYNC4, then the server must commit all of the data to stable storage and enough of the metadata to retrieve the data before returning. The server implementor is free to implement DATA_SYNC4 in the same fashion as FILE_SYNC4, but with a possible performance drop. If stable is UNSTABLE4, the server is free to commit any part of the data and the metadata to stable storage, including all or none, before returning a reply to the client. There is no guarantee whether or when any uncommitted data will subsequently be committed to stable storage. The only guarantees made by the server are that it will not destroy any data without changing the value of verf and that it will not commit the data and metadata at a level less than that requested by the client.
書き込み要求の一部は、書き込みが行われるべきかの仕様です。クライアントは、安定したパラメータを使用してデータがサーバによって処理されるかの方法を指定します。安定がFILE_SYNC4であれば、サーバは結果を返す前に、安定したストレージに書き込まれたデータに加えて、すべてのファイルシステムのメタデータをコミットする必要があります。これは、NFSバージョン2プロトコルのセマンティクスに対応しています。その他の動作は、プロトコル違反を構成しています。安定がDATA_SYNC4ある場合、サーバーは安定して保管し、返す前にデータを取得するメタデータの十分にすべてのデータをコミットする必要があります。サーバ実装者はFILE_SYNC4と同じように、しかし、可能性、パフォーマンスの低下とDATA_SYNC4を実装して自由です。安定がUNSTABLE4ある場合、サーバーはクライアントへの応答を返す前に、すべてまたはnoneを含む安定したストレージへのデータの任意の部分とメタデータをコミットして自由です。コミットされていないデータは、その後安定したストレージにコミットするかどうかとき保証はありません。サーバによって作られた唯一の保証は、それがVERFの値を変更することなく、任意のデータを破壊し、それがクライアントによって要求されたよりも低いレベルでのデータとメタデータをコミットしていないということではないだろうということです。
The stateid returned from a previous record lock or share reservation request is provided as part of the argument. The stateid is used by the server to verify that the associated lock is still valid and to update lease timeouts for the client.
前のレコードロックまたは共有の予約要求から返されたstateidは、引数の一部として提供されます。 stateidは、関連するロックがまだ有効であることを確認するために、クライアントのリースのタイムアウトを更新するためにサーバによって使用されています。
Upon successful completion, the following results are returned. The count result is the number of bytes of data written to the file. The server may write fewer bytes than requested. If so, the actual number of bytes written starting at location, offset, is returned.
正常に完了すると、次の結果が返されます。カウント結果はファイルに書き込まれたデータのバイト数です。サーバーは、要求されたよりも少ないバイトを書き込むことができます。その場合、位置から始まる書き込まれたバイトの実際の数は、オフセット、戻されます。
The server also returns an indication of the level of commitment of the data and metadata via committed. If the server committed all data and metadata to stable storage, committed should be set to FILE_SYNC4. If the level of commitment was at least as strong as DATA_SYNC4, then committed should be set to DATA_SYNC4. Otherwise, committed must be returned as UNSTABLE4. If stable was FILE4_SYNC, then committed must also be FILE_SYNC4: anything else constitutes a protocol violation. If stable was DATA_SYNC4, then committed may be FILE_SYNC4 or DATA_SYNC4: anything else constitutes a protocol violation. If stable was UNSTABLE4, then committed may be either FILE_SYNC4, DATA_SYNC4, or UNSTABLE4.
また、サーバーはコミットを介したデータおよびメタデータのコミットメントのレベルを示す値を返します。サーバーが安定したストレージにすべてのデータとメタデータを犯した場合、コミットはFILE_SYNC4に設定する必要があります。コミットメントのレベルがDATA_SYNC4と少なくとも同じくらい強かった場合、コミットはDATA_SYNC4に設定する必要があります。そうでない場合、コミットはUNSTABLE4として返さなければなりません。安定したがFILE4_SYNCた場合は、コミットもFILE_SYNC4でなければなりません：他の何かがプロトコル違反を構成しています。安定したがDATA_SYNC4た場合は、コミットFILE_SYNC4またはDATA_SYNC4ことがあります何か他のものは、プロトコル違反を構成しています。安定したがUNSTABLE4た場合は、コミットFILE_SYNC4、DATA_SYNC4、またはUNSTABLE4のいずれであってもよいです。
The final portion of the result is the write verifier, verf. The write verifier is a cookie that the client can use to determine whether the server has changed state between a call to WRITE and a subsequent call to either WRITE or COMMIT. This cookie must be consistent during a single instance of the NFS version 4 protocol service and must be unique between instances of the NFS version 4 protocol server, where uncommitted data may be lost.
結果の最後の部分は、書き込み検証、VERFあります。書き込み検証は、クライアントがサーバがWRITEへの呼び出しとWRITEかCOMMITのどちらかへのその後の呼び出しの間で状態を変更したかどうかを判断するために使用できるクッキーです。このクッキーは、NFSバージョン4プロトコルサービスの単一のインスタンス間に一貫性がなければならず、コミットされていないデータが失われる可能性がNFSバージョン4プロトコルサーバのインスタンス間で一意でなければなりません。
If a client writes data to the server with the stable argument set to UNSTABLE4 and the reply yields a committed response of DATA_SYNC4 or UNSTABLE4, the client will follow up some time in the future with a COMMIT operation to synchronize outstanding asynchronous data and metadata with the server's stable storage, barring client error. It is possible that due to client crash or other error that a subsequent COMMIT will not be received by the server.
クライアントがUNSTABLE4に設定された安定した引数を使用してサーバにデータを書き込み、返信がDATA_SYNC4またはUNSTABLE4のコミット応答を生成する場合は、クライアントが持つ優れた非同期データおよびメタデータを同期させるためにCOMMIT操作で、将来的にいくつかの時間をフォローアップしますサーバの安定したストレージ、クライアントエラーがなければ。その後のCOMMITというクライアントのクラッシュまたはその他のエラーが原因で、サーバによって受信されない可能性があります。
On success, the current filehandle retains its value.
成功すると、現在のファイルハンドルは、その値を保持します。
IMPLEMENTATION
実装
It is possible for the server to write fewer than count bytes of data. In this case, the server should not return an error unless no data was written at all. If the server writes less than count bytes, the client should issue another WRITE to write the remaining data.
サーバーがデータのバイト数を数えるよりも少ないを書くことが可能です。データが全く書かれていない限りこの場合、サーバがエラーを返すべきではありません。サーバがカウントバイト未満に書き込む場合は、クライアントが残りのデータを書き込むために、別のWRITEを発行する必要があります。
It is assumed that the act of writing data to a file will cause the time_modified of the file to be updated. However, the time_modified of the file should not be changed unless the contents of the file are changed. Thus, a WRITE request with count set to 0 should not cause the time_modified of the file to be updated.
ファイルにデータを書き込む行為は、ファイルのtime_modifiedが更新されますと仮定されます。ファイルの内容が変更されない限りただし、ファイルのtime_modifiedは変更すべきではありません。このように、0に設定されたカウントと書き込み要求がファイルのtime_modifiedをアップデートするべきではありません。
The definition of stable storage has been historically a point of contention. The following expected properties of stable storage may help in resolving design issues in the implementation. Stable storage is persistent storage that survives:
貯蔵安定性の定義は歴史的に競合のポイントとなっています。安定したストレージの以下の期待される特性は、実装に設計上の問題の解決に役立つことがあります。安定したストレージは生き残る永続的なストレージです。
1. Repeated power failures.
2. Hardware failures (of any board, power supply, etc.).
3. Repeated software crashes, including reboot cycle.
This definition does not address failure of the stable storage module itself.
この定義は、安定したストレージモジュール自体の故障に対応していません。
The verifier is defined to allow a client to detect different instances of an NFS version 4 protocol server over which cached, uncommitted data may be lost. In the most likely case, the verifier allows the client to detect server reboots. This information is required so that the client can safely determine whether the server could have lost cached data. If the server fails unexpectedly and the client has uncommitted data from previous WRITE requests (done with the stable argument set to UNSTABLE4 and in which the result committed was returned as UNSTABLE4 as well) it may not have flushed cached data to stable storage. The burden of recovery is on the client and the client will need to retransmit the data to the server.
検証者は、コミットされていないデータが失われる可能性があり、キャッシュされたその上NFSバージョン4プロトコルサーバの異なるインスタンスを検出するためのクライアントを許可するように定義されています。最も可能性が高い場合には、検証は、クライアントがサーバーの再起動を検出することができます。クライアントが安全にサーバがキャッシュされたデータを失っていることができるかどうかを判断できるように、この情報が必要になります。サーバーが予期せずに失敗し、クライアントは、前のWRITE要求（UNSTABLE4に設定された安定した引数で行われ、結果はコミットしているが、同様UNSTABLE4として返された）からのコミットされていないデータがある場合には、安定したストレージにキャッシュされたデータをフラッシュしていない可能性があり。回復の負担は、クライアント上で、クライアントがサーバにデータを再送信する必要があります。
A suggested verifier would be to use the time that the server was booted or the time the server was last started (if restarting the server without a reboot results in lost buffers).
提案検証は、サーバが起動された時刻または（失われたバッファにリブート結果なしでサーバーを再起動する場合）、サーバーが最後に開始された時刻を使用することです。
The committed field in the results allows the client to do more effective caching. If the server is committing all WRITE requests to stable storage, then it should return with committed set to FILE_SYNC4, regardless of the value of the stable field in the arguments. A server that uses an NVRAM accelerator may choose to implement this policy. The client can use this to increase the effectiveness of the cache by discarding cached data that has already been committed on the server.
結果内のコミットフィールドは、クライアントがより効果的なキャッシングを行うことができます。サーバーが安定したストレージにすべてのWRITE要求をコミットしている場合、それは関係なく、引数で安定したフィールドの値の、FILE_SYNC4にコミット設定して返す必要があります。 NVRAMアクセラレータを使用するサーバーは、このポリシーを実装することを選択できます。クライアントがすでにサーバーにコミットされたキャッシュされたデータを破棄することにより、キャッシュの有効性を高めるためにこれを使用することができます。
Some implementations may return NFS4ERR_NOSPC instead of NFS4ERR_DQUOT when a user's quota is exceeded.
ユーザのクォータを超えた場合、いくつかの実装がNFS4ERR_DQUOTの代わりにNFS4ERR_NOSPCを返すことがあります。
ERRORS
エラー
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_DQUOT NFS4ERR_EXPIRED NFS4ERR_FBIG NFS4ERR_FHEXPIRED NFS4ERR_GRACE
NFS4ERR_ACCES NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_DELAY NFS4ERR_DENIED NFS4ERR_DQUOT NFS4ERR_EXPIRED NFS4ERR_FBIG NFS4ERR_FHEXPIRED NFS4ERR_GRACE
NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_LEASE_MOVED NFS4ERR_LOCKED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
NFS4ERR_INVAL NFS4ERR_IO NFS4ERR_LEASE_MOVED NFS4ERR_LOCKED NFS4ERR_MOVED NFS4ERR_NOFILEHANDLE NFS4ERR_NOSPC NFS4ERR_OLD_STATEID NFS4ERR_RESOURCE NFS4ERR_ROFS NFS4ERR_SERVERFAULT NFS4ERR_STALE NFS4ERR_STALE_STATEID NFS4ERR_WRONGSEC
The procedures used for callbacks are defined in the following sections. In the interest of clarity, the terms "client" and "server" refer to NFS clients and servers, despite the fact that for an individual callback RPC, the sense of these terms would be precisely the opposite.
コールバックのために使用される手順は、次のセクションで定義されています。明瞭にするために、用語「クライアント」と「サーバー」は、個々のコールバックRPCのために、これらの用語の意味は正反対になるという事実にもかかわらず、NFSクライアントとサーバを参照してください。
SYNOPSIS
SYNOPSIS
<null>
<NULL>
ARGUMENT
引数
void;
無効;
RESULT
結果
void;
無効;
DESCRIPTION
DESCRIPTION
Standard NULL procedure. Void argument, void response. Even though there is no direct functionality associated with this procedure, the server will use CB_NULL to confirm the existence of a path for RPCs from server to client.
標準NULL手続き。ボイド引数、無効応答。この手順に関連した直接的な機能はありませんにもかかわらず、サーバは、サーバからクライアントへのRPCのパスの存在を確認するためにCB_NULLを使用します。
ERRORS
エラー
None.
無し。
SYNOPSIS
SYNOPSIS
compoundargs -> compoundres
compoundargs - > compoundres
ARGUMENT
引数
enum nfs_cb_opnum4 { OP_CB_GETATTR = 3, OP_CB_RECALL = 4 };
列挙{nfs_cb_opnum4 OP_CB_GETATTR = 3、OP_CB_RECALL = 4}。
union nfs_cb_argop4 switch (unsigned argop) {
case OP_CB_GETATTR: CB_GETATTR4args opcbgetattr;
case OP_CB_RECALL: CB_RECALL4args opcbrecall; };
struct CB_COMPOUND4args {
utf8string tag;
uint32_t minorversion;
nfs_cb_argop4 argarray<>; };
RESULT
結果
union nfs_cb_resop4 switch (unsigned resop){
case OP_CB_GETATTR: CB_GETATTR4res opcbgetattr;
case OP_CB_RECALL: CB_RECALL4res opcbrecall; };
struct CB_COMPOUND4res {
nfsstat4 status;
utf8string tag;
nfs_cb_resop4 resarray<>; };
DESCRIPTION
DESCRIPTION
The CB_COMPOUND procedure is used to combine one or more of the callback procedures into a single RPC request. The main callback RPC program has two main procedures: CB_NULL and CB_COMPOUND. All other operations use the CB_COMPOUND procedure as a wrapper.
CB_COMPOUND手順は、単一のRPC要求にコールバック手続きの一つ以上を組み合わせるために使用されます。 CB_NULLとCB_COMPOUND：メインのコールバックRPCプログラムは、主に2つの手順があります。他のすべての操作は、ラッパーとしてCB_COMPOUNDプロシージャを使用します。
In the processing of the CB_COMPOUND procedure, the client may find that it does not have the available resources to execute any or all of the operations within the CB_COMPOUND sequence. In this case, the error NFS4ERR_RESOURCE will be returned for the particular operation within the CB_COMPOUND procedure where the resource exhaustion occurred. This assumes that all previous operations within the CB_COMPOUND sequence have been evaluated successfully.
CB_COMPOUND手順の処理では、クライアントは、それがCB_COMPOUND配列内の操作のいずれか、またはすべてを実行するために使用可能なリソースを持っていないことがあります。この場合、エラーNFS4ERR_RESOURCEは、リソースの枯渇が発生しCB_COMPOUNDプロシージャ内の特定の操作のために返されます。これはCB_COMPOUND配列内のすべての以前の操作が正常に評価されていることを前提としています。
Contained within the CB_COMPOUND results is a 'status' field. This status must be equivalent to the status of the last operation that was executed within the CB_COMPOUND procedure. Therefore, if an operation incurred an error then the 'status' value will be the same error value as is being returned for the operation that failed.
CB_COMPOUND結果に含まれる「状態」欄です。このステータスはCB_COMPOUND手順の中で実行された最後の操作の状態と同等でなければなりません。操作がエラーを発生した場合、したがって、次に「ステータス」値は、失敗した操作のために返される同じエラー値となります。
IMPLEMENTATION
実装
The CB_COMPOUND procedure is used to combine individual operations into a single RPC request. The client interprets each of the operations in turn. If an operation is executed by the client and the status of that operation is NFS4_OK, then the next operation in the CB_COMPOUND procedure is executed. The client continues this process until there are no more operations to be executed or one of the operations has a status value other than NFS4_OK.
CB_COMPOUND手順は、単一のRPC要求に個々の操作を組み合わせるために使用されます。クライアントは、順番にそれぞれの操作を解釈します。操作は、クライアントで実行されると、その操作のステータスがNFS4_OKでされている場合は、CB_COMPOUNDの手順の次の動作が実行されます。が実行されるべきそれ以上の操作がされないかのいずれかの操作がNFS4_OK以外の状態値を有するまで、クライアントは、このプロセスを継続します。
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_RESOURCE
NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_RESOURCE
SYNOPSIS
SYNOPSIS
fh, attrbits -> attrbits, attrvals
FH、attrbits - > attrbits、attrvals
ARGUMENT
引数
struct CB_GETATTR4args {
nfs_fh4 fh;
bitmap4 attr_request;
};
RESULT
結果
struct CB_GETATTR4resok {
fattr4 obj_attributes;
};
union CB_GETATTR4res switch (nfsstat4 status) {
case NFS4_OK:
CB_GETATTR4resok resok4;
default:
void;
};
DESCRIPTION
DESCRIPTION
The CB_GETATTR operation is used to obtain the attributes modified by an open delegate to allow the server to respond to GETATTR requests for a file which is the subject of an open delegation.
CB_GETATTR操作は、サーバーがオープン委譲の対象であるファイルのGETATTR要求に応答できるようにするために、オープンデリゲートによって変更された属性を取得するために使用されます。
If the handle specified is not one for which the client holds a write open delegation, an NFS4ERR_BADHANDLE error is returned.
指定されたハンドルは、クライアントが書き込みオープン委譲を保持するためのものではない場合は、NFS4ERR_BADHANDLEエラーが返されます。
IMPLEMENTATION
実装
The client returns attrbits and the associated attribute values only for attributes that it may change (change, time_modify, object_size).
クライアントは、それが変更される可能性があり、属性（変更、time_modify、オブジェクト_）用attrbitsと関連付けられた属性値を返します。
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_RESOURCE
NFS4ERR_BADHANDLE NFS4ERR_RESOURCE
SYNOPSIS
SYNOPSIS
stateid, truncate, fh -> status
stateid、切り捨て、FH - >ステータス
ARGUMENT
引数
struct CB_RECALL4args {
stateid4 stateid;
bool truncate;
nfs_fh4 fh;
};
RESULT
結果
struct CB_RECALL4res {
nfsstat4 status;
};
DESCRIPTION
DESCRIPTION
The CB_RECALL operation is used to begin the process of recalling an open delegation and returning it to the server.
CB_RECALL操作が開いている委譲を想起し、それをサーバーに戻す処理を開始するために使用されています。
The truncate flag is used to optimize recall for a file which is about to be truncated to zero. When it is set, the client is freed of obligation to propagate modified data for the file to the server, since this data is irrelevant.
TRUNCATEフラグはゼロに切り捨てされようとしているファイルのリコールを最適化するために使用されます。それが設定されている場合、クライアントは、このデータは無関係であるため、サーバーへのファイルのために変更されたデータを伝播する義務が除去されます。
If the handle specified is not one for which the client holds an open delegation, an NFS4ERR_BADHANDLE error is returned.
指定されたハンドルは、クライアントが開いている委譲を保持するためのものではない場合は、NFS4ERR_BADHANDLEエラーが返されます。
If the stateid specified is not one corresponding to an open delegation for the file specified by the filehandle, an NFS4ERR_BAD_STATEID is returned.
指定されたstateidは、ファイルハンドルで指定されたファイルのオープン委譲に対応していないものである場合、NFS4ERR_BAD_STATEIDが返されます。
IMPLEMENTATION
実装
The client should reply to the callback immediately. Replying does not complete the recall. The recall is not complete until the delegation is returned using a DELEGRETURN.
クライアントはすぐにコールバックに返信する必要があります。返信するには、リコールを完了していません。代表団はDELEGRETURNを使用して返されるまで、リコールは完全ではありません。
ERRORS
エラー
NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_RESOURCE
NFS4ERR_BADHANDLE NFS4ERR_BAD_STATEID NFS4ERR_RESOURCE
The major security feature to consider is the authentication of the user making the request of NFS service. Consideration should also be given to the integrity and privacy of this NFS request. These specific issues are discussed as part of the section on "RPC and Security Flavor".
考慮すべき主要なセキュリティ機能では、NFSサービスの要求を行ったユーザの認証です。検討もこのNFS要求の整合性とプライバシーに与えられるべきです。これらの特定の問題は、「RPCとセキュリティの味」のセクションの一部として議論されています。
The NFS version 4 protocol provides for the association of named attributes to files. The name space identifiers for these attributes are defined as string names. The protocol does not define the specific assignment of the name space for these file attributes; the application developer or system vendor is allowed to define the attribute, its semantics, and the associated name. Even though this name space will not be specifically controlled to prevent collisions, the application developer or system vendor is strongly encouraged to provide the name assignment and associated semantics for attributes via an Informational RFC. This will provide for interoperability where common interests exist.
NFSバージョン4プロトコルは、ファイルに指定された属性との関連付けのために用意されています。これらの属性の名前空間識別子は、文字列名として定義されています。プロトコルは、これらのファイルの属性の名前空間の特定の割り当てを定義していません。アプリケーション開発者やシステムベンダーは、属性、その意味論、および関連する名前を定義することが許可されています。この名前空間は、具体的衝突を防ぐために制御されることはありませんにもかかわらず、アプリケーション開発者やシステムベンダーが強く情報RFC経由での属性の名前の割り当てと関連セマンティクスを提供することが奨励されます。これは共通の利益が存在し、相互運用性のために提供されます。
/*
* Copyright (C) The Internet Society (1998,1999,2000).
* All Rights Reserved.
*/
/*
* nfs4_prot.x
*
*/
%#pragma ident "@(#)nfs4_prot.x 1.97 00/06/12"
％の＃プラグマのident "@（＃）nfs4_prot.x 1.97 00/06/12"
/*
* Basic typedefs for RFC 1832 data type definitions
*/
typedef int int32_t;
typedef unsigned int uint32_t;
typedef hyper int64_t;
typedef unsigned hyper uint64_t;
/*
* Sizes
*/
const NFS4_FHSIZE = 128;
const NFS4_VERIFIER_SIZE = 8;
/*
* File types
*/
enum nfs_ftype4 {
NF4REG = 1, /* Regular File */
NF4DIR = 2, /* Directory */
NF4BLK = 3, /* Special File - block device */
NF4CHR = 4, /* Special File - character device */
NF4LNK = 5, /* Symbolic Link */
NF4SOCK = 6, /* Special File - socket */
NF4FIFO = 7, /* Special File - fifo */
NF4ATTRDIR = 8, /* Attribute Directory */
NF4NAMEDATTR = 9 /* Named Attribute */
};
/*
* Error status
*/
enum nfsstat4 {
NFS4_OK = 0,
NFS4ERR_PERM = 1,
NFS4ERR_NOENT = 2,
NFS4ERR_IO = 5,
NFS4ERR_NXIO = 6,
NFS4ERR_ACCES = 13,
NFS4ERR_EXIST = 17,
NFS4ERR_XDEV = 18,
NFS4ERR_NODEV = 19,
NFS4ERR_NOTDIR = 20,
NFS4ERR_ISDIR = 21,
NFS4ERR_INVAL = 22,
NFS4ERR_FBIG = 27,
NFS4ERR_NOSPC = 28,
NFS4ERR_ROFS = 30,
NFS4ERR_MLINK = 31,
NFS4ERR_NAMETOOLONG = 63,
NFS4ERR_NOTEMPTY = 66,
NFS4ERR_DQUOT = 69,
NFS4ERR_STALE = 70,
NFS4ERR_BADHANDLE = 10001,
NFS4ERR_BAD_COOKIE = 10003,
NFS4ERR_NOTSUPP = 10004,
NFS4ERR_TOOSMALL = 10005,
NFS4ERR_SERVERFAULT = 10006,
NFS4ERR_BADTYPE = 10007,
NFS4ERR_DELAY = 10008,
NFS4ERR_SAME = 10009,/* nverify says attrs same */
NFS4ERR_DENIED = 10010,/* lock unavailable */
NFS4ERR_EXPIRED = 10011,/* lock lease expired */
NFS4ERR_LOCKED = 10012,/* I/O failed due to lock */
NFS4ERR_GRACE = 10013,/* in grace period */
NFS4ERR_FHEXPIRED = 10014,/* file handle expired */
NFS4ERR_SHARE_DENIED = 10015,/* share reserve denied */
NFS4ERR_WRONGSEC = 10016,/* wrong security flavor */
NFS4ERR_CLID_INUSE = 10017,/* clientid in use */
NFS4ERR_RESOURCE = 10018,/* resource exhaustion */
NFS4ERR_MOVED = 10019,/* filesystem relocated */
NFS4ERR_NOFILEHANDLE = 10020,/* current FH is not set */
NFS4ERR_MINOR_VERS_MISMATCH = 10021,/* minor vers not supp */
NFS4ERR_STALE_CLIENTID = 10022,
NFS4ERR_STALE_STATEID = 10023,
NFS4ERR_OLD_STATEID = 10024,
NFS4ERR_BAD_STATEID = 10025,
NFS4ERR_BAD_SEQID = 10026,
NFS4ERR_NOT_SAME = 10027,/* verify - attrs not same */
NFS4ERR_LOCK_RANGE = 10028,
NFS4ERR_SYMLINK = 10029,
NFS4ERR_READDIR_NOSPC = 10030,
NFS4ERR_LEASE_MOVED = 10031 };
NFS4ERR_LEASE_MOVED = 10031}。
/*
* Basic data types
*/
typedef uint32_t bitmap4<>;
typedef uint64_t offset4;
typedef uint32_t count4;
typedef uint64_t length4;
typedef uint64_t clientid4;
typedef uint64_t stateid4;
typedef uint32_t seqid4;
typedef opaque utf8string<>;
typedef utf8string component4;
typedef component4 pathname4<>;
typedef uint64_t nfs_lockid4;
typedef uint64_t nfs_cookie4;
typedef utf8string linktext4;
typedef opaque sec_oid4<>;
typedef uint32_t qop4;
typedef uint32_t mode4;
typedef uint64_t changeid4;
typedef opaque verifier4[NFS4_VERIFIER_SIZE];
/*
* Timeval
*/
struct nfstime4 {
int64_t seconds;
uint32_t nseconds;
};
enum time_how4 { SET_TO_SERVER_TIME4 = 0, SET_TO_CLIENT_TIME4 = 1 };
列挙time_how4 {SET_TO_SERVER_TIME4 = 0、SET_TO_CLIENT_TIME4 = 1}。
union settime4 switch (time_how4 set_it) {
case SET_TO_CLIENT_TIME4:
nfstime4 time;
default:
void;
};
/*
* File access handle
*/
typedef opaque nfs_fh4<NFS4_FHSIZE>;
不透明nfs_fh4のtypedef <NFS4_FHSIZE>。
/*
* File attribute definitions
*/
/*
* FSID structure for major/minor
*/
struct fsid4 {
uint64_t major;
uint64_t minor;
};
/*
* Filesystem locations attribute for relocation/migration
*/
struct fs_location4 {
utf8string server<>;
pathname4 rootpath;
};
struct fs_locations4 {
pathname4 fs_root;
fs_location4 locations<>;
};
/*
* Various Access Control Entry definitions
*/
/*
* Mask that indicates which Access Control Entries are supported.
* Values for the fattr4_aclsupport attribute.
*/
const ACL4_SUPPORT_ALLOW_ACL = 0x00000001;
const ACL4_SUPPORT_DENY_ACL = 0x00000002;
const ACL4_SUPPORT_AUDIT_ACL = 0x00000004;
const ACL4_SUPPORT_ALARM_ACL = 0x00000008;
typedef uint32_t acetype4;
typedefでのuint32_t acetype4。
/*
* acetype4 values, others can be added as needed.
*/
const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001;
const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002;
const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003;
/*
* ACE flag
*/
typedef uint32_t aceflag4;
/*
* ACE flag values
*/
const ACE4_FILE_INHERIT_ACE = 0x00000001;
const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002;
const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004;
const ACE4_INHERIT_ONLY_ACE = 0x00000008;
const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010;
const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020;
const ACE4_IDENTIFIER_GROUP = 0x00000040;
/*
* ACE mask
*/
typedef uint32_t acemask4;
/*
* ACE mask values
*/
const ACE4_READ_DATA = 0x00000001;
const ACE4_LIST_DIRECTORY = 0x00000001;
const ACE4_WRITE_DATA = 0x00000002;
const ACE4_ADD_FILE = 0x00000002;
const ACE4_APPEND_DATA = 0x00000004;
const ACE4_ADD_SUBDIRECTORY = 0x00000004;
const ACE4_READ_NAMED_ATTRS = 0x00000008;
const ACE4_WRITE_NAMED_ATTRS = 0x00000010;
const ACE4_EXECUTE = 0x00000020;
const ACE4_DELETE_CHILD = 0x00000040;
const ACE4_READ_ATTRIBUTES = 0x00000080;
const ACE4_WRITE_ATTRIBUTES = 0x00000100;
const ACE4_DELETE = 0x00010000;
const ACE4_READ_ACL = 0x00020000;
const ACE4_WRITE_ACL = 0x00040000;
const ACE4_WRITE_OWNER = 0x00080000;
const ACE4_SYNCHRONIZE = 0x00100000;
/*
* ACE4_GENERIC_READ -- defined as combination of
* ACE4_READ_ACL |
* ACE4_READ_DATA |
* ACE4_READ_ATTRIBUTES |
* ACE4_SYNCHRONIZE
*/
const ACE4_GENERIC_READ = 0x00120081;
constのACE4_GENERIC_READ = 0x00120081;
/*
* ACE4_GENERIC_WRITE -- defined as combination of
* ACE4_READ_ACL |
* ACE4_WRITE_DATA |
* ACE4_WRITE_ATTRIBUTES |
* ACE4_WRITE_ACL |
* ACE4_APPEND_DATA |
* ACE4_SYNCHRONIZE
*/
const ACE4_GENERIC_WRITE = 0x00160106;
constのACE4_GENERIC_WRITE = 0x00160106;
/*
* ACE4_GENERIC_EXECUTE -- defined as combination of
* ACE4_READ_ACL
* ACE4_READ_ATTRIBUTES
* ACE4_EXECUTE
* ACE4_SYNCHRONIZE
*/
const ACE4_GENERIC_EXECUTE = 0x001200A0;
/*
* Access Control Entry definition
*/
struct nfsace4 {
acetype4 type;
aceflag4 flag;
acemask4 access_mask;
utf8string who;
};
/*
* Special data/attribute associated with
* file types NF4BLK and NF4CHR.
*/
struct specdata4 {
uint32_t specdata1;
uint32_t specdata2;
};
/*
* Values for fattr4_fh_expire_type
*/
const FH4_PERSISTENT = 0x00000000;
const FH4_NOEXPIRE_WITH_OPEN = 0x00000001;
const FH4_VOLATILE_ANY = 0x00000002;
const FH4_VOL_MIGRATION = 0x00000004;
const FH4_VOL_RENAME = 0x00000008;
typedef bitmap4 fattr4_supported_attrs;
typedef nfs_ftype4 fattr4_type;
typedef uint32_t fattr4_fh_expire_type;
typedef changeid4 fattr4_change;
typedef uint64_t fattr4_size;
typedef bool fattr4_link_support;
typedef bool fattr4_symlink_support;
typedef bool fattr4_named_attr;
typedef fsid4 fattr4_fsid;
typedef bool fattr4_unique_handles;
typedef uint32_t fattr4_lease_time;
typedef nfsstat4 fattr4_rdattr_error;
typedef nfsace4 fattr4_acl<>;
typedef uint32_t fattr4_aclsupport;
typedef bool fattr4_archive;
typedef bool fattr4_cansettime;
typedef bool fattr4_case_insensitive;
typedef bool fattr4_case_preserving;
typedef bool fattr4_chown_restricted;
typedef uint64_t fattr4_fileid;
typedef uint64_t fattr4_files_avail;
typedef nfs_fh4 fattr4_filehandle;
typedef uint64_t fattr4_files_free;
typedef uint64_t fattr4_files_total;
typedef fs_locations4 fattr4_fs_locations;
typedef bool fattr4_hidden;
typedef bool fattr4_homogeneous;
typedef uint64_t fattr4_maxfilesize;
typedef uint32_t fattr4_maxlink;
typedef uint32_t fattr4_maxname;
typedef uint64_t fattr4_maxread;
typedef uint64_t fattr4_maxwrite;
typedef utf8string fattr4_mimetype; typedef mode4 fattr4_mode;
typedef bool fattr4_no_trunc;
typedef uint32_t fattr4_numlinks;
typedef utf8string fattr4_owner;
typedef utf8string fattr4_owner_group;
typedef uint64_t fattr4_quota_avail_hard;
typedef uint64_t fattr4_quota_avail_soft;
typedef uint64_t fattr4_quota_used;
typedef specdata4 fattr4_rawdev;
typedef uint64_t fattr4_space_avail;
typedef uint64_t fattr4_space_free;
typedef uint64_t fattr4_space_total;
typedef uint64_t fattr4_space_used;
typedef bool fattr4_system;
typedef nfstime4 fattr4_time_access;
typedef settime4 fattr4_time_access_set;
typedef nfstime4 fattr4_time_backup;
typedef nfstime4 fattr4_time_create;
typedef nfstime4 fattr4_time_delta;
typedef nfstime4 fattr4_time_metadata;
typedef nfstime4 fattr4_time_modify;
typedef settime4 fattr4_time_modify_set;
/*
* Mandatory Attributes
*/
const FATTR4_SUPPORTED_ATTRS = 0;
const FATTR4_TYPE = 1;
const FATTR4_FH_EXPIRE_TYPE = 2;
const FATTR4_CHANGE = 3;
const FATTR4_SIZE = 4;
const FATTR4_LINK_SUPPORT = 5;
const FATTR4_SYMLINK_SUPPORT = 6;
const FATTR4_NAMED_ATTR = 7;
const FATTR4_FSID = 8;
const FATTR4_UNIQUE_HANDLES = 9;
const FATTR4_LEASE_TIME = 10;
const FATTR4_RDATTR_ERROR = 11;
/*
* Recommended Attributes
*/
const FATTR4_ACL = 12;
const FATTR4_ACLSUPPORT = 13;
const FATTR4_ARCHIVE = 14;
const FATTR4_CANSETTIME = 15;
const FATTR4_CASE_INSENSITIVE = 16; const FATTR4_CASE_PRESERVING = 17;
const FATTR4_CHOWN_RESTRICTED = 18;
const FATTR4_FILEHANDLE = 19;
const FATTR4_FILEID = 20;
const FATTR4_FILES_AVAIL = 21;
const FATTR4_FILES_FREE = 22;
const FATTR4_FILES_TOTAL = 23;
const FATTR4_FS_LOCATIONS = 24;
const FATTR4_HIDDEN = 25;
const FATTR4_HOMOGENEOUS = 26;
const FATTR4_MAXFILESIZE = 27;
const FATTR4_MAXLINK = 28;
const FATTR4_MAXNAME = 29;
const FATTR4_MAXREAD = 30;
const FATTR4_MAXWRITE = 31;
const FATTR4_MIMETYPE = 32;
const FATTR4_MODE = 33;
const FATTR4_NO_TRUNC = 34;
const FATTR4_NUMLINKS = 35;
const FATTR4_OWNER = 36;
const FATTR4_OWNER_GROUP = 37;
const FATTR4_QUOTA_AVAIL_HARD = 38;
const FATTR4_QUOTA_AVAIL_SOFT = 39;
const FATTR4_QUOTA_USED = 40;
const FATTR4_RAWDEV = 41;
const FATTR4_SPACE_AVAIL = 42;
const FATTR4_SPACE_FREE = 43;
const FATTR4_SPACE_TOTAL = 44;
const FATTR4_SPACE_USED = 45;
const FATTR4_SYSTEM = 46;
const FATTR4_TIME_ACCESS = 47;
const FATTR4_TIME_ACCESS_SET = 48;
const FATTR4_TIME_BACKUP = 49;
const FATTR4_TIME_CREATE = 50;
const FATTR4_TIME_DELTA = 51;
const FATTR4_TIME_METADATA = 52;
const FATTR4_TIME_MODIFY = 53;
const FATTR4_TIME_MODIFY_SET = 54;
typedef opaque attrlist4<>;
不透明attrlist4のtypedef <>。
/*
* File attribute container
*/
struct fattr4 {
bitmap4 attrmask;
attrlist4 attr_vals;
};
｝；
/*
* Change info for the client
*/
struct change_info4 {
bool atomic;
changeid4 before;
changeid4 after;
};
struct clientaddr4 {
/* see struct rpcb in RFC 1833 */
string r_netid<>; /* network id */
string r_addr<>; /* universal address */
};
/*
* Callback program info as provided by the client
*/
struct cb_client4 {
unsigned int cb_program;
clientaddr4 cb_location;
};
/*
* Client ID
*/
struct nfs_client_id4 {
verifier4 verifier;
opaque id<>;
};
struct nfs_lockowner4 {
clientid4 clientid;
opaque owner<>;
};
enum nfs_lock_type4 {
READ_LT = 1,
WRITE_LT = 2,
READW_LT = 3, /* blocking read */
WRITEW_LT = 4 /* blocking write */
};
/*
* ACCESS: Check access permission
*/
const ACCESS4_READ = 0x00000001;
const ACCESS4_LOOKUP = 0x00000002;
const ACCESS4_MODIFY = 0x00000004;
const ACCESS4_EXTEND = 0x00000008;
const ACCESS4_DELETE = 0x00000010;
const ACCESS4_EXECUTE = 0x00000020;
struct ACCESS4args {
/* CURRENT_FH: object */
uint32_t access;
};
struct ACCESS4resok {
uint32_t supported;
uint32_t access;
};
union ACCESS4res switch (nfsstat4 status) {
case NFS4_OK:
ACCESS4resok resok4;
default:
void;
};
/*
* CLOSE: Close a file and release share locks
*/
struct CLOSE4args {
/* CURRENT_FH: object */
seqid4 seqid;
stateid4 stateid;
};
union CLOSE4res switch (nfsstat4 status) {
case NFS4_OK:
stateid4 stateid;
default:
void;
};
/*
* COMMIT: Commit cached data on server to stable storage
*/
struct COMMIT4args {
/* CURRENT_FH: file */
offset4 offset;
count4 count;
}; struct COMMIT4resok {
verifier4 writeverf;
};
union COMMIT4res switch (nfsstat4 status) {
case NFS4_OK:
COMMIT4resok resok4;
default:
void;
};
/*
* CREATE: Create a file
*/
union createtype4 switch (nfs_ftype4 type) {
case NF4LNK:
linktext4 linkdata;
case NF4BLK:
case NF4CHR:
specdata4 devdata;
case NF4SOCK:
case NF4FIFO:
case NF4DIR:
void;
};
struct CREATE4args {
/* CURRENT_FH: directory for creation */
component4 objname;
createtype4 objtype;
};
struct CREATE4resok {
change_info4 cinfo;
};
union CREATE4res switch (nfsstat4 status) {
case NFS4_OK:
CREATE4resok resok4;
default:
void;
};
/*
* DELEGPURGE: Purge Delegations Awaiting Recovery
*/
struct DELEGPURGE4args {
clientid4 clientid;
};
struct DELEGPURGE4res {
nfsstat4 status;
};
/*
* DELEGRETURN: Return a delegation
*/
struct DELEGRETURN4args {
stateid4 stateid;
};
struct DELEGRETURN4res {
nfsstat4 status;
};
/*
* GETATTR: Get file attributes
*/
struct GETATTR4args {
/* CURRENT_FH: directory or file */
bitmap4 attr_request;
};
struct GETATTR4resok {
fattr4 obj_attributes;
};
union GETATTR4res switch (nfsstat4 status) {
case NFS4_OK:
GETATTR4resok resok4;
default:
void;
};
/*
* GETFH: Get current filehandle
*/
struct GETFH4resok {
nfs_fh4 object;
};
union GETFH4res switch (nfsstat4 status) { case NFS4_OK: GETFH4resok resok4; default:
GETFH4resokのresok4;組合GETFH4resは（nfsstat4ステータス）{ケースNFS4_OKスイッチデフォルト：
void;
};
/*
* LINK: Create link to an object
*/
struct LINK4args {
/* SAVED_FH: source object */
/* CURRENT_FH: target directory */
component4 newname;
};
struct LINK4resok {
change_info4 cinfo;
};
union LINK4res switch (nfsstat4 status) {
case NFS4_OK:
LINK4resok resok4;
default:
void;
};
/*
* LOCK/LOCKT/LOCKU: Record lock management
*/
struct LOCK4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
seqid4 seqid;
bool reclaim;
stateid4 stateid;
offset4 offset;
length4 length;
};
struct LOCK4denied {
nfs_lockowner4 owner;
offset4 offset;
length4 length;
};
union LOCK4res switch (nfsstat4 status) {
case NFS4_OK:
stateid4 stateid;
case NFS4ERR_DENIED:
LOCK4denied denied;
default:
void;
};
struct LOCKT4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
nfs_lockowner4 owner;
offset4 offset;
length4 length;
};
union LOCKT4res switch (nfsstat4 status) {
case NFS4ERR_DENIED:
LOCK4denied denied;
case NFS4_OK:
void;
default:
void;
};
struct LOCKU4args {
/* CURRENT_FH: file */
nfs_lock_type4 locktype;
seqid4 seqid;
stateid4 stateid;
offset4 offset;
length4 length;
};
union LOCKU4res switch (nfsstat4 status) {
case NFS4_OK:
stateid4 stateid;
default:
void;
};
/*
* LOOKUP: Lookup filename
*/
struct LOOKUP4args {
/* CURRENT_FH: directory */
pathname4 path;
};
struct LOOKUP4res {
/* CURRENT_FH: object */
nfsstat4 status;
};
/*
* LOOKUPP: Lookup parent directory
*/
struct LOOKUPP4res {
/* CURRENT_FH: directory */
nfsstat4 status;
};
/*
* NVERIFY: Verify attributes different
*/
struct NVERIFY4args {
/* CURRENT_FH: object */
fattr4 obj_attributes;
};
struct NVERIFY4res {
nfsstat4 status;
};
/*
* Various definitions for OPEN
*/
enum createmode4 {
UNCHECKED4 = 0,
GUARDED4 = 1,
EXCLUSIVE4 = 2
};
union createhow4 switch (createmode4 mode) {
case UNCHECKED4:
case GUARDED4:
fattr4 createattrs;
case EXCLUSIVE4:
verifier4 createverf;
};
enum opentype4 { OPEN4_NOCREATE = 0, OPEN4_CREATE = 1 };
列挙opentype4 {OPEN4_NOCREATE = 0、OPEN4_CREATE = 1}。
union openflag4 switch (opentype4 opentype) {
case OPEN4_CREATE:
createhow4 how;
default:
void;
};
/* Next definitions used for OPEN delegation */
enum limit_by4 {
NFS_LIMIT_SIZE = 1,
NFS_LIMIT_BLOCKS = 2
/* others as needed */
};
struct nfs_modified_limit4 {
uint32_t num_blocks;
uint32_t bytes_per_block;
};
union nfs_space_limit4 switch (limit_by4 limitby) {
/* limit specified as file size */
case NFS_LIMIT_SIZE:
uint64_t filesize;
/* limit specified by number of blocks */
case NFS_LIMIT_BLOCKS:
nfs_modified_limit4 mod_blocks;
} ;
/*
* Share Access and Deny constants for open argument
*/
const OPEN4_SHARE_ACCESS_READ = 0x00000001;
const OPEN4_SHARE_ACCESS_WRITE = 0x00000002;
const OPEN4_SHARE_ACCESS_BOTH = 0x00000003;
const OPEN4_SHARE_DENY_NONE = 0x00000000;
const OPEN4_SHARE_DENY_READ = 0x00000001;
const OPEN4_SHARE_DENY_WRITE = 0x00000002;
const OPEN4_SHARE_DENY_BOTH = 0x00000003;
enum open_delegation_type4 { OPEN_DELEGATE_NONE = 0, OPEN_DELEGATE_READ = 1, OPEN_DELEGATE_WRITE = 2 };
列挙open_delegation_type4 {OPEN_DELEGATE_NONE = 0、OPEN_DELEGATE_READ = 1、OPEN_DELEGATE_WRITE = 2}。
enum open_claim_type4 { CLAIM_NULL = 0, CLAIM_PREVIOUS = 1, CLAIM_DELEGATE_CUR = 2, CLAIM_DELEGATE_PREV = 3 };
列挙open_claim_type4 {CLAIM_NULL = 0、CLAIM_PREVIOUS = 1、CLAIM_DELEGATE_CUR = 2、CLAIM_DELEGATE_PREV = 3}。
struct open_claim_delegate_cur4 {
pathname4 file; stateid4 delegate_stateid;
};
union open_claim4 switch (open_claim_type4 claim) {
/*
* No special rights to file. Ordinary OPEN of the specified file.
*/
case CLAIM_NULL:
/* CURRENT_FH: directory */
pathname4 file;
/*
* Right to the file established by an open previous to server
* reboot. File identified by filehandle obtained at that time
* rather than by name.
*/
case CLAIM_PREVIOUS:
/* CURRENT_FH: file being reclaimed */
uint32_t delegate_type;
/*
* Right to file based on a delegation granted by the server.
* File is specified by name.
*/
case CLAIM_DELEGATE_CUR:
/* CURRENT_FH: directory */
open_claim_delegate_cur4 delegate_cur_info;
/* Right to file based on a delegation granted to a previous boot
* instance of the client. File is specified by name.
*/
case CLAIM_DELEGATE_PREV:
/* CURRENT_FH: directory */
pathname4 file_delegate_prev;
};
/*
* OPEN: Open a file, potentially receiving an open delegation
*/
struct OPEN4args {
open_claim4 claim;
openflag4 openhow;
nfs_lockowner4 owner;
seqid4 seqid;
uint32_t share_access;
uint32_t share_deny;
}; struct open_read_delegation4 {
stateid4 stateid; /* Stateid for delegation*/
bool recall; /* Pre-recalled flag for
delegations obtained
by reclaim
(CLAIM_PREVIOUS) */
nfsace4 permissions; /* Defines users who don't
need an ACCESS call to
open for read */
};
struct open_write_delegation4 {
stateid4 stateid; /* Stateid for delegation */
bool recall; /* Pre-recalled flag for
delegations obtained
by reclaim
(CLAIM_PREVIOUS) */
nfs_space_limit4 space_limit; /* Defines condition that
the client must check to
determine whether the
file needs to be flushed
to the server on close.
*/
nfsace4 permissions; /* Defines users who don't
need an ACCESS call as
part of a delegated
open. */
};
union open_delegation4
switch (open_delegation_type4 delegation_type) {
case OPEN_DELEGATE_NONE:
void;
case OPEN_DELEGATE_READ:
open_read_delegation4 read;
case OPEN_DELEGATE_WRITE:
open_write_delegation4 write;
};
/*
* Result flags
*/
/* Mandatory locking is in effect for this file. */
const OPEN4_RESULT_MLOCK = 0x00000001;
/* Client must confirm open */
const OPEN4_RESULT_CONFIRM = 0x00000002;
struct OPEN4resok {
構造体OPEN4resok {
stateid4 stateid; /* Stateid for open */
change_info4 cinfo; /* Directory Change Info */
uint32_t rflags; /* Result flags */
verifier4 open_confirm; /* OPEN_CONFIRM verifier */
open_delegation4 delegation; /* Info on any open
delegation */
};
union OPEN4res switch (nfsstat4 status) {
case NFS4_OK:
/* CURRENT_FH: opened file */
OPEN4resok resok4;
default:
void;
};
/*
* OPENATTR: open named attributes directory
*/
struct OPENATTR4res {
/* CURRENT_FH: name attr directory*/
nfsstat4 status;
};
/*
* OPEN_CONFIRM: confirm the open
*/
struct OPEN_CONFIRM4args {
/* CURRENT_FH: opened file */
seqid4 seqid;
verifier4 open_confirm; /* OPEN_CONFIRM verifier */
};
struct OPEN_CONFIRM4resok {
stateid4 stateid;
};
union OPEN_CONFIRM4res switch (nfsstat4 status) {
case NFS4_OK:
OPEN_CONFIRM4resok resok4;
default:
void;
};
/*
* OPEN_DOWNGRADE: downgrade the access/deny for a file
*/
struct OPEN_DOWNGRADE4args {
/* CURRENT_FH: opened file */
stateid4 stateid;
seqid4 seqid;
uint32_t share_access;
uint32_t share_deny;
};
struct OPEN_DOWNGRADE4resok {
stateid4 stateid;
};
union OPEN_DOWNGRADE4res switch(nfsstat4 status) {
case NFS4_OK:
OPEN_DOWNGRADE4resok resok4;
default:
void;
};
/*
* PUTFH: Set current filehandle
*/
struct PUTFH4args {
nfs_fh4 object;
};
struct PUTFH4res {
/* CURRENT_FH: */
nfsstat4 status;
};
/*
* PUTPUBFH: Set public filehandle
*/
struct PUTPUBFH4res {
/* CURRENT_FH: public fh */
nfsstat4 status;
};
/*
* PUTROOTFH: Set root filehandle
*/
struct PUTROOTFH4res {
/* CURRENT_FH: root fh */
nfsstat4 status;
};
/*
* READ: Read from file
*/
struct READ4args {
/* CURRENT_FH: file */
stateid4 stateid;
offset4 offset;
count4 count;
};
struct READ4resok {
bool eof;
opaque data<>;
};
union READ4res switch (nfsstat4 status) {
case NFS4_OK:
READ4resok resok4;
default:
void;
};
/*
* READDIR: Read directory
*/
struct READDIR4args {
/* CURRENT_FH: directory */
nfs_cookie4 cookie;
verifier4 cookieverf;
count4 dircount;
count4 maxcount;
bitmap4 attr_request;
};
struct entry4 {
nfs_cookie4 cookie;
component4 name;
fattr4 attrs;
entry4 *nextentry;
};
struct dirlist4 {
entry4 *entries;
bool eof;
};
struct READDIR4resok {
verifier4 cookieverf;
dirlist4 reply;
}; union READDIR4res switch (nfsstat4 status) {
case NFS4_OK:
READDIR4resok resok4;
default:
void;
};
/*
* READLINK: Read symbolic link
*/
struct READLINK4resok {
linktext4 link;
};
union READLINK4res switch (nfsstat4 status) {
case NFS4_OK:
READLINK4resok resok4;
default:
void;
};
/*
* REMOVE: Remove filesystem object
*/
struct REMOVE4args {
/* CURRENT_FH: directory */
component4 target;
};
struct REMOVE4resok {
change_info4 cinfo;
};
union REMOVE4res switch (nfsstat4 status) {
case NFS4_OK:
REMOVE4resok resok4;
default:
void;
};
/*
* RENAME: Rename directory entry
*/
struct RENAME4args {
/* SAVED_FH: source directory */
component4 oldname;
/* CURRENT_FH: target directory */ component4 newname;
};
struct RENAME4resok {
change_info4 source_cinfo;
change_info4 target_cinfo;
};
union RENAME4res switch (nfsstat4 status) {
case NFS4_OK:
RENAME4resok resok4;
default:
void;
};
/*
* RENEW: Renew a Lease
*/
struct RENEW4args {
stateid4 stateid;
};
struct RENEW4res {
nfsstat4 status;
};
/*
* RESTOREFH: Restore saved filehandle
*/
struct RESTOREFH4res {
/* CURRENT_FH: value of saved fh */
nfsstat4 status;
};
/*
* SAVEFH: Save current filehandle
*/
struct SAVEFH4res {
/* SAVED_FH: value of current fh */
nfsstat4 status;
};
/*
* SECINFO: Obtain Available Security Mechanisms
*/
struct SECINFO4args {
/* CURRENT_FH: */
component4 name;
};
/*
* From RFC 2203
*/
enum rpc_gss_svc_t {
RPC_GSS_SVC_NONE = 1,
RPC_GSS_SVC_INTEGRITY = 2,
RPC_GSS_SVC_PRIVACY = 3
};
struct rpcsec_gss_info {
sec_oid4 oid;
qop4 qop;
rpc_gss_svc_t service;
};
struct secinfo4 {
uint32_t flavor;
/* null for AUTH_SYS, AUTH_NONE;
contains rpcsec_gss_info for
RPCSEC_GSS. */
opaque flavor_info<>;
};
typedef secinfo4 SECINFO4resok<>;
typedefのsecinfo4 SECINFO4resok <>。
union SECINFO4res switch (nfsstat4 status) {
case NFS4_OK:
SECINFO4resok resok4;
default:
void;
};
/*
* SETATTR: Set attributes
*/
struct SETATTR4args {
/* CURRENT_FH: target object */
stateid4 stateid;
fattr4 obj_attributes;
};
｝；
struct SETATTR4res {
nfsstat4 status; bitmap4 attrsset;
};
/*
* SETCLIENTID
*/
struct SETCLIENTID4args {
nfs_client_id4 client;
cb_client4 callback;
};
struct SETCLIENTID4resok {
clientid4 clientid;
verifier4 setclientid_confirm;
};
union SETCLIENTID4res switch (nfsstat4 status) {
case NFS4_OK:
SETCLIENTID4resok resok4;
case NFS4ERR_CLID_INUSE:
clientaddr4 client_using;
default:
void;
};
struct SETCLIENTID_CONFIRM4args {
verifier4 setclientid_confirm;
};
struct SETCLIENTID_CONFIRM4res {
nfsstat4 status;
};
/*
* VERIFY: Verify attributes same
*/
struct VERIFY4args {
/* CURRENT_FH: object */
fattr4 obj_attributes;
};
struct VERIFY4res {
nfsstat4 status;
};
/*
* WRITE: Write to file
*/
enum stable_how4 { UNSTABLE4 = 0, DATA_SYNC4 = 1, FILE_SYNC4 = 2 };
列挙stable_how4 {UNSTABLE4 = 0、DATA_SYNC4 = 1、FILE_SYNC4 = 2}。
struct WRITE4args {
/* CURRENT_FH: file */
stateid4 stateid;
offset4 offset;
stable_how4 stable;
opaque data<>;
};
struct WRITE4resok {
count4 count;
stable_how4 committed;
verifier4 writeverf;
};
union WRITE4res switch (nfsstat4 status) {
case NFS4_OK:
WRITE4resok resok4;
default:
void;
};
/*
* Operation arrays
*/
enum nfs_opnum4 { OP_ACCESS = 3, OP_CLOSE = 4, OP_COMMIT = 5, OP_CREATE = 6, OP_DELEGPURGE = 7, OP_DELEGRETURN = 8, OP_GETATTR = 9, OP_GETFH = 10, OP_LINK = 11, OP_LOCK = 12, OP_LOCKT = 13, OP_LOCKU = 14, OP_LOOKUP = 15, OP_LOOKUPP = 16, OP_NVERIFY = 17, OP_OPEN = 18,
列挙nfs_opnum4 {OP_ACCESS = 3、OP_CLOSE = 4、OP_COMMIT = 5、OP_CREATE = 6、OP_DELEGPURGE = 7、OP_DELEGRETURN = 8、OP_GETATTR = 9、OP_GETFH = 10、OP_LINK = 11、OP_LOCK = 12、OP_LOCKT = 13、OP_LOCKU = 14 、OP_LOOKUP = 15、OP_LOOKUPP = 16、OP_NVERIFY = 17、OP_OPEN = 18、
OP_OPENATTR = 19, OP_OPEN_CONFIRM = 20, OP_OPEN_DOWNGRADE = 21, OP_PUTFH = 22, OP_PUTPUBFH = 23, OP_PUTROOTFH = 24, OP_READ = 25, OP_READDIR = 26, OP_READLINK = 27, OP_REMOVE = 28, OP_RENAME = 29, OP_RENEW = 30, OP_RESTOREFH = 31, OP_SAVEFH = 32, OP_SECINFO = 33, OP_SETATTR = 34, OP_SETCLIENTID = 35, OP_SETCLIENTID_CONFIRM = 36, OP_VERIFY = 37, OP_WRITE = 38 };
OP_OPENATTR = 19、OP_OPEN_CONFIRM = 20、OP_OPEN_DOWNGRADE = 21、OP_PUTFH = 22、OP_PUTPUBFH = 23、OP_PUTROOTFH = 24、OP_READ = 25、OP_READDIR = 26、OP_READLINK = 27、OP_REMOVE = 28、OP_RENAME = 29、OP_RENEW = 30、OP_RESTOREFH = 31、OP_SAVEFH = 32、OP_SECINFO = 33、OP_SETATTR = 34、OP_SETCLIENTID = 35、OP_SETCLIENTID_CONFIRM = 36、OP_VERIFY = 37、OP_WRITE = 38}。
union nfs_argop4 switch (nfs_opnum4 argop) {
case OP_ACCESS: ACCESS4args opaccess;
case OP_CLOSE: CLOSE4args opclose;
case OP_COMMIT: COMMIT4args opcommit;
case OP_CREATE: CREATE4args opcreate;
case OP_DELEGPURGE: DELEGPURGE4args opdelegpurge;
case OP_DELEGRETURN: DELEGRETURN4args opdelegreturn;
case OP_GETATTR: GETATTR4args opgetattr;
case OP_GETFH: void;
case OP_LINK: LINK4args oplink;
case OP_LOCK: LOCK4args oplock;
case OP_LOCKT: LOCKT4args oplockt;
case OP_LOCKU: LOCKU4args oplocku;
case OP_LOOKUP: LOOKUP4args oplookup;
case OP_LOOKUPP: void;
case OP_NVERIFY: NVERIFY4args opnverify;
case OP_OPEN: OPEN4args opopen;
case OP_OPENATTR: void;
case OP_OPEN_CONFIRM: OPEN_CONFIRM4args opopen_confirm;
case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4args opopen_downgrade;
case OP_PUTFH: PUTFH4args opputfh;
case OP_PUTPUBFH: void;
case OP_PUTROOTFH: void;
case OP_READ: READ4args opread;
case OP_READDIR: READDIR4args opreaddir;
case OP_READLINK: void; case OP_REMOVE: REMOVE4args opremove;
case OP_RENAME: RENAME4args oprename;
case OP_RENEW: RENEW4args oprenew;
case OP_RESTOREFH: void;
case OP_SAVEFH: void;
case OP_SECINFO: SECINFO4args opsecinfo;
case OP_SETATTR: SETATTR4args opsetattr;
case OP_SETCLIENTID: SETCLIENTID4args opsetclientid;
case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4args
opsetclientid_confirm;
case OP_VERIFY: VERIFY4args opverify;
case OP_WRITE: WRITE4args opwrite;
};
union nfs_resop4 switch (nfs_opnum4 resop){
case OP_ACCESS: ACCESS4res opaccess;
case OP_CLOSE: CLOSE4res opclose;
case OP_COMMIT: COMMIT4res opcommit;
case OP_CREATE: CREATE4res opcreate;
case OP_DELEGPURGE: DELEGPURGE4res opdelegpurge;
case OP_DELEGRETURN: DELEGRETURN4res opdelegreturn;
case OP_GETATTR: GETATTR4res opgetattr;
case OP_GETFH: GETFH4res opgetfh;
case OP_LINK: LINK4res oplink;
case OP_LOCK: LOCK4res oplock;
case OP_LOCKT: LOCKT4res oplockt;
case OP_LOCKU: LOCKU4res oplocku;
case OP_LOOKUP: LOOKUP4res oplookup;
case OP_LOOKUPP: LOOKUPP4res oplookupp;
case OP_NVERIFY: NVERIFY4res opnverify;
case OP_OPEN: OPEN4res opopen;
case OP_OPENATTR: OPENATTR4res opopenattr;
case OP_OPEN_CONFIRM: OPEN_CONFIRM4res opopen_confirm;
case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4res opopen_downgrade;
case OP_PUTFH: PUTFH4res opputfh;
case OP_PUTPUBFH: PUTPUBFH4res opputpubfh;
case OP_PUTROOTFH: PUTROOTFH4res opputrootfh;
case OP_READ: READ4res opread;
case OP_READDIR: READDIR4res opreaddir;
case OP_READLINK: READLINK4res opreadlink;
case OP_REMOVE: REMOVE4res opremove;
case OP_RENAME: RENAME4res oprename;
case OP_RENEW: RENEW4res oprenew;
case OP_RESTOREFH: RESTOREFH4res oprestorefh;
case OP_SAVEFH: SAVEFH4res opsavefh;
case OP_SECINFO: SECINFO4res opsecinfo;
case OP_SETATTR: SETATTR4res opsetattr;
case OP_SETCLIENTID: SETCLIENTID4res opsetclientid; case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4res
opsetclientid_confirm;
case OP_VERIFY: VERIFY4res opverify;
case OP_WRITE: WRITE4res opwrite;
};
struct COMPOUND4args {
utf8string tag;
uint32_t minorversion;
nfs_argop4 argarray<>;
};
struct COMPOUND4res {
nfsstat4 status;
utf8string tag;
nfs_resop4 resarray<>;
};
/*
* Remote file service routines
*/
program NFS4_PROGRAM {
version NFS_V4 {
void
NFSPROC4_NULL(void) = 0;
COMPOUND4res
NFSPROC4_COMPOUND(COMPOUND4args) = 1;
} = 4;
} = 100003;
/*
* NFS4 Callback Procedure Definitions and Program
*/
/*
* CB_GETATTR: Get Current Attributes
*/
struct CB_GETATTR4args {
nfs_fh4 fh;
bitmap4 attr_request;
};
struct CB_GETATTR4resok { fattr4 obj_attributes;
構造体CB_GETATTR4resok {fattr4 obj_属性。
};
｝；
union CB_GETATTR4res switch (nfsstat4 status) {
case NFS4_OK:
CB_GETATTR4resok resok4;
default:
void;
};
/*
* CB_RECALL: Recall an Open Delegation
*/
struct CB_RECALL4args {
stateid4 stateid;
bool truncate;
nfs_fh4 fh;
};
struct CB_RECALL4res {
nfsstat4 status;
};
/*
* Various definitions for CB_COMPOUND
*/
enum nfs_cb_opnum4 {
OP_CB_GETATTR = 3,
OP_CB_RECALL = 4
};
union nfs_cb_argop4 switch (unsigned argop) {
case OP_CB_GETATTR: CB_GETATTR4args opcbgetattr;
case OP_CB_RECALL: CB_RECALL4args opcbrecall;
};
union nfs_cb_resop4 switch (unsigned resop){
case OP_CB_GETATTR: CB_GETATTR4res opcbgetattr;
case OP_CB_RECALL: CB_RECALL4res opcbrecall;
};
struct CB_COMPOUND4args {
utf8string tag;
uint32_t minorversion;
nfs_cb_argop4 argarray<>;
};
struct CB_COMPOUND4res {
nfsstat4 status; utf8string tag;
nfs_cb_resop4 resarray<>;
};
/*
* Program number is in the transient range since the client
* will assign the exact transient program number and provide
* that to the server via the SETCLIENTID operation.
*/
program NFS4_CALLBACK {
version NFS_CB {
void
CB_NULL(void) = 0;
CB_COMPOUND4res
CB_COMPOUND(CB_COMPOUND4args) = 1;
} = 1;
} = 40000000;
[Floyd] S. Floyd, V. Jacobson, "The Synchronization of Periodic Routing Messages," IEEE/ACM Transactions on Networking, 2(2), pp. 122-136, April 1994.
[フロイド] S.フロイド、V. Jacobsonの "周期的ルーティングメッセージの同期、" ネットワーク上のIEEE / ACMトランザクション、2（2）、頁122から136まで、1994年4月。
[Gray] C. Gray, D. Cheriton, "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency," Proceedings of the Twelfth Symposium on Operating Systems Principles, p. 202-210, December 1989.
[グレー] C.グレー、D. Cheriton、「リース：分散ファイルキャッシュの一貫性のための効率的なフォールトトレラントメカニズム、」オペレーティングシステムの原理、P上の十二シンポジウム。 202〜210、1989年12月。
[ISO10646] "ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane."
[ISO10646]「ISO / IEC 10646-1：1993国際規格 - 情報技術 - ユニバーサルマルチオクテット符号化文字セット（UCS） - 第1部：アーキテクチャと基本多言語面」
[Juszczak] Juszczak, Chet, "Improving the Performance and Correctness of an NFS Server," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, June 1990, pages 53-63. Describes reply cache implementation that avoids work in the server by handling duplicate requests. More important, though listed as a side-effect, the reply cache aids in the avoidance of destructive non-idempotent operation re-application -- improving correctness.
[Juszczak] Juszczak、チェット、 "NFSサーバーのパフォーマンスと正確性を向上させる、" USENIX会議議事録、USENIX協会、バークレー、CA、1990年6月、ページ53-63。重複した要求を処理することにより、サーバでの作業を回避し、応答キャッシュの実装は説明しています。より重要な、副作用、破壊的非冪等の操作の再塗布の回避に応答キャッシュ助剤として記載されているものの - 改善正当。
[Kazar] Kazar, Michael Leon, "Synchronization and Caching Issues in the Andrew File System," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Dallas Winter 1988, pages 27-36. A description of the cache consistency scheme in AFS. Contrasted with other distributed file systems.
[Kazar] Kazar、マイケル・レオン、「アンドリュー・ファイル・システムにおける同期とキャッシュ関連の問題、」USENIX会議議事録、USENIX協会、バークレー、CA、ダラス冬1988年、ページ27-36。 AFSでのキャッシュの整合性スキームの説明。他の分散ファイルシステムとは対照的。
[Macklem] Macklem, Rick, "Lessons Learned Tuning the 4.3BSD Reno Implementation of the NFS Protocol," Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA, January 1991. Describes performance work in tuning the 4.3BSD Reno NFS implementation. Describes performance improvement (reduced CPU loading) through elimination of data copies.
[Macklem] Macklem、リック、「レッスンはチューニングにNFSプロトコルの4.3BSDリノの実装を学んだ、」冬のUSENIX会議議事録、USENIX協会、バークレー、CAは、1991年1月には、4.3BSDレノNFSの実装をチューニングしてパフォーマンスの作業について説明します。データ・コピーの除去を介してパフォーマンスの改善（減少CPU負荷）が記載されています。
[Mogul] Mogul, Jeffrey C., "A Recovery Protocol for Spritely NFS," USENIX File System Workshop Proceedings, Ann Arbor, MI, USENIX Association, Berkeley, CA, May 1992. Second paper on Spritely NFS proposes a lease-based scheme for recovering state of consistency protocol.
Spritely NFS上の[モーグル]モーグル、ジェフリーC.、「Spritely NFS用のリカバリプロトコル、」USENIXファイルシステムのワークショップ議事録、ミシガン州アナーバー、USENIX協会、バークレー、CA、月1992年第二紙は、リースに基づく方式を提案しています一貫性プロトコルの状態を回復します。
[Nowicki] Nowicki, Bill, "Transport Issues in the Network File System," ACM SIGCOMM newsletter Computer Communication Review, April 1989. A brief description of the basis for the dynamic retransmission work.
[Nowicki] Nowicki、ビル、「ネットワーク・ファイル・システムでの交通問題、」ACMのSIGCOMMニュースレターコンピュータコミュニケーションレビュー、1989年4月ダイナミック再送仕事の基礎の簡単な説明。
[Pawlowski] Pawlowski, Brian, Ron Hixon, Mark Stein, Joseph Tumminaro, "Network Computing in the UNIX and IBM Mainframe Environment," Uniforum `89 Conf. Proc., (1989) Description of an NFS server implementation for IBM's MVS operating system.
「UNIXおよびIBMメインフレーム環境でのネットワーク・コンピューティング、」[ポロウスキー]ポロウスキー、ブライアン、ロン・ヒクソン、マーク・スタイン、ジョセフTumminaro、のUniforum `89コンファレンス。 PROC。、IBMのMVSオペレーティング・システムのためのNFSサーバの実装の（1989）説明。
[RFC1094] Sun Microsystems, Inc., "NFS: Network File System Protocol Specification", RFC 1094, March 1989.
[RFC1094]サン・マイクロシステムズ社、 "NFS：ネットワークシステムプロトコル仕様書ファイル"、RFC 1094、1989年3月。
[RFC1345] Simonsen, K., "Character Mnemonics & Character Sets", RFC 1345, June 1992.
[RFC1345]シモンセン、K.、 "文字ニーモニック＆文字セット"、RFC 1345、1992年6月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC1813]キャラハン、B.、ポロウスキー、B.およびP.ストーバック、 "NFSバージョン3プロトコル仕様"、RFC 1813、1995年6月。
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
[RFC1831]スリニバサン、R.、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 1831、1995年8月。
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[RFC1832]スリニバサン、R.、 "XDR：外部データ表現標準"、RFC 1832、1995年8月。
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995.
[RFC1833]スリニバサン、R.、 "ONC RPCバージョン2のプロトコルのバインド"、RFC 1833、1995年8月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025]アダムス、C.、 "単純な公開鍵GSS-APIメカニズム（SPKM）"、RFC 2025、1996年10月。
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996.
[RFC2054]キャラハン、B.、 "WebNFSのクライアント仕様"、RFC 2054、1996年10月。
[RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055, October 1996.
[RFC2055]キャラハン、B.、 "WebNFSのサーバー仕様"、RFC 2055、1996年10月。
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC2078]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース、バージョン2"、RFC 2078、1997年1月。
[RFC2152] Goldsmith, D., "UTF-7 A Mail-Safe Transformation Format of Unicode", RFC 2152, May 1997.
[RFC2152]ゴールドスミス、D.、 "ユニコードのUTF-7 Aメールセーフ変換形式"、RFC 2152、1997年5月。
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, August 1995.
[RFC2203]アイスラー、M.、チウ、A.、およびL.陵、 "RPCSEC_GSSプロトコル仕様"、RFC 2203、1995年8月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999.
[RFC2623]アイスラー、M.、 "NFSバージョン2およびバージョン3のセキュリティ問題とRPCSEC_GSSとケルベロスV5のNFSプロトコルの使用"、RFC 2623、1999年6月。
[RFC2624] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, June 1999.
[RFC2624] Shepler、S.、 "NFSバージョン4の設計上の考慮事項"、RFC 2624、1999年6月。
[RFC2847] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM", RFC 2847, June 2000.
[RFC2847]アイスラー、M.、 "LIPKEY - SPKMを用いた低インフラストラクチャ公開鍵メカニズム"、RFC 2847、2000年6月。
[Sandberg] Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design and Implementation of the Sun Network Filesystem," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The basic paper describing the SunOS implementation of the NFS version 2 protocol, and discusses the goals, protocol specification and trade-offs.
[サンドバーグ]サンドバーグ、R.、D.ゴールドバーグ、S.クレイマン、D.ウォルシュ、B.リヨン、「日ネットワークファイルシステムの設計と実装、」USENIX会議議事録、USENIX協会、バークレー、CA、夏1985ザ・基本的な紙は、NFSバージョン2プロトコルのSunOSの実装を記述し、目標、プロトコル仕様とトレードオフについて説明します。
[Srinivasan] Srinivasan, V., Jeffrey C. Mogul, "Spritely NFS: Implementation and Performance of Cache Consistency Protocols", WRL Research Report 89/5, Digital Equipment Corporation Western Research Laboratory, 100 Hamilton Ave., Palo Alto, CA, 94301, May 1989. This paper analyzes the effect of applying a Sprite-like consistency protocol applied to standard NFS. The issues of recovery in a stateful environment are covered in [Mogul].
[スリニバサン]スリニバサン、V.、ジェフリーC.モーグル、「Spritely NFS：キャッシュ一貫性プロトコルの実装と性能」、WRL研究報告5分の89、ディジタル・イクイップメント・コーポレーション西研究所、100ハミルトンアベニュー、パロアルト、CA、 94301、月1989は、本稿では、標準的なNFSに適用スプライト状の一貫性プロトコルを適用した効果を分析します。ステートフル環境の回復の問題は、[ムガール人]で覆われています。
[Unicode1] The Unicode Consortium, "The Unicode Standard, Version 3.0", Addison-Wesley Developers Press, Reading, MA, 2000. ISBN 0-201-61633-5. More information available at: http://www.unicode.org/
[Unicode1]はUnicodeコンソーシアム、 "Unicode標準、バージョン3.0"、アディソン・ウェズリー開発押し、読書、MA、2000年ISBN 0-201-61633-5。 http://www.unicode.org/：でより多くの情報が利用可能
[Unicode2] "Unsupported Scripts" Unicode, Inc., The Unicode Consortium, P.O. Box 700519, San Jose, CA 95710-0519 USA, September 1999 http://www.unicode.org/unicode/standard/unsupported.html
[Unicode2] "サポートされていないスクリプト" のUnicode、Inc.の、ユニコードコンソーシアム、P。箱700519、サンノゼ、CA 95710から0519 USA、1999年9月http://www.unicode.org/unicode/standard/unsupported.html
[XNFS] The Open Group, Protocols for Interworking: XNFS, Version 3W, The Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025, ISBN 1-85912-184-5, February 1998. HTML version available: http://www.opengroup.org
[XNFS]オープングループ、インターワーキングのためのプロトコル：XNFS、バージョン3W、オープングループ、1010年エル・カミノレアルスイート380、メンロパーク、CA 94025、ISBN 1-85912-184-5、1998年2月HTMLバージョンが利用可能にします。http ：//www.opengroup.org
Spencer Shepler Sun Microsystems, Inc. 7808 Moonflower Drive Austin, Texas 78750
スペンサーSheplerサン・マイクロシステムズ株式会社7808ムーンフラワードライブオースティン、テキサス州78750
Phone: +1 512-349-9376 EMail: spencer.shepler@sun.com
電話：+1 512-349-9376電子メール：spencer.shepler@sun.com
Carl Beame Hummingbird Ltd.
カールBeameハミングバード株式会社
EMail: beame@bws.com
メールアドレス：beame@bws.com
Brent Callaghan Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
ブレントキャラハンサン・マイクロシステムズ株式会社901サンアントニオの道パロアルト、CA 94303
Phone: +1 650-786-5067 EMail: brent.callaghan@sun.com
電話：+1 650-786-5067電子メール：brent.callaghan@sun.com
Mike Eisler 5565 Wilson Road Colorado Springs, CO 80919
マイク・アイスラー5565ウィルソン道路コロラドスプリングス、CO 80919
Phone: +1 719-599-9026 EMail: mike@eisler.com
電話：+1 719-599-9026電子メール：mike@eisler.com
David Noveck Network Appliance 375 Totten Pond Road Waltham, MA 02451
デビッドNoveckネットワーク・アプライアンス375トッテン池道路ウォルサム、MA 02451
Phone: +1 781-895-4949 E-mail: dnoveck@netapp.com
電話：+1 781-895-4949 Eメール：dnoveck@netapp.com
David Robinson Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
デビッド・ロビンソンサン・マイクロシステムズ株式会社901サンアントニオの道パロアルト、CA 94303
Phone: +1 650-786-5088 EMail: david.robinson@sun.com
電話：+1 650-786-5088電子メール：david.robinson@sun.com
Robert Thurlow Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
ロバート・Thurlowサン・マイクロシステムズ株式会社901サンアントニオの道パロアルト、CA 94303
Phone: +1 650-786-5096 EMail: robert.thurlow@sun.com
電話：+1 650-786-5096電子メール：robert.thurlow@sun.com
The author thanks and acknowledges:
著者のおかげと認め：
Neil Brown for his extensive review and comments of various drafts.
彼の豊富なレビューと様々なドラフトのコメントのためのニール・ブラウン。
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。