RFC3530 日本語訳
3530 Network File System (NFS) version 4 Protocol. S. Shepler, B.Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. April 2003. (Format: TXT=600988 bytes) (Obsoletes RFC3010) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Shepler
Request for Comments: 3530 B. Callaghan
Obsoletes: 3010 D. Robinson
Category: Standards Track R. Thurlow
Sun Microsystems, Inc.
C. Beame
Hummingbird Ltd.
M. Eisler
D. Noveck
Network Appliance, Inc.
April 2003
Sheplerがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3530 B.キャラハンは以下を時代遅れにします。 3010年のD.ロビンソンカテゴリ: 標準化過程R.サーロウサン・マイクロシステムズ・インクC.Beameハチドリ株式会社M.アイスラーD.NoveckネットアプライアンスInc.2003年4月
Network File System (NFS) version 4 Protocol
ネットワークファイルシステム(NFS)バージョン4 プロトコル
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. 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プロトコルはファイルのロックのサポートとマウントプロトコルを統合している間、伝統的なファイルアクセスを支持します。 添加、強いセキュリティ(そして、交渉)のサポートでは、合成操作、クライアントキャッシュ、および国際化は加えられます。 もちろん、注意はバージョン4がインターネットで上手に操作するNFSを環境にするのに適用されました。
This document replaces RFC 3010 as the definition of the NFS version 4 protocol.
このドキュメントはNFSバージョン4プロトコルの定義としてRFC3010に取って代わります。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Shepler, et al. Standards Track [Page 1] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[1ページ]RFC3530NFSバージョン4 プロトコル2003年4月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Changes since RFC 3010 . . . . . . . . . . . . . . . 8
1.2. NFS version 4 Goals. . . . . . . . . . . . . . . . . 9
1.3. Inconsistencies of this Document with Section 18 . . 9
1.4. Overview of NFS version 4 Features . . . . . . . . . 10
1.4.1. RPC and Security . . . . . . . . . . . . . . 10
1.4.2. Procedure and Operation Structure. . . . . . 10
1.4.3. Filesystem Mode. . . . . . . . . . . . . . . 11
1.4.3.1. Filehandle Types . . . . . . . . . 11
1.4.3.2. Attribute Types. . . . . . . . . . 12
1.4.3.3. Filesystem Replication and
Migration. . . . . . . . . . . . . 13
1.4.4. OPEN and CLOSE . . . . . . . . . . . . . . . 13
1.4.5. File locking . . . . . . . . . . . . . . . . 13
1.4.6. Client Caching and Delegation. . . . . . . . 13
1.5. General Definitions. . . . . . . . . . . . . . . . . 14
2. Protocol Data Types. . . . . . . . . . . . . . . . . . . . 16
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . 16
2.2. Structured Data Types. . . . . . . . . . . . . . . . 18
3. RPC and Security Flavor. . . . . . . . . . . . . . . . . . 23
3.1. Ports and Transports . . . . . . . . . . . . . . . . 23
3.1.1. Client Retransmission Behavior . . . . . . . 24
3.2. Security Flavors . . . . . . . . . . . . . . . . . . 25
3.2.1. Security mechanisms for NFS version 4. . . . 25
3.2.1.1. Kerberos V5 as a security triple . 25
3.2.1.2. LIPKEY as a security triple. . . . 26
3.2.1.3. SPKM-3 as a security triple. . . . 27
3.3. Security Negotiation . . . . . . . . . . . . . . . . 27
3.3.1. SECINFO. . . . . . . . . . . . . . . . . . . 28
3.3.2. Security Error . . . . . . . . . . . . . . . 28
3.4. Callback RPC Authentication. . . . . . . . . . . . . 28
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1. Obtaining the First Filehandle . . . . . . . . . . . 30
4.1.1. Root Filehandle. . . . . . . . . . . . . . . 31
4.1.2. Public Filehandle. . . . . . . . . . . . . . 31
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . 31
4.2.1. General Properties of a Filehandle . . . . . 32
4.2.2. Persistent Filehandle. . . . . . . . . . . . 32
4.2.3. Volatile Filehandle. . . . . . . . . . . . . 33
4.2.4. One Method of Constructing a
Volatile Filehandle. . . . . . . . . . . . . 34
4.3. Client Recovery from Filehandle Expiration . . . . . 35
5. File Attributes. . . . . . . . . . . . . . . . . . . . . . 35
5.1. Mandatory Attributes . . . . . . . . . . . . . . . . 37
5.2. Recommended Attributes . . . . . . . . . . . . . . . 37
5.3. Named Attributes . . . . . . . . . . . . . . . . . . 37
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 8 1.1。 RFC3010.81.2以来の変化。 NFSバージョン4Goals。 . . . . . . . . . . . . . . . . 9 1.3. セクション18.91.4があるこのDocumentの矛盾。 NFSバージョン4Features. . . . . . . . . 10 1.4.1の概観。 RPCとセキュリティ. . . . . . . . . . . . . . 10 1.4.2。 手順と操作構造。 . . . . . 10 1.4.3. ファイルシステムモード。 . . . . . . . . . . . . . . 11 1.4.3.1. Filehandleは.111.4に.2に.3をタイプします。 タイプを結果と考えてください。 . . . . . . . . . 12 1.4.3.3. ファイルシステム模写と移動。 . . . . . . . . . . . . 13 1.4.4. .5に.131.4を開いて、閉じてください。 ファイルのロック. . . . . . . . . . . . . . . . 13 1.4.6。 クライアントキャッシュと代表団。 . . . . . . . 13 1.5. 一般定義。 . . . . . . . . . . . . . . . . 14 2. データ型について議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . 16 2.1. 基礎データは.162.2をタイプします。 データ型を構造化しました。 . . . . . . . . . . . . . . . 18 3. RPCとセキュリティ風味。 . . . . . . . . . . . . . . . . . 23 3.1. .1に.233.1を移植して、輸送します。 クライアントRetransmissionの振舞い. . . . . . . 24 3.2。 セキュリティは.1に.253.2に風味を添えます。 NFSバージョン4のためのセキュリティー対策。 . . . 25 3.2.1.1. セキュリティとしてのケルベロスV5は.253.2に.2に.1を3倍にします。 セキュリティとしてのLIPKEYは3倍になります。 . . . 26 3.2.1.3. セキュリティとしてのSPKM-3は3倍になります。 . . . 27 3.3. セキュリティ交渉. . . . . . . . . . . . . . . . 27 3.3.1。 SECINFO。 . . . . . . . . . . . . . . . . . . 28 3.3.2. セキュリティ誤り. . . . . . . . . . . . . . . 28 3.4。 回収RPC認証。 . . . . . . . . . . . . 28 4. Filehandles. . . . . . . . . . . . . . . . . . . . . . . . 30 4.1。 最初のFilehandle. . . . . . . . . . . 30 4.1.1を得ます。 Filehandleを根づかせてください。 . . . . . . . . . . . . . . 31 4.1.2. 公共のFilehandle。 . . . . . . . . . . . . . 31 4.2. Filehandleは.1に.314.2をタイプします。 Filehandle. . . . . 32 4.2.2の一般特性。 しつこいFilehandle。 . . . . . . . . . . . 32 4.2.3. 揮発性のFilehandle。 . . . . . . . . . . . . 33 4.2.4. 揮発性のFilehandleを組み立てる1つの方法。 . . . . . . . . . . . . 34 4.3. Filehandle満了. . . . . 35 5からのクライアント回復。 属性をファイルしてください。 . . . . . . . . . . . . . . . . . . . . . 35 5.1. 義務的な属性. . . . . . . . . . . . . . . . 37 5.2。 お勧めの属性. . . . . . . . . . . . . . . 37 5.3。 属性. . . . . . . . . . . . . . . . . . 37と命名されます。
Shepler, et al. Standards Track [Page 2] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[2ページ]RFC3530NFSバージョン4 プロトコル2003年4月
5.4. Classification of Attributes . . . . . . . . . . . . 38
5.5. Mandatory Attributes - Definitions . . . . . . . . . 39
5.6. Recommended Attributes - Definitions . . . . . . . . 41
5.7. Time Access. . . . . . . . . . . . . . . . . . . . . 46
5.8. Interpreting owner and owner_group . . . . . . . . . 47
5.9. Character Case Attributes. . . . . . . . . . . . . . 49
5.10. Quota Attributes . . . . . . . . . . . . . . . . . . 49
5.11. Access Control Lists . . . . . . . . . . . . . . . . 50
5.11.1. ACE type . . . . . . . . . . . . . . . . . 51
5.11.2. ACE Access Mask. . . . . . . . . . . . . . 52
5.11.3. ACE flag . . . . . . . . . . . . . . . . . 54
5.11.4. ACE who . . . . . . . . . . . . . . . . . 55
5.11.5. Mode Attribute . . . . . . . . . . . . . . 56
5.11.6. Mode and ACL Attribute . . . . . . . . . . 57
5.11.7. mounted_on_fileid. . . . . . . . . . . . . 57
6. Filesystem Migration and Replication . . . . . . . . . . . 58
6.1. Replication. . . . . . . . . . . . . . . . . . . . . 58
6.2. Migration. . . . . . . . . . . . . . . . . . . . . . 59
6.3. Interpretation of the fs_locations Attribute . . . . 60
6.4. Filehandle Recovery for Migration or Replication . . 61
7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . 61
7.1. Server Exports . . . . . . . . . . . . . . . . . . . 61
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . 62
7.3. Server Pseudo Filesystem . . . . . . . . . . . . . . 62
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . 63
7.5. Filehandle Volatility. . . . . . . . . . . . . . . . 63
7.6. Exported Root. . . . . . . . . . . . . . . . . . . . 63
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . 63
7.8. Security Policy and Name Space Presentation. . . . . 64
8. File Locking and Share Reservations. . . . . . . . . . . . 65
8.1. Locking. . . . . . . . . . . . . . . . . . . . . . . 65
8.1.1. Client ID. . . . . . . . . . . . . . . . . 66
8.1.2. Server Release of Clientid . . . . . . . . 69
8.1.3. lock_owner and stateid Definition. . . . . 69
8.1.4. Use of the stateid and Locking . . . . . . 71
8.1.5. Sequencing of Lock Requests. . . . . . . . 73
8.1.6. Recovery from Replayed Requests. . . . . . 74
8.1.7. Releasing lock_owner State . . . . . . . . 74
8.1.8. Use of Open Confirmation . . . . . . . . . 75
8.2. Lock Ranges. . . . . . . . . . . . . . . . . . . . . 76
8.3. Upgrading and Downgrading Locks. . . . . . . . . . . 76
8.4. Blocking Locks . . . . . . . . . . . . . . . . . . . 77
8.5. Lease Renewal. . . . . . . . . . . . . . . . . . . . 77
8.6. Crash Recovery . . . . . . . . . . . . . . . . . . . 78
8.6.1. Client Failure and Recovery. . . . . . . . 79
8.6.2. Server Failure and Recovery. . . . . . . . 79
8.6.3. Network Partitions and Recovery. . . . . . 81
8.7. Recovery from a Lock Request Timeout or Abort . . . 85
5.4. 属性. . . . . . . . . . . . 38 5.5の分類。 義務的な属性--定義. . . . . . . . . 39 5.6。 お勧めの属性--定義. . . . . . . . 41 5.7。 時間アクセサリー . . . . . . . . . . . . . . . . . . . . 46 5.8. 所有者と所有者_グループ. . . . . . . . . 47 5.9を解釈します。 キャラクターケース属性。 . . . . . . . . . . . . . 49 5.10. 割当て属性. . . . . . . . . . . . . . . . . . 49 5.11。 アクセスコントロールリスト. . . . . . . . . . . . . . . . 50 5.11.1。 ACEタイプ. . . . . . . . . . . . . . . . . 51 5.11.2。 アクセスマスクを負かしてください。 . . . . . . . . . . . . . 52 5.11.3. ACE旗. . . . . . . . . . . . . . . . . 54 5.11の.4。 ACE、だれ、.55 5.11 .5。 モード属性. . . . . . . . . . . . . . 56 5.11.6。 モードとACL Attribute. . . . . . . . . . 57 5.11.7は_fileidに_を取り付けました。 . . . . . . . . . . . . 57 6. ファイルシステム移動と模写. . . . . . . . . . . 58 6.1。 模写。 . . . . . . . . . . . . . . . . . . . . 58 6.2. 移動。 . . . . . . . . . . . . . . . . . . . . . 59 6.3. fs_位置Attribute. . . . 60 6.4の解釈。 移動か模写. . 61 7のためのFilehandle回復。 NFSサーバー名スペース. . . . . . . . . . . . . . . . . . . 61 7.1。 サーバ輸出. . . . . . . . . . . . . . . . . . . 61 7.2。 輸出. . . . . . . . . . . . . . . . . . 62 7.3をブラウズします。 サーバ疑似ファイルシステム. . . . . . . . . . . . . . 62 7.4。 重解. . . . . . . . . . . . . . . . . . . 63 7.5。 Filehandleの不安定さ。 . . . . . . . . . . . . . . . 63 7.6. 根を輸出しました。 . . . . . . . . . . . . . . . . . . . 63 7.7. .637.8に交差して、ポイントを取り付けてください。 安全保障政策と名前宇宙プレゼンテーション。 . . . . 64 8. ロックをファイルしてください、そして、予約を共有してください。 . . . . . . . . . . . 65 8.1. ロック。 . . . . . . . . . . . . . . . . . . . . . . 65 8.1.1. クライアントID。 . . . . . . . . . . . . . . . . 66 8.1.2. Clientid. . . . . . . . 69 8.1.3の錠_所有者とstateid DefinitionのサーバRelease。 . . . . 69 8.1.4. stateidとLocking. . . . . . 71 8.1.5の使用。 ロック要求の配列。 . . . . . . . 73 8.1.6. 再演された要求からの回復。 . . . . . 74 8.1.7. ロック_所有者州. . . . . . . . 74 8.1.8をリリースします。 開いている確認. . . . . . . . . 75 8.2の使用。 範囲をロックしてください。 . . . . . . . . . . . . . . . . . . . . 76 8.3. 錠をアップグレードして、格下げします。 . . . . . . . . . . 76 8.4. 錠. . . . . . . . . . . . . . . . . . . 77 8.5を妨げます。 更新を賃貸してください。 . . . . . . . . . . . . . . . . . . . 77 8.6. 回復. . . . . . . . . . . . . . . . . . . 78 8.6.1を墜落させてください。 クライアント失敗と回復。 . . . . . . . 79 8.6.2. サーバ失敗と回復。 . . . . . . . 79 8.6.3. パーティションと回復をネットワークでつないでください。 . . . . . 81 8.7. ロック要求タイムアウトかアボート. . . 85からの回復
Shepler, et al. Standards Track [Page 3] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[3ページ]RFC3530NFSバージョン4 プロトコル2003年4月
8.8. Server Revocation of Locks. . . . . . . . . . . . . 85
8.9. Share Reservations. . . . . . . . . . . . . . . . . 86
8.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . 87
8.10.1. Close and Retention of State
Information. . . . . . . . . . . . . . . . 88
8.11. Open Upgrade and Downgrade. . . . . . . . . . . . . 88
8.12. Short and Long Leases . . . . . . . . . . . . . . . 89
8.13. Clocks, Propagation Delay, and Calculating Lease
Expiration. . . . . . . . . . . . . . . . . . . . . 89
8.14. Migration, Replication and State. . . . . . . . . . 90
8.14.1. Migration and State. . . . . . . . . . . . 90
8.14.2. Replication and State. . . . . . . . . . . 91
8.14.3. Notification of Migrated Lease . . . . . . 92
8.14.4. Migration and the Lease_time Attribute . . 92
9. Client-Side Caching . . . . . . . . . . . . . . . . . . . . 93
9.1. Performance Challenges for Client-Side Caching. . . 93
9.2. Delegation and Callbacks. . . . . . . . . . . . . . 94
9.2.1. Delegation Recovery . . . . . . . . . . . . 96
9.3. Data Caching. . . . . . . . . . . . . . . . . . . . 98
9.3.1. Data Caching and OPENs . . . . . . . . . . 98
9.3.2. Data Caching and File Locking. . . . . . . 99
9.3.3. Data Caching and Mandatory File Locking. . 101
9.3.4. Data Caching and File Identity . . . . . . 101
9.4. Open Delegation . . . . . . . . . . . . . . . . . . 102
9.4.1. Open Delegation and Data Caching . . . . . 104
9.4.2. Open Delegation and File Locks . . . . . . 106
9.4.3. Handling of CB_GETATTR . . . . . . . . . . 106
9.4.4. Recall of Open Delegation. . . . . . . . . 109
9.4.5. Clients that Fail to Honor
Delegation Recalls . . . . . . . . . . . . 111
9.4.6. Delegation Revocation. . . . . . . . . . . 112
9.5. Data Caching and Revocation . . . . . . . . . . . . 112
9.5.1. Revocation Recovery for Write Open
Delegation . . . . . . . . . . . . . . . . 113
9.6. Attribute Caching . . . . . . . . . . . . . . . . . 113
9.7. Data and Metadata Caching and Memory Mapped Files . 115
9.8. Name Caching . . . . . . . . . . . . . . . . . . . 118
9.9. Directory Caching . . . . . . . . . . . . . . . . . 119
10. Minor Versioning . . . . . . . . . . . . . . . . . . . . . 120
11. Internationalization . . . . . . . . . . . . . . . . . . . 122
11.1. Stringprep profile for the utf8str_cs type. . . . . 123
11.1.1. Intended applicability of the
nfs4_cs_prep profile . . . . . . . . . . . 123
11.1.2. Character repertoire of nfs4_cs_prep . . . 124
11.1.3. Mapping used by nfs4_cs_prep . . . . . . . 124
11.1.4. Normalization used by nfs4_cs_prep . . . . 124
11.1.5. Prohibited output for nfs4_cs_prep . . . . 125
11.1.6. Bidirectional output for nfs4_cs_prep. . . 125
8.8. 錠のサーバ取消し。 . . . . . . . . . . . . 85 8.9. 予約を共有してください。 . . . . . . . . . . . . . . . . 86 8.10. 操作. . . . . . . . . . . . . . . 87 8.10.1を開くか、または閉じてください。 州の情報の閉鎖と保有。 . . . . . . . . . . . . . . . 88 8.11. アップグレードとダウングレードを開いてください。 . . . . . . . . . . . . 88 8.12. 短くて長いリース. . . . . . . . . . . . . . . 89 8.13。 時計、伝播遅延、および計算は満了を賃貸します。 . . . . . . . . . . . . . . . . . . . . 89 8.14. 移動、模写、および状態。 . . . . . . . . . 90 8.14.1. 移動と状態。 . . . . . . . . . . . 90 8.14.2. 模写と状態。 . . . . . . . . . . 91 8.14.3. 通知、移動、リース. . . . . . 92 8.14.4 移動とリース_時間属性. . 92 9。 クライアントサイドキャッシュ. . . . . . . . . . . . . . . . . . . . 93 9.1。 パフォーマンスはクライアントサイドキャッシュのために挑戦します。 . . 93 9.2. 代表団と回収。 . . . . . . . . . . . . . 94 9.2.1. 代表団回復. . . . . . . . . . . . 96 9.3。 データキャッシュ。 . . . . . . . . . . . . . . . . . . . 98 9.3.1. データ、キャッシュして、.2に.989.3を開きます。 データキャッシュとファイルのロック。 . . . . . . 99 9.3.3. データのキャッシュしていて義務的なファイルのロック。 . 101 9.3.4. データキャッシュとファイルのアイデンティティ. . . . . . 101 9.4。 代表団. . . . . . . . . . . . . . . . . . 102 9.4.1を開いてください。 代表団とデータキャッシュ. . . . . 104 9.4.2を開いてください。 代表団とファイルロック. . . . . . 106 9.4.3を開いてください。 CB_GETATTR. . . . . . . . . . 106 9.4.4の取り扱い。 開いている代表団のリコール。 . . . . . . . . 109 9.4.5. クライアントはHonor Delegation Recalls. . . . . . . . . . . . 111 9.4.6へのそのFailです。 代表団取消し。 . . . . . . . . . . 112 9.5. データキャッシュと取消し. . . . . . . . . . . . 112 9.5.1。 取消し回復、開いている代表団. . . . . . . . . . . . . . . . 113 9.6に書いてください。 キャッシュ. . . . . . . . . . . . . . . . . 113 9.7を結果と考えてください。 データ、メタデータキャッシュ、およびメモリはファイル. 115 9.8を写像しました。 キャッシュ. . . . . . . . . . . . . . . . . . . 118 9.9を命名してください。 ディレクトリキャッシュ. . . . . . . . . . . . . . . . . 119 10。 小さい方のVersioning. . . . . . . . . . . . . . . . . . . . . 120 11。 国際化. . . . . . . . . . . . . . . . . . . 122 11.1。 utf8str_CsタイプへのStringprepプロフィール。 . . . . 123 11.1.1. nfs4_Cs_予習プロフィール. . . . . . . . . . . 123 11.1.2のものの意図している適用性。 nfs4_Cs_予習. . . 124 11.1.3のキャラクターレパートリー。 nfs4_Cs_予習. . . . . . . 124 11.1.4使用されるマッピング。 nfs4_Cs_予習. . . . 124 11.1.5使用される正常化。 nfs4_Cs_予習. . . . 125 11.1.6のための出力を禁止しました。 nfs4_Cs_予習のための双方向の出力。 . . 125
Shepler, et al. Standards Track [Page 4] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[4ページ]RFC3530NFSバージョン4 プロトコル2003年4月
11.2. Stringprep profile for the utf8str_cis type . . . . 125
11.2.1. Intended applicability of the
nfs4_cis_prep profile. . . . . . . . . . . 125
11.2.2. Character repertoire of nfs4_cis_prep . . 125
11.2.3. Mapping used by nfs4_cis_prep . . . . . . 125
11.2.4. Normalization used by nfs4_cis_prep . . . 125
11.2.5. Prohibited output for nfs4_cis_prep . . . 126
11.2.6. Bidirectional output for nfs4_cis_prep . . 126
11.3. Stringprep profile for the utf8str_mixed type . . . 126
11.3.1. Intended applicability of the
nfs4_mixed_prep profile. . . . . . . . . . 126
11.3.2. Character repertoire of nfs4_mixed_prep . 126
11.3.3. Mapping used by nfs4_cis_prep . . . . . . 126
11.3.4. Normalization used by nfs4_mixed_prep . . 127
11.3.5. Prohibited output for nfs4_mixed_prep . . 127
11.3.6. Bidirectional output for nfs4_mixed_prep . 127
11.4. UTF-8 Related Errors. . . . . . . . . . . . . . . . 127
12. Error Definitions . . . . . . . . . . . . . . . . . . . . 128
13. NFS version 4 Requests . . . . . . . . . . . . . . . . . . 134
13.1. Compound Procedure. . . . . . . . . . . . . . . . . 134
13.2. Evaluation of a Compound Request. . . . . . . . . . 135
13.3. Synchronous Modifying Operations. . . . . . . . . . 136
13.4. Operation Values. . . . . . . . . . . . . . . . . . 136
14. NFS version 4 Procedures . . . . . . . . . . . . . . . . . 136
14.1. Procedure 0: NULL - No Operation. . . . . . . . . . 136
14.2. Procedure 1: COMPOUND - Compound Operations . . . . 137
14.2.1. Operation 3: ACCESS - Check Access
Rights. . . . . . . . . . . . . . . . . . 140
14.2.2. Operation 4: CLOSE - Close File . . . . . 142
14.2.3. Operation 5: COMMIT - Commit
Cached Data . . . . . . . . . . . . . . . 144
14.2.4. Operation 6: CREATE - Create a
Non-Regular File Object . . . . . . . . . 147
14.2.5. Operation 7: DELEGPURGE -
Purge Delegations Awaiting Recovery . . . 150
14.2.6. Operation 8: DELEGRETURN - Return
Delegation. . . . . . . . . . . . . . . . 151
14.2.7. Operation 9: GETATTR - Get Attributes . . 152
14.2.8. Operation 10: GETFH - Get Current
Filehandle. . . . . . . . . . . . . . . . 153
14.2.9. Operation 11: LINK - Create Link to a
File. . . . . . . . . . . . . . . . . . . 154
14.2.10. Operation 12: LOCK - Create Lock . . . . 156
14.2.11. Operation 13: LOCKT - Test For Lock . . . 160
14.2.12. Operation 14: LOCKU - Unlock File . . . . 162
14.2.13. Operation 15: LOOKUP - Lookup Filename. . 163
14.2.14. Operation 16: LOOKUPP - Lookup
Parent Directory. . . . . . . . . . . . . 165
11.2. Stringprepはutf8str_cisのためにタイプ. . . . 125 11.2.1の輪郭を描きます。 nfs4_cis_予習プロフィールの意図している適用性。 . . . . . . . . . . 125 11.2.2. nfs4_cis_予習. . 125 11.2.3のキャラクターレパートリー。 nfs4_cis_予習. . . . . . 125 11.2.4使用されるマッピング。 nfs4_cis_予習. . . 125 11.2.5使用される正常化。 nfs4_cis_予習. . . 126 11.2.6のための出力を禁止しました。 nfs4_cis_予習. . 126 11.3のための双方向の出力。 Stringprepはutf8strのために_複雑なタイプ. . . 126 11.3.1の輪郭を描きます。 nfs4_の意図している適用性は_予習プロフィールを混ぜました。 . . . . . . . . . 126 11.3.2. nfs4_のキャラクターレパートリーは_予習. 126 11.3.3を混ぜました。 nfs4_cis_予習. . . . . . 126 11.3.4使用されるマッピング。 nfs4_によって使用された正常化は_予習. . 127 11.3.5を混ぜました。 nfs4_のための禁止された出力は_予習. . 127 11.3.6を混ぜました。 nfs4_のための双方向の出力は_予習. 127 11.4を混ぜました。 UTF-8は誤りを関係づけました。 . . . . . . . . . . . . . . . 127 12. 誤り定義. . . . . . . . . . . . . . . . . . . . 128 13。 NFSバージョン4Requests. . . . . . . . . . . . . . . . . . 134 13.1。 手順を合成してください。 . . . . . . . . . . . . . . . . 134 13.2. 合成要求の評価。 . . . . . . . . . 135 13.3. 同期変更作業。 . . . . . . . . . 136 13.4. 操作値。 . . . . . . . . . . . . . . . . . 136 14. NFSバージョン4Procedures. . . . . . . . . . . . . . . . . 136 14.1。 手順0: ヌル--操作がありません。 . . . . . . . . . 136 14.2. 手順1: 化合物--操作. . . . 137 14.2.1を合成してください。 操作3: アクセス--アクセス権をチェックしてください。 . . . . . . . . . . . . . . . . . 140 14.2.2. 操作4: 閉じてください--近いファイル. . . . . 142 14.2.3。 操作5: 公約してください--キャッシュされたデータ. . . . . . . . . . . . . . . 144 14.2.4を遂行してください。 操作6: 作成、--.5に非レギュラーのファイルオブジェクト. . . . . . . . . 147 14.2を作成してください 操作7: DELEGPURGE--回復. . . 150 14.2.6を待つ委譲を掃除してください。 操作8: DELEGRETURN--委譲を返してください。 . . . . . . . . . . . . . . . 151 14.2.7. 操作9: GETATTR--属性. . 152 14.2.8を得てください。 操作10: GETFH--現在のFilehandleを手に入れてください。 . . . . . . . . . . . . . . . 153 14.2.9. 操作11: リンクしてください--ファイルへのリンクを作成してください。 . . . . . . . . . . . . . . . . . . 154 14.2.10. 操作12: ロックしてください--ロック. . . . 156 14.2.11を作成してください。 操作13: LOCKT--ロック. . . 160 14.2.12には、テストしてください。 操作14: LOCKU--ファイル. . . . 162 14.2.13をアンロックしてください。 操作15: ルックアップ--ルックアップファイル名。 . 163 14.2.14. 操作16: LOOKUPP--ルックアップ親ディレクトリ。 . . . . . . . . . . . . 165
Shepler, et al. Standards Track [Page 5] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[5ページ]RFC3530NFSバージョン4 プロトコル2003年4月
14.2.15. Operation 17: NVERIFY - Verify
Difference in Attributes . . . . . . . . 166
14.2.16. Operation 18: OPEN - Open a Regular
File. . . . . . . . . . . . . . . . . . . 168
14.2.17. Operation 19: OPENATTR - Open Named
Attribute Directory . . . . . . . . . . . 178
14.2.18. Operation 20: OPEN_CONFIRM -
Confirm Open . . . . . . . . . . . . . . 180
14.2.19. Operation 21: OPEN_DOWNGRADE -
Reduce Open File Access . . . . . . . . . 182
14.2.20. Operation 22: PUTFH - Set
Current Filehandle. . . . . . . . . . . . 184
14.2.21. Operation 23: PUTPUBFH -
Set Public Filehandle . . . . . . . . . . 185
14.2.22. Operation 24: PUTROOTFH -
Set Root Filehandle . . . . . . . . . . . 186
14.2.23. Operation 25: READ - Read from File . . . 187
14.2.24. Operation 26: READDIR -
Read Directory. . . . . . . . . . . . . . 190
14.2.25. Operation 27: READLINK -
Read Symbolic Link. . . . . . . . . . . . 193
14.2.26. Operation 28: REMOVE -
Remove Filesystem Object. . . . . . . . . 195
14.2.27. Operation 29: RENAME -
Rename Directory Entry. . . . . . . . . . 197
14.2.28. Operation 30: RENEW - Renew a Lease . . . 200
14.2.29. Operation 31: RESTOREFH -
Restore Saved Filehandle. . . . . . . . . 201
14.2.30. Operation 32: SAVEFH - Save
Current Filehandle. . . . . . . . . . . . 202
14.2.31. Operation 33: SECINFO - Obtain
Available Security. . . . . . . . . . . . 203
14.2.32. Operation 34: SETATTR - Set Attributes. . 206
14.2.33. Operation 35: SETCLIENTID -
Negotiate Clientid. . . . . . . . . . . . 209
14.2.34. Operation 36: SETCLIENTID_CONFIRM -
Confirm Clientid. . . . . . . . . . . . . 213
14.2.35. Operation 37: VERIFY -
Verify Same Attributes. . . . . . . . . . 217
14.2.36. Operation 38: WRITE - Write to File . . . 218
14.2.37. Operation 39: RELEASE_LOCKOWNER -
Release Lockowner State . . . . . . . . . 223
14.2.38. Operation 10044: ILLEGAL -
Illegal operation . . . . . . . . . . . . 224
15. NFS version 4 Callback Procedures . . . . . . . . . . . . 225
15.1. Procedure 0: CB_NULL - No Operation . . . . . . . . 225
15.2. Procedure 1: CB_COMPOUND - Compound
Operations. . . . . . . . . . . . . . . . . . . . . 226
14.2.15. 操作17: NVERIFY--属性. . . . . . . . 166 14.2.16の違いについて確かめてください。 操作18: 開いてください--通常のファイルを開いてください。 . . . . . . . . . . . . . . . . . . 168 14.2.17. 操作19: OPENATTR--命名された属性ディレクトリ. . . . . . . . . . . 178 14.2.18を開いてください。 操作20: _が確認する戸外--開いている.18014.2に.19を確認してください。 操作21: 戸外_ダウングレード--オープン・ファイルアクセス. . . . . . . . . 182 14.2.20を減少させてください。 操作22: PUTFH--現在のFilehandleを設定してください。 . . . . . . . . . . . 184 14.2.21. 操作23: PUTPUBFH--公共のFilehandle. . . . . . . . . . 185 14.2.22を設定してください。 操作24: PUTROOTFH--根のFilehandle. . . . . . . . . . . 186 14.2.23を設定してください。 操作25: 読んでください--ファイル. . . 187 14.2.24から、読んでください。 操作26: READDIR--ディレクトリを読んでください。 . . . . . . . . . . . . . 190 14.2.25. 操作27: READLINK--シンボリックリンクを読んでください。 . . . . . . . . . . . 193 14.2.26. 操作28: 取り外してください--ファイルシステム対象物を取り外してください。 . . . . . . . . 195 14.2.27. 操作29: 改名、--ディレクトリエントリを改名してください。 . . . . . . . . . 197 14.2.28. 操作30: 更新してください--リース. . . 200 14.2.29を更新してください。 操作31: RESTOREFH--保存しているFilehandleを返してください。 . . . . . . . . 201 14.2.30. 操作32: SAVEFH--現在のFilehandleを取っておいてください。 . . . . . . . . . . . 202 14.2.31. 操作33: SECINFO--利用可能なセキュリティを得てください。 . . . . . . . . . . . 203 14.2.32. 操作34: SETATTR--属性を設定してください。 . 206 14.2.33. 操作35: SETCLIENTID--Clientidを交渉してください。 . . . . . . . . . . . 209 14.2.34. 操作36: SETCLIENTID_が確認する、--Clientidを確認してください。 . . . . . . . . . . . . 213 14.2.35. 操作37: 検証、--同じ属性について確かめてください。 . . . . . . . . . 217 14.2.36. 操作38: 書いてください--ファイル. . . 218 14.2.37まで書いてください。 操作39: _LOCKOWNERをリリースしてください--リリースLockowner州. . . . . . . . . 223 14.2の.38。 操作10044: ILLEGAL--違法手術. . . . . . . . . . . . 224 15。 NFSバージョン4Callback Procedures. . . . . . . . . . . . 225 15.1。 手順0: CB_ヌル--いいえ操作. . . . . . . . 225 15.2。 手順1: CB_化合物--操作を合成してください。 . . . . . . . . . . . . . . . . . . . . 226
Shepler, et al. Standards Track [Page 6] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[6ページ]RFC3530NFSバージョン4 プロトコル2003年4月
15.2.1. Operation 3: CB_GETATTR - Get
Attributes . . . . . . . . . . . . . . . . 228
15.2.2. Operation 4: CB_RECALL -
Recall an Open Delegation. . . . . . . . . 229
15.2.3. Operation 10044: CB_ILLEGAL -
Illegal Callback Operation . . . . . . . . 230
16. Security Considerations . . . . . . . . . . . . . . . . . 231
17. IANA Considerations . . . . . . . . . . . . . . . . . . . 232
17.1. Named Attribute Definition. . . . . . . . . . . . . 232
17.2. ONC RPC Network Identifiers (netids). . . . . . . . 232
18. RPC definition file . . . . . . . . . . . . . . . . . . . 234
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 268
20. Normative References . . . . . . . . . . . . . . . . . . . 268
21. Informative References . . . . . . . . . . . . . . . . . . 270
22. Authors' Information . . . . . . . . . . . . . . . . . . . 273
22.1. Editor's Address. . . . . . . . . . . . . . . . . . 273
22.2. Authors' Addresses. . . . . . . . . . . . . . . . . 274
23. Full Copyright Statement . . . . . . . . . . . . . . . . . 275
15.2.1. 操作3: CB_GETATTR--属性. . . . . . . . . . . . . . . . 228 15.2.2を得てください。 操作4: CB_リコール--開いている委譲を思い出してください。 . . . . . . . . 229 15.2.3. 操作10044: CB_不法入国者--不法なコールバック操作. . . . . . . . 230 16。 セキュリティ問題. . . . . . . . . . . . . . . . . 231 17。 IANA問題. . . . . . . . . . . . . . . . . . . 232 17.1。 属性定義と命名されます。 . . . . . . . . . . . . 232 17.2. ONC RPCは識別子(netids)をネットワークでつなぎます。 . . . . . . . 232 18. RPC定義ファイル. . . . . . . . . . . . . . . . . . . 234 19。 承認. . . . . . . . . . . . . . . . . . . . . 268 20。 引用規格. . . . . . . . . . . . . . . . . . . 268 21。 有益な参照. . . . . . . . . . . . . . . . . . 270 22。 作者の情報. . . . . . . . . . . . . . . . . . . 273 22.1。 エディタのアドレス。 . . . . . . . . . . . . . . . . . 273 22.2. 作者のアドレス。 . . . . . . . . . . . . . . . . 274 23. 完全な著作権宣言文. . . . . . . . . . . . . . . . . 275
Shepler, et al. Standards Track [Page 7] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[7ページ]RFC3530NFSバージョン4 プロトコル2003年4月
1. Introduction
1. 序論
1.1. Changes since RFC 3010
1.1. RFC3010以来の変化
This definition of the NFS version 4 protocol replaces or obsoletes the definition present in [RFC3010]. While portions of the two documents have remained the same, there have been substantive changes in others. The changes made between [RFC3010] and this document represent implementation experience and further review of the protocol. While some modifications were made for ease of implementation or clarification, most updates represent errors or situations where the [RFC3010] definition were untenable.
NFSバージョン4プロトコルのこの定義は、[RFC3010]の現在の定義を取り替えるか、または時代遅れにします。 2通のドキュメントの一部が同じままで残っている間、他のものにおける実質的な変化があります。 [RFC3010]とこのドキュメントの間で行われた変更はプロトコルの実装経験とさらなるレビューを表します。 実装か明確化の容易さのためにいくつかの変更をしていた間、ほとんどのアップデートが[RFC3010]定義が支持できない誤りか状況を表します。
The following list is not all inclusive of all changes but presents some of the most notable changes or additions made:
以下のリストは最も注目に値することの或るものが変えるか、または追加が作ったすべての変化にもかかわらず、プレゼントをすべて含んでいません:
o The state model has added an open_owner4 identifier. This was
done to accommodate Posix based clients and the model they use for
file locking. For Posix clients, an open_owner4 would correspond
to a file descriptor potentially shared amongst a set of processes
and the lock_owner4 identifier would correspond to a process that
is locking a file.
o 州のモデルは開いている_owner4識別子を加えました。 彼らがファイルのロックに使用するPosixのベースのクライアントとモデルに対応するためにこれをしました。 Posixクライアントに関しては、戸外_owner4は1セットのプロセスの中で潜在的に共有されたファイルディスクリプタに対応しているでしょう、そして、錠_owner4識別子はファイルをロックしているプロセスに対応しているでしょう。
o Clarifications and error conditions were added for the handling of
the owner and group attributes. Since these attributes are string
based (as opposed to the numeric uid/gid of previous versions of
NFS), translations may not be available and hence the changes
made.
o 明確化とエラー条件は所有者とグループ属性の取り扱いのために加えられました。 これらの属性が基づく(NFSの旧バージョンの数値uid/ヒツジ暈倒病と対照的に)ストリングであるので、翻訳は、利用可能であって、したがって、行われた変更でないかもしれません。
o Clarifications for the ACL and mode attributes to address
evaluation and partial support.
o ACLとモード属性が評価と部分的なサポートを扱う明確化。
o For identifiers that are defined as XDR opaque, limits were set on
their size.
o XDR不透明なものと定義される識別子において、限界はそれらのサイズに設定されました。
o Added the mounted_on_filed attribute to allow Posix clients to
correctly construct local mounts.
o _の上の取り付けられた_がPosixクライアントが正しく地方のマウントを組み立てるのを許容するために属性をファイルしたと言い足しました。
o Modified the SETCLIENTID/SETCLIENTID_CONFIRM operations to deal
correctly with confirmation details along with adding the ability
to specify new client callback information. Also added
clarification of the callback information itself.
o 新しいクライアントコールバック情報を指定する能力を加えると共に確認の詳細に正しく対処するようにSETCLIENTID/SETCLIENTID_CONFIRM操作を変更しました。 コールバック情報自体のまた、加えられた明確化。
o Added a new operation LOCKOWNER_RELEASE to enable notifying the
server that a lock_owner4 will no longer be used by the client.
o 錠_owner4がもうクライアントによって使用されないようにサーバに通知しながら可能にするために新しい操作LOCKOWNER_RELEASEを加えます。
o RENEW operation changes to identify the client correctly and allow
for additional error returns.
o RENEW操作は、正しくクライアントを特定して、追加誤りリターンを考慮するために変化します。
Shepler, et al. Standards Track [Page 8] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[8ページ]RFC3530NFSバージョン4 プロトコル2003年4月
o Verify error return possibilities for all operations.
o すべての操作のために誤りリターンの可能性について確かめてください。
o Remove use of the pathname4 data type from LOOKUP and OPEN in
favor of having the client construct a sequence of LOOKUP
operations to achieive the same effect.
o pathname4データ型のクライアントにLOOKUP操作の系列を構成させることを支持してLOOKUPとオープンから同じくらいが作用するachieiveまでの使用を取り除いてください。
o Clarification of the internationalization issues and adoption of
the new stringprep profile framework.
o 国際化問題の明確化と新しいstringprepの採用はフレームワークの輪郭を描きます。
1.2. NFS Version 4 Goals
1.2. NFSバージョン4目標
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:
NFSバージョン4プロトコルは既にバージョン2[RFC1094]と3[RFC1813]までに定義されたNFSプロトコルのさらなる改正です。 それは旧バージョンの本質的特質を保有します: 簡単な回復には、トランスポート・プロトコルの如何にかかわらずオペレーティングシステム、ファイルシステム、簡単さ、および望ましい市場成果を設計してください。 NFSバージョン4改正には、以下の目標があります:
o Improved access and good performance on the Internet.
o インターネットに関する改良されたアクセスと望ましい市場成果。
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.
プロトコルは容易にトランジットファイアウォールに設計されています、そして、潜在が高く、帯域幅が低いところでよく振る舞ってください、そして、非常に多くの1サーバあたりのクライアントに比例してください。
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プロトコルは、1人の極小集合のセキュリティ体系をサポートするためにセキュリティを交渉して、クライアントとサーバを必要とする能力をクライアントとサーバに許容するためにメカニズムを提供します。
o Good cross-platform interoperability.
o 良いクロスプラットフォーム相互運用性。
The protocol features a filesystem model that provides a useful,
common set of features that does not unduly favor one filesystem
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.
プロトコルは、後方の互換性に感染しない標準の拡大を受け入れるように設計されています。
1.3. Inconsistencies of this Document with Section 18
1.3. セクション18とのこのDocumentの矛盾
Section 18, RPC Definition File, contains the definitions in XDR description language of the constructs used by the protocol. Prior to Section 18, several of the constructs are reproduced for purposes
セクション18(RPC Definition File)はプロトコルによって使用される構造物のXDR記述言語との定義を含みます。 セクション18の前では、いくつかの構造物が目的のために再生します。
Shepler, et al. Standards Track [Page 9] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[9ページ]RFC3530NFSバージョン4 プロトコル2003年4月
of explanation. The reader is warned of the possibility of errors in the reproduced constructs outside of Section 18. For any part of the document that is inconsistent with Section 18, Section 18 is to be considered authoritative.
説明について。 読者について再生の誤りの可能性が外にセクション18を作ると警告されます。 セクション18に矛盾したドキュメントのどんな部分においても、セクション18は正式であると考えられることになっています。
1.4. Overview of NFS version 4 Features
1.4. NFSバージョン4Featuresの概要
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 filesystems and distributed filesystems is expected as well.
要するに、妥当な文脈を読者に提供するために、NFSバージョン4プロトコルの主要な特徴は再検討されるでしょう。 NFSプロトコルの旧バージョンに詳しい読者とNFSプロトコルに新しい読者の両方のための適切な関係を提供するためにこれをするでしょう。 NFSプロトコルに新しい読者のために、予想される基礎知識がまだあります。 読者は[RFC1831]と[RFC1832]で説明されるようにXDRとRPCプロトコルに詳しいはずです。 また、ファイルシステムと分配されたファイルシステムに関する基礎知識は予想されます。
1.4.1. RPC and Security
1.4.1. 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 [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.
NFSの旧バージョンのように、NFSバージョン4プロトコルに使用されるExternal Data Representation(XDR)とRemote Procedure Call(RPC)メカニズムは[RFC1831]と[RFC1832]で定義されたものです。 セキュリティ要件を終わらせるために終わりに間に合うと、RPCSEC_GSSフレームワーク[RFC2203]は、基本的なRPCセキュリティを広げるのに使用されるでしょう。 RPCSEC_GSSの使用に、NFSバージョン4プロトコルに認証、保全、およびプライバシーを提供するために様々なメカニズムを提供できます。 ケルベロスV5は1つのセキュリティフレームワークを提供するために[RFC1964]で説明されるように使用されるでしょう。 [RFC2847]で説明されたLIPKEY GSS-APIメカニズムは、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 filesystem resources. With this, the client can securely match the security mechanism that meets the policies specified at both the client and server.
バンドにおけるセキュリティ交渉を可能にするために、NFSバージョン4プロトコルはサーバのファイルシステムリソースへのアクセスにセキュリティー対策を使用しなければならない方針に関するサーバについて質問するメソッドをクライアントに提供する新しい操作を加えました。 これと、クライアントはしっかりとクライアントとサーバの両方で指定された方針を出迎えるセキュリティー対策を合わせることができます。
1.4.2. Procedure and Operation Structure
1.4.2. 手順と操作構造
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.
NFSプロトコルの旧バージョンからの重要な出発はCOMPOUND手順の導入です。 NFSバージョン4プロトコルのために、2つのRPC手順、NULL、およびCOMPOUNDがあります。 COMPOUND手順は操作で定義されます、そして、これらの操作は、より密接に伝統的なNFS手順に対応しています。
Shepler, et al. Standards Track [Page 10] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[10ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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 filesystem 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.
COMPOUND手順の使用で、クライアントは簡単であるか複雑な要求を組み込むことができます。 これらのCOMPOUND要求は論理的なファイルシステム操作に必要であるRPCsの数の減少を考慮します。 例えば、サーバとの前の接触がなければ、クライアントは、1つの要求におけるファイルから独身のCOMPOUND RPCでLOOKUP、オープン、および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.
COMPOUNDに使用されるモデルは非常に簡単です。 操作のどんな論理的なORもANDingもありません。 COMPOUND要求の中で結合された操作はオーダーでサーバによって評価されます。操作がいったん失敗結果を返すと、評価は終わります、そして、すべての評価の操作の結果はクライアントに返されます。
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 filesystem 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プロトコルは、クライアントに"filehandle"でサーバでファイルかディレクトリを参照させ続けています。 COMPOUND手順に、操作の系列の中で1つの操作から別の操作までfilehandleを渡すメソッドがあります。 「現在のfilehandle」と「保存しているfilehandle」の概念があります。 ほとんどの操作が作動するファイルシステム対象物として「現在のfilehandle」を使用します。 「保存しているfilehandle」は一時的なfilehandleストレージとしてある操作のための追加オペランドと同様にCOMPOUND手順の中で使用されます。
1.4.3. Filesystem Model
1.4.3. ファイルシステムモデル
The general filesystem model used for the NFS version 4 protocol is the same as previous versions. The server filesystem 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 filesystem tree provided by the server. The server provides multiple filesystems by gluing them together with pseudo filesystems. These pseudo filesystems provide for potential gaps in the path names between real filesystems.
NFSバージョン4プロトコルは、パス名とfilehandleの間の初期のマッピングに備えるために別々のプロトコルを必要としません。 このマッピングにより古い山のプロトコルを使用することの代わりに、サーバはサーバによって提供されたファイルシステム木の論理的な根か先端を表すROOT filehandleを提供します。サーバは、疑似ファイルシステムと共にそれらをにかわで接ぐことによって、複数のファイルシステムを提供します。これらの疑似ファイルシステムは本当のファイルシステムの間のパス名の潜在的ギャップに備えます。
1.4.3.1. Filehandle Types
1.4.3.1. Filehandleはタイプします。
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 filesystem object to which it referred. For some server implementations, this persistence requirement has been difficult to
NFSプロトコルの旧バージョンでは、サーバによって提供されたfilehandleは、それが参照されたファイルシステム対象物の生涯有効であるか、または永続的になるように保証されました。 いくつかのサーバ実装、要件が難しいこの固執のために
Shepler, et al. Standards Track [Page 11] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[11ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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 filesystem 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バージョン4プロトコルにおいて、この要件は、filehandleの別のタイプを導入することによって伸びやかで、不安定です。 永続的で揮発性のfilehandleタイプと、サーバ実装は操作環境に伴うサーバでファイルシステムの能力を合わせることができます。 クライアントは、サーバによって提供されるfilehandleのタイプに関する知識を持って、それぞれの意味論に対処する用意ができていることができます。
1.4.3.2. Attribute Types
1.4.3.2. 属性タイプ
The NFS version 4 protocol introduces three classes of filesystem 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つのクラスに関するファイルシステムかファイル属性を紹介します。 追加filehandleタイプのように、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 filesystem 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 filesystem attributes that must be provided by the server and must be properly represented by the server. Recommended attributes represent different filesystem 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 filesystem 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.
義務的な属性はサーバで提供しなければならなくて、サーバで適切に表さなければならないファイルかファイルシステム属性の極小集合です。お勧めの属性は異なったファイルシステムタイプと操作環境の代理をします。 お勧めの属性は、より多くの操作環境の、より良い相互運用性と包含を考慮するでしょう。 義務的でお勧めの属性セットは、伝統的なファイルかファイルシステム属性です。 3番目のタイプの属性は命名された属性です。 命名された属性はディレクトリかファイルに関連づけられて、ストリング名によって言及される不透明なバイト・ストリームです。 命名された属性はアプリケーションの特定のデータを通常のファイルかディレクトリに関連づけるメソッドとしてクライアントアプリケーションで使用されることになっています。
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つの重要な追加がAccess Control List(ACL)属性です。 この属性はNFSプロトコルの旧バージョンで使用されるモデルを超えてディレクトリとファイルアクセス制御に備えます。 定義がユーザとグループレベルの仕様のために許容するACLはコントロールにアクセスします。
Shepler, et al. Standards Track [Page 12] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[12ページ]RFC3530NFSバージョン4 プロトコル2003年4月
1.4.3.3. Filesystem Replication and Migration
1.4.3.3. ファイルシステム模写と移行
With the use of a special file attribute, the ability to migrate or replicate server filesystems is enabled within the protocol. The filesystem locations attribute provides a method for the client to probe the server about the location of a filesystem. In the event of a migration of a filesystem, the client will receive an error when operating on the filesystem 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 filesystem. From this information, the client can use its own policies to access the appropriate filesystem location.
特別なファイル属性の使用で、移行するか、またはサーバファイルシステムを模写する能力はプロトコルの中で可能にされます。 ファイルシステム位置の属性はクライアントがファイルシステムの位置に関するサーバを調べるメソッドを提供します。 ファイルできます、そして、ファイルシステムを作動させるとき、ファイルシステムの移行の場合、クライアントは誤りを受けるでしょう、そして、次に、新しさに関する質問はシステム位置をファイルします。 同様のステップは模写に使用されて、クライアントは特定のファイルシステムの複数の利用可能な位置にサーバについて質問できます。 この情報から、クライアントは、適切なファイルシステム位置にアクセスするのにそれ自身の方針を使用できます。
1.4.4. OPEN and CLOSE
1.4.4. 開いて近いです。
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プロトコルはオープンとCLOSE操作を導入します。 オープン操作はファイルルックアップ、作成、およびシェア意味論を結合できる単一のポイントを提供します。 また、CLOSE操作はオープンで蓄積された状態のリリースに備えます。
1.4.5. File locking
1.4.5. ファイルのロック
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コールバックメカニズムは必要ではありません。 Network Lockマネージャ(NLM)、これはNFSファイルのロックプロトコルの旧バージョンからの出発です。 ファイルロックに関連している状態はリースベースのモデルの下でサーバで維持されます。 サーバはNFSクライアントによって保持されたすべての状態とただ一つのリースの期間を定義します。 クライアントが定義された期間中にリースを更新しないなら、クライアントのリースに関連しているすべての状態がサーバによってリリースされるかもしれません。クライアントはRENEW操作の使用で他の操作(主としてREAD)の使用でそれとなくリースを更新するかもしれません。
1.4.6. Client Caching and Delegation
1.4.6. クライアントキャッシュと委譲
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 filesystem 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.
ファイルが開かれるとき、ファイルデータがないかどうか、クライアントはキャッシュの正当性をチェックします。 ファイルが変えられたかどうか決定するために質問をサーバに送ります。 この情報に基づいて、クライアントは、保たれるか、またはリリースされて、ファイルのためのデータキャッシュがそうするべきであるかどうかと決心しています。 また、ファイルが閉じられるとき、どんな変更されたデータもサーバに書かれます。
Shepler, et al. Standards Track [Page 13] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[13ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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への主要な追加はサーバが、ある責任をクライアントへ代表として派遣する能力です。 サーバがファイルのために委譲をクライアントに与えるとき、ある意味論は他のクライアントとのそのファイルの共有に関してクライアントに保証されます。 オープンでは、サーバは、読書をクライアントに提供するか、またはファイルのために委譲を書くかもしれません。 読書委譲をクライアントに与えるなら、他のどんなクライアントにも委譲の持続時間のためのファイルに書く能力がないことを保証します。 クライアントが他のどんなクライアントもファイルへのアクセスを読むか、または書くのをさせないaが保証されると委譲、クライアントに書く当然のことであるなら。
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.
サーバは委譲をリコールできます。別のクライアントがアクセスが与えられた委譲と衝突するような方法でファイルへのアクセスを要求するなら、サーバは、初期のクライアントに通知して、委譲を思い出すことができます。 これは、コールバック経路がサーバとクライアントの間に存在するのを必要とします。 このコールバック経路が存在していないなら、委譲を与えることができません。 委譲の本質は局所的にオープンなどの戦務活動にクライアントを許容するということです、CLOSE、LOCK、LOCKU、READ、サーバとの即座の相互作用のないWRITE。
1.5. General Definitions
1.5. 一般定義
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
filesystem services for a set of applications.
クライアント、「クライアント」はNFSサーバのリソースにアクセスする実体です。 クライアントは直接NFSサーバにアクセスする論理を含むアプリケーションであるかもしれません。 また、クライアントは1セットのアプリケーションのための伝統的なオペレーティングシステムクライアント遠隔ファイルシステムサービスであるかもしれません。
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.
ファイルの場合では、クライアントをロックするのは、1つ以上のアプリケーションを代表して1セットの錠を維持する実体です。 それが管理するそれらの錠において、このクライアントはクラッシュか失敗回復に責任があります。
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.
クライアントについてのユニークな速記言及として使用されるClientidのA64ビットの量はVerifierとIDを供給しました。 サーバはClientidを供給するのに原因となります。
Shepler, et al. Standards Track [Page 14] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[14ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
錠がクライアントに取消不能に与えられるサーバによって定義された時間のAn間隔を賃貸してください。 リースの期間の終わりに、リースが広げられていないなら、錠は取り消されるかもしれません。 リース間隔の後に闘争錠を与えたなら、錠を取り消さなければなりません。
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 share reservations unless
specifically stated otherwise.
別の方法で明確に述べられない場合「錠」が両方の記録的な(バイト範囲)錠について言及して、予約を共有するのに使用される用語をロックしてください。
Server The "Server" is the entity responsible for coordinating
client access to a set of filesystems.
サーバ、「サーバ」は1セットのファイルシステムへのクライアントアクセスを調整するのに原因となる実体です。
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).
安定したStorage NFSバージョン4サーバは記憶媒体(例えば、ディスク、不揮発性のRAM)自体以外のコンポーネントの複数の停電(停電、すなわち、いくつかの停電を間断なくどっと落させるのを含んでいる)、オペレーティングシステムの故障、およびハードウェアの故障からのデータの損失なしで回復できなければなりません。
Some examples of stable storage that are allowable for an
NFS server include:
安定貯蔵のいくつかのNFSサーバにおいて、許容できる例は:
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 128-bit quantity returned by a server that uniquely
defines the open and locking state provided by the server
for a specific open or lock owner for a specific file.
サーバによってそんなに唯一返されたStateidのA128ビットの量は特定のファイルのためにサーバによって特定の戸外かロック所有者に提供された戸外とロック状態を定義します。
Shepler, et al. Standards Track [Page 15] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[15ページ]RFC3530NFSバージョン4 プロトコル2003年4月
Stateids composed of all bits 0 or all bits 1 have special
meaning and are reserved values.
すべてのビット0かすべてのビット1で構成されたStateidsは特別な意味を持って、予約された値です。
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.
64ビットの量がサーバが確認するのに使用できるクライアントでクライアントを生成した検証Aは、前のすべてのロック状態を再開して、失いました。
2. Protocol Data Types
2. プロトコルデータ型
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データ型を当てにします。
2.1. Basic Data Types
2.1. 基本のデータ型
Data Type Definition ____________________________________________________________________ int32_t typedef int int32_t;
データ型定義____________________________________________________________________ int32_t typedef int int32_t。
uint32_t typedef unsigned int uint32_t;
uint32_t typedefの未署名のint uint32_t。
int64_t typedef hyper int64_t;
int64_t typedef超-int64_t。
uint64_t typedef unsigned hyper uint64_t;
uint64_t typedefの未署名の超-uint64_t。
attrlist4 typedef opaque attrlist4<>;
Used for file/directory attributes
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。 変化_インフォメーションの定義では、使用されます。
clientid4 typedef uint64_t clientid4;
Shorthand reference to client identification
clientid4 typedef uint64_t clientid4。 クライアント識別の速記参照
component4 typedef utf8str_cs component4;
Represents path name components
component4 typedef utf8str_Cs component4。 パス名コンポーネントを表します。
count4 typedef uint32_t count4;
Various count parameters (READ, WRITE, COMMIT)
count4 typedef uint32_t count4。 様々なカウントパラメタ(読んでください、そして、書いてください、そして、公約してください)
length4 typedef uint64_t length4;
Describes LOCK lengths
length4 typedef uint64_t length4。 LOCKの長さについて説明します。
Shepler, et al. Standards Track [Page 16] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[16ページ]RFC3530NFSバージョン4 プロトコル2003年4月
linktext4 typedef utf8str_cs linktext4;
Symbolic link contents
linktext4 typedef utf8str_Cs 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 typedefの不透明なnfs_fh4<NFS4_FHSIZE>。 Filehandle定義。 NFS4_FHSIZEは128と定義されます。
nfs_ftype4 enum nfs_ftype4;
Various defined file types
nfs_ftype4 enum nfs_ftype4。 様々な定義されたファイルの種類
nfsstat4 enum nfsstat4;
Return value for operations
nfsstat4 enum nfsstat4。 操作のために値を返してください。
offset4 typedef uint64_t offset4;
Various offset designations (READ, WRITE,
LOCK, COMMIT)
offset4 typedef uint64_t offset4。 様々なオフセット名称(読んでください、そして、書いてください、そして、ロックしてください、そして、公約してください)
pathname4 typedef component4 pathname4<>;
Represents path name for LOOKUP, OPEN and others
pathname4 typedef component4 pathname4<>。 LOOKUP、オープン、および他のもののためにパス名を表します。
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 [RFC2743] for details.
秒_oid4 typedefの不透明な秒_oid4<>。 セキュリティObject Identifier、秒_oid4データ型は本当に不明瞭ではありません。 代わりに、GSS-APIによってmech_タイプ議論にGSS_Init_秒_文脈に使用されるようにASN.1OBJECT IDENTIFIERを含んでいます。 詳細に関して[RFC2743]を見てください。
seqid4 typedef uint32_t seqid4;
Sequence identifier used for file locking
seqid4 typedef uint32_t seqid4。 ファイルのロックに使用される系列識別子
utf8string typedef opaque utf8string<>;
UTF-8 encoding for strings
utf8string typedefの不透明なutf8string<>。 ストリングのためのUTF-8コード化
utf8str_cis typedef opaque utf8str_cis;
Case-insensitive UTF-8 string
utf8str_cis typedefの不透明なutf8str_cis。 大文字と小文字を区別しないUTF-8ストリング
utf8str_cs typedef opaque utf8str_cs;
Case-sensitive UTF-8 string
utf8str_Csのtypedefの不明瞭なutf8str_Cs。 大文字と小文字を区別するUTF-8ストリング
Shepler, et al. Standards Track [Page 17] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[17ページ]RFC3530NFSバージョン4 プロトコル2003年4月
utf8str_mixed typedef opaque utf8str_mixed;
UTF-8 strings with a case sensitive prefix and
a case insensitive suffix.
utf8str_は_が混ぜたtypedefの不透明なutf8strを混ぜました。 大文字と小文字を区別する接頭語と大文字と小文字を区別しない接尾語があるUTF-8ストリング。
verifier4 typedef opaque verifier4[NFS4_VERIFIER_SIZE];
Verifier used for various operations (COMMIT,
CREATE, OPEN, READDIR, SETCLIENTID,
SETCLIENTID_CONFIRM, WRITE) NFS4_VERIFIER_SIZE is
defined as 8.
verifier4 typedefの不透明なverifier4[NFS4_VERIFIER_SIZE]。 様々な操作(COMMIT、CREATE、オープン、READDIR、SETCLIENTID、SETCLIENTID_CONFIRM、WRITE)NFS4_VERIFIER_SIZEに、中古の検証は8と定義されます。
2.2. Structured Data Types
2.2. 構造化されたデータ型
nfstime4
struct nfstime4 {
int64_t seconds;
uint32_t nseconds;
}
nfstime4 struct nfstime4int64_t秒(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構造は真夜中以来の秒と数ナノ秒か1970年1月1日協定世界時の(UTC)0時間の数を与えます。 数秒間のゼロ以上がさばく値は1970年1月1日0時間の後に日付を指示します。 数秒間のゼロ未満がさばく値は1970年1月1日0時間の前に日付を指示します。 どちらの場合も、nseconds分野は最終的な時間表現のために秒分野に加えられることです。 例えば、表されるべき時間が半分であるなら、1970年1月1日0時間、2番目の分野が持っている秒以前、負のもの(-1)の値とnseconds分野には半分2(500000000)番目の値があるでしょう。 nsecondsのための値より多くの999,999,999は無効であると考えられます。
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 filesystem 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
時間_how4
enum time_how4 {
SET_TO_SERVER_TIME4 = 0,
SET_TO_CLIENT_TIME4 = 1
};
enumに_how4を調節してください。SET_TO_SERVER_TIME4は0、SET_TO_CLIENT_TIME4=1と等しいです。
Shepler, et al. Standards Track [Page 18] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[18ページ]RFC3530NFSバージョン4 プロトコル2003年4月
settime4
settime4
union settime4 switch (time_how4 set_it) {
case SET_TO_CLIENT_TIME4:
nfstime4 time;
default:
void;
};
組合settime4スイッチ(時間_how4は_それを設定した)はSET_TO_CLIENT_TIME4:nfstime4時間デフォルト: (空間)をケースに入れます。
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_TO_SERVER_TIME4であるなら、サーバは時間的価値に時間のローカルの表現を使用します。
specdata4
specdata4
struct specdata4 {
uint32_t specdata1; /* major device number */
uint32_t specdata2; /* minor device number */
};
struct specdata4の*uint32_t specdata1; _/*主要な装置番号*/uint32t 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;
};
struct fsid4、uint64_t少佐(uint64_t未成年者)。
This type is the filesystem identifier that is used as a mandatory attribute.
このタイプは義務的な属性として使用されるファイルシステム識別子です。
fs_location4
fs_location4
struct fs_location4 {
utf8str_cis server<>;
pathname4 rootpath;
};
struct fs_location4、utf8str_cisサーバ<>(pathname4 rootpath)。
fs_locations4
fs_locations4
struct fs_locations4 {
pathname4 fs_root;
fs_location4 locations<>;
};
pathname4 fs_が根づかせる; fs_location4位置の<>;struct fs_locations4。
Shepler, et al. Standards Track [Page 19] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[19ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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;
};
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/32)からビットnを含む配列における整数の位置を計算できます、そして、その整数の中のビットは(nモッズ風の32)です。
0 1
+-----------+-----------+-----------+--
| count | 31 .. 0 | 63 .. 32 |
+-----------+-----------+-----------+--
0 1 +-----------+-----------+-----------+-- | カウント| 31 .. 0 | 63 .. 32 | +-----------+-----------+-----------+--
change_info4
変化_info4
struct change_info4 {
bool atomic;
changeid4 before;
changeid4 after;
};
struct変化_info4、bool原子;、changeid4以前; 後のchangeid4;、。
This structure is used with the CREATE, LINK, REMOVE, RENAME operations to let the client know the value of the change attribute for the directory in which the target filesystem object resides.
この構造はCREATEと共に使用されます、LINK、削除、目標ファイルシステム対象物が住んでいるディレクトリのために変化属性の値をクライアントに知らせるRENAME操作。
clientaddr4
clientaddr4
struct clientaddr4 {
/* see struct rpcb in RFC 1833 */
string r_netid<>; /* network id */
string r_addr<>; /* universal address */
};
/*が、RFC1833で**/ストリングr_netid<>; /*ネットワークイド*/ストリングr_addr<>;/普遍的なstruct rpcbが*/を扱うのを見るstruct clientaddr4。
The clientaddr4 structure is used as part of the SETCLIENTID operation to either specify the address of the client that is using a clientid or as part of the callback registration. The
clientaddr4構造はclientidを使用しているクライアントのアドレスを指定するSETCLIENTID操作の一部として、または、コールバック登録の一部として使用されます。 The
Shepler, et al. Standards Track [Page 20] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[20ページ]RFC3530NFSバージョン4 プロトコル2003年4月
r_netid and r_addr fields are specified in [RFC1833], but they are underspecified in [RFC1833] as far as what they should look like for specific protocols.
r_netidとr_addr分野は[RFC1833]で指定されますが、それらはそれらが特定のプロトコルのために似るべきであることと同じくらい遠い[RFC1833]でunderspecifiedされます。
For TCP over IPv4 and for UDP over IPv4, the format of r_addr is the US-ASCII string:
IPv4の上のTCPとIPv4の上のUDPに関しては、r_addrの形式は米国-ASCIIストリングです:
h1.h2.h3.h4.p1.p2
h1.h2.h3.h4.p1.p2
The prefix, "h1.h2.h3.h4", is the standard textual form for representing an IPv4 address, which is always four octets long. Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, the first through fourth octets each converted to ASCII-decimal. Assuming big-endian ordering, p1 and p2 are, respectively, the first and second octets each converted to ASCII-decimal. For example, if a host, in big-endian order, has an address of 0x0A010307 and there is a service listening on, in big endian order, port 0x020F (decimal 527), then the complete universal address is "10.1.3.7.2.15".
接頭語、「h1.h2.h3.h4"、IPv4アドレスを表すための標準の原文のフォームは長いですか?」いつもアドレスは4つの八重奏です。 ビッグエンディアン注文、h1、h2、h3、およびh4が4番目の八重奏でそれぞれ1番目であると仮定するのがそれぞれASCII-小数に変えました。 ビッグエンディアン注文を仮定する、p1、およびp2はそれぞれ1番目です、そして、2番目の八重奏はそれぞれASCII-小数に変えました。 例えば、ポート0x020F(10進527)ホストがビッグエンディアンオーダーに0x0A010307のアドレスを持って、ビッグエンディアンオーダーの進行中のサービス聴取があれば、次に、完全な普遍的なアドレスがそうである、「10.1 .3 .7 .2 0.15インチ」
For TCP over IPv4 the value of r_netid is the string "tcp". For UDP over IPv4 the value of r_netid is the string "udp".
IPv4の上のTCPに関しては、r_netidの値はストリング"tcp"です。 IPv4の上のUDPに関しては、r_netidの値はストリング"udp"です。
For TCP over IPv6 and for UDP over IPv6, the format of r_addr is the US-ASCII string:
IPv6の上のTCPとIPv6の上のUDPに関しては、r_addrの形式は米国-ASCIIストリングです:
x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
x1:x2:x3:x4:x5:x6:x7: x8.p1.p2
The suffix "p1.p2" is the service port, and is computed the same way as with universal addresses for TCP and UDP over IPv4. The prefix, "x1:x2:x3:x4:x5:x6:x7:x8", is the standard textual form for representing an IPv6 address as defined in Section 2.2 of [RFC2373]. Additionally, the two alternative forms specified in Section 2.2 of [RFC2373] are also acceptable.
接尾語、「p1.p2"はサービスポートであり、ずっとIPv4の上のTCPとUDPのための普遍的なアドレスのように同じように計算されます」。 接頭語、「x1:x2:x3:x4:x5:x6:x7: x8"、標準の原文のフォームは[RFC2373]のセクション2.2で定義されるようにIPv6アドレスを表すものですか?」 また、さらに、[RFC2373]のセクション2.2で指定された2つの選択方式も許容しています。
For TCP over IPv6 the value of r_netid is the string "tcp6". For UDP over IPv6 the value of r_netid is the string "udp6".
IPv6の上のTCPに関しては、r_netidの値はストリング"tcp6""です。 IPv6の上のUDPに関しては、r_netidの値はストリング"udp6""です。
cb_client4
cb_client4
struct cb_client4 {
unsigned int cb_program;
clientaddr4 cb_location;
};
未署名のint cb_がプログラムする; clientaddr4 cb_位置;struct cb_client4。
This structure is used by the client to inform the server of its call back address; includes the program number and client address.
この構造は呼び出しの逆アドレスのサーバを知らせるのにクライアントによって使用されます。 プログラム番号とクライアントアドレスを含んでいます。
Shepler, et al. Standards Track [Page 21] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[21ページ]RFC3530NFSバージョン4 プロトコル2003年4月
nfs_client_id4
nfs_クライアント_id4
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
struct nfs_クライアント_id4、verifier4検証(不明瞭なイド<NFS4_OPAQUE_LIMIT>)。
This structure is part of the arguments to the SETCLIENTID operation. NFS4_OPAQUE_LIMIT is defined as 1024.
この構造はSETCLIENTID操作への議論の一部です。 NFS4_OPAQUE_LIMITは1024と定義されます。
open_owner4
_owner4を開いてください。
struct open_owner4 {
clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>;
};
struct戸外_owner4、clientid4 clientid(分っている所有者<NFS4_OPAQUE_LIMIT>)。
This structure is used to identify the owner of open state. NFS4_OPAQUE_LIMIT is defined as 1024.
この構造は、開口状態の所有者を特定するのに使用されます。 NFS4_OPAQUE_LIMITは1024と定義されます。
lock_owner4
錠_owner4
struct lock_owner4 {
clientid4 clientid;
opaque owner<NFS4_OPAQUE_LIMIT>;
};
struct錠_owner4、clientid4 clientid(分っている所有者<NFS4_OPAQUE_LIMIT>)。
This structure is used to identify the owner of file locking state. NFS4_OPAQUE_LIMIT is defined as 1024.
この構造は、ファイルのロック州の所有者を特定するのに使用されます。 NFS4_OPAQUE_LIMITは1024と定義されます。
open_to_lock_owner4
_錠_owner4への開いている_
struct open_to_lock_owner4 {
seqid4 open_seqid;
stateid4 open_stateid;
seqid4 lock_seqid;
lock_owner4 lock_owner;
};
structに_錠_owner4にseqid4の開いている_seqidで; stateid4戸外_stateid; seqid4錠_seqid; 錠_owner4錠_所有者;_を開いてください。
This structure is used for the first LOCK operation done for an open_owner4. It provides both the open_stateid and lock_owner such that the transition is made from a valid open_stateid sequence to that of the new lock_stateid sequence. Using this mechanism avoids the confirmation of the lock_owner/lock_seqid pair since it is tied to established state in the form of the open_stateid/open_seqid.
この構造は戸外_owner4のために行われた最初のLOCK操作に使用されます。 それが戸外_stateidと錠_所有者を両方に提供するので、有効な開いている_stateid系列から新しい錠_stateid系列のものまで変遷をします。 このメカニズムを使用すると、それが開いている__stateid/戸外のseqidの形で設立された状態に結ばれるので、錠_所有者/ロック_seqid組の確認は避けられます。
Shepler, et al. Standards Track [Page 22] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[22ページ]RFC3530NFSバージョン4 プロトコル2003年4月
stateid4
stateid4
struct stateid4 {
uint32_t seqid;
opaque other[12];
};
uint32_tがseqidする; 不透明なもう一方[12];struct stateid4。
This structure is used for the various state sharing mechanisms between the client and server. For the client, this data structure is read-only. The starting value of the seqid field is undefined. The server is required to increment the seqid field monotonically at each transition of the stateid. This is important since the client will inspect the seqid in OPEN stateids to determine the order of OPEN processing done by the server.
この構造はクライアントとサーバの間の様々な州の共有メカニズムに使用されます。クライアントにとって、このデータ構造は書き込み禁止です。 seqid分野の始めの値は未定義です。 サーバが、stateidの各変遷のときにseqid分野を単調に増加するのに必要です。 クライアントがサーバによって行われたオープン処理の順番を決定するためにオープンstateidsでseqidを点検するので、これは重要です。
3. RPC and Security Flavor
3. RPCとセキュリティ風味
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.
NFSバージョン4プロトコルは、[RFC1831]と[RFC1832]で定義されるようにRPCバージョン2を使用するRemote Procedure Call(RPC)アプリケーションと対応するeXternal Data Representation(XDR)です。 NFSバージョン4プロトコルのために、より強いセキュリティを提供するのにメカニズムとして[RFC2203]で定義されるRPCSEC_GSSセキュリティ風味を使用しなければなりません。
3.1. Ports and Transports
3.1. ポートと輸送
Historically, NFS version 2 and version 3 servers have resided on port 2049. The registered port 2049 [RFC3232] 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サーバはポート2049の上にありました。 NFSプロトコルのための2049[RFC3232]の登録されたポートはデフォルト設定であるべきです。 NFSサービスに登録されたポートを使用するのは、NFSクライアントが[RFC1833]で説明されるようにRPCの拘束力があるプロトコルを使用する必要はないことを意味します。 これはトランジットファイアウォールにNFSを許容するでしょう。
Where an NFS version 4 implementation supports operation over the IP network protocol, the supported transports between NFS and IP MUST be among the IETF-approved congestion control transport protocols, which include TCP and SCTP. To enhance the possibilities for interoperability, an NFS version 4 implementation MUST support operation over the TCP transport protocol, at least until such time as a standards track RFC revises this requirement to use a different IETF-approved congestion control transport protocol.
NFSバージョン4実装がIPネットワーク・プロトコルの上の操作をサポートするところに、IETFによって承認された輻輳制御トランスポート・プロトコルの中にNFSとIPの間のサポートしている輸送があるに違いありません。トランスポート・プロトコルはTCPとSCTPを含んでいます。 相互運用性のために可能性を高めるために、NFSバージョン4実装は、TCPトランスポート・プロトコルと、少なくともRFCが改訂する標準化過程のような時間までの操作が異なったIETFによって承認された輻輳制御トランスポート・プロトコルを使用するというこの要件であるとサポートしなければなりません。
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が輸送、クライアント、およびサーバとして使用されるなら、SHOULDはパーシステントコネクションを使用します。 これは、背の低い送られた接続でTCPの輻輳制御の弱化を防いで、WAN環境のためにSYN握手の必要性を排除することによって、性能を向上させるでしょう。
Shepler, et al. Standards Track [Page 23] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[23ページ]RFC3530NFSバージョン4 プロトコル2003年4月
As noted in the Security Considerations section, the authentication model for NFS version 4 has moved from machine-based to principal- based. However, this modification of the authentication model does not imply a technical requirement to move the TCP connection management model from whole machine-based to one based on a per user model. In particular, NFS over TCP client implementations have traditionally multiplexed traffic for multiple users over a common TCP connection between an NFS client and server. This has been true, regardless whether the NFS client is using AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS over TCP server implementations have assumed such a model and thus scale the implementation of TCP connection management in proportion to the number of expected client machines. It is intended that NFS version 4 will not modify this connection management model. NFS version 4 clients that violate this assumption can expect scaling issues on the server and hence reduced service.
Security Considerations部で注意されるように、NFSバージョン4のための認証モデルはベースのマシンベースの主体から移行しました。 しかしながら、認証モデルのこの変更はユーザモデルあたりのaに基づいた1つへのマシンベースの全体からTCP接続マネジメント・モデルを動かすという技術的要求事項を含意しません。 特に、TCPクライアント実装の上のNFSは複数のユーザのためにNFSクライアントとサーバとの一般的なTCP関係の上にトラフィックを伝統的に多重送信しました。NFSクライアントがAUTH_SYS、AUTH_DH、RPCSEC_GSSまたはいかなる他の風味も使用しているか否かに関係なく、これは、本当であって、不注意です。 同様に、TCPサーバ実装の上のNFSはそのようなモデルに就いて、その結果、予想されたクライアントマシンの数に比例してTCP接続管理の実装をスケーリングします。 NFSバージョン4がこの接続マネジメント・モデルを変更しないことを意図します。 この仮定に違反するNFSバージョン4クライアントはサーバに関する問題をスケーリングしている、したがって、減少しているサービスを予想できます。
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].
様々なタイマに関して、クライアントとサーバがそれらのタイマの不注意な同期を避けるべきであることに注意してください。 一般答弁のさらなる議論について、[フロイド]を参照してください。
3.1.1. Client Retransmission Behavior
3.1.1. クライアントRetransmissionの振舞い
When processing a request received over a reliable transport such as TCP, the NFS version 4 server MUST NOT silently drop the request, except if the transport connection has been broken. Given such a contract between NFS version 4 clients and servers, clients MUST NOT retry a request unless one or both of the following are true:
TCPなどの信頼できる輸送の上に受け取られた要求を処理するとき、NFSバージョン4サーバは静かに輸送接続がそうした以外に、知らせられた要求を下げてはいけません。 NFSバージョン4クライアントとサーバとのそのような契約を考えて、以下の1か両方が本当でない場合、クライアントは要求を再試行してはいけません:
o The transport connection has been broken
o 輸送接続は失意でした。
o The procedure being retried is the NULL procedure
o 再試行される手順はNULL手順です。
Since reliable transports, such as TCP, do not always synchronously inform a peer when the other peer has broken the connection (for example, when an NFS server reboots), the NFS version 4 client may want to actively "probe" the connection to see if has been broken. Use of the NULL procedure is one recommended way to do so. So, when a client experiences a remote procedure call timeout (of some arbitrary implementation specific amount), rather than retrying the remote procedure call, it could instead issue a NULL procedure call to the server. If the server has died, the transport connection break will eventually be indicated to the NFS version 4 client. The client can then reconnect, and then retry the original request. If the NULL procedure call gets a response, the connection has not broken. The client can decide to wait longer for the original request's response, or it can break the transport connection and reconnect before re-sending the original request.
TCPなどの信頼できる輸送が、もう片方の同輩がいつ電話を切ったかを(NFSサーバが例えばリブートされるとき)いつも同時同輩に知らせるというわけではないのでNFSバージョン4クライアントが見るために活発に接続を「調べたがっているかもしれない」、壊されました。 NULL手順の使用はそうする1つのお勧めの方法です。 それで、クライアントが遠隔手続き呼び出しを再試行するよりむしろ、遠隔手続き呼び出しタイムアウト(いくらかの任意の実装特定の量の)を経験するとき、それは代わりにNULL手順呼び出しをサーバに発行するかもしれません。サーバが死んだなら、輸送接続中断は結局、NFSバージョン4クライアントに示されるでしょう。 次に、クライアントは、オリジナルの要求を再接続して、次に、再試行できます。 NULL手順呼び出しが返事をもらうなら、接続は中断していません。 クライアントが、オリジナルの要求の応答が、より長い間待つと決めることができるか、それは、輸送接続を調教して、オリジナルの要求を再送する前に、再接続されることができます。
Shepler, et al. Standards Track [Page 24] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[24ページ]RFC3530NFSバージョン4 プロトコル2003年4月
For callbacks from the server to the client, the same rules apply, but the server doing the callback becomes the client, and the client receiving the callback becomes the server.
コールバックをするサーバはクライアントになります、そして、サーバからクライアントまでのコールバックのために、同じ規則は申し込まれますが、コールバックを受けるクライアントはサーバになります。
3.2. Security Flavors
3.2. セキュリティ風味
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 [RFC2743]. This allows for the use of various 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]と共にGSS-API[RFC2743]の機能性を使用するRPCSEC_GSSの追加担保風味を導入しました。 これはRPC層でRPCセキュリティ風味を加える追加実装オーバーヘッドなしで様々なセキュリティー対策の使用を考慮します。 NFSバージョン4において、義務的なセキュリティー対策を可能にするのにRPCSEC_GSSセキュリティ風味を使用しなければなりません。 他の風味の、そして、そのようなAUTH_NONE、AUTH_SYS、および_AUTH DH MAY、また、実装されてください。
3.2.1. Security mechanisms for NFS version 4
3.2.1. NFSバージョン4のためのセキュリティー対策
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の使用は以下の選択を必要とします。 メカニズム、保護の品質、およびサービス(認証、保全、プライバシー)。 セキュリティが3倍になるのに従って、このドキュメントの残りはRPCSEC_GSSセキュリティのこれらの3つのパラメタを参照するでしょう。
3.2.1.1. Kerberos V5 as a security triple
3.2.1.1. セキュリティとしてのケルベロスV5は3倍になります。
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
1 RPCSEC_GSS疑似風味3=メカニズムのOID4=メカニズムのアルゴリズム5=サービスの疑似風味2=名の=番号
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.
1 2 3 4 5 -------------------------------------------------------------------- 390003krb5、1.2 .840 .113554 .1 .2 .2 DES MAC MD5 rpc_gss_は保全のために_なにもに390004krb5i1.2.840.113554.1.2.2DES MAC MD5 rpc_gss_svc_保全390005krb5p1.2.840.113554.1.2.2DES MAC MD5 rpc_gss_svcな_プライバシーをsvcして、プライバシーのために56ビットのDESをsvcします。
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
疑似風味が作成者へのマッピング援助としてここに提示されることに注意してください。 このNFSプロトコルがメソッドを含んでいるので、セキュリティとそれを交渉するのはGSS-APIメカニズムを理解しています。
Shepler, et al. Standards Track [Page 25] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[25ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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バージョン3に必要です。
For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please see [RFC2623].
RPCSEC_GSSとケルベロスV5のNFSの使用の議論に関しては、[RFC2623]を見てください。
Users and implementors are warned that 56 bit DES is no longer considered state of the art in terms of resistance to brute force attacks. Once a revision to [RFC1964] is available that adds support for AES, implementors are urged to incorporate AES into their NFSv4 over Kerberos V5 protocol stacks, and users are similarly urged to migrate to the use of AES.
ユーザと作成者は56ビットのDESがもうブルートフォースアタックへの抵抗で最先端であると考えられないのに注意されます。 [RFC1964]への改正がいったん利用可能になると、それはAESのためにサポートを言い足します、そして、作成者がケルベロスV5プロトコル・スタックの上で彼らのNFSv4にAESを組み入れるよう促されて、ユーザがAESの使用にわたるよう同様に促されます。
3.2.1.2. LIPKEY as a security triple
3.2.1.2. セキュリティとしてのLIPKEYは3倍になります。
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メカニズムは、実装されて、以下のセキュリティ三重を提供しなければなりません。 コラムの定義は前の小区分「セキュリティ三重としてのケルベロス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
1 2 3 4 5 -------------------------------------------------------------------- 390006 _390007の.5の.9の交渉されたrpc_gss lipkey-i1.3.6.1.5_svc_保全390008lipkey-p1.3.6.1.5.5.9が交渉しなかったlipkey1.3.6の.9の交渉されたrpc_gss_svc.1.5.5なにもrpcな_gss_svc_プライバシー
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が、MANDATORY、MANDATORYとしてのプライバシーのための秘密性のための128ビットのcast5CBCとして保全にHMAC-MD5を指定して、最初に、より弱いアルゴリズムの前にHMAC-MD5とcast5CBCを記載しなければならないとさらに指定するので、コラム4で「交渉された」指定は相互運用性を損ないません。 GSS-API文脈作成をイベントでは、SPKM-3同輩は義務的なアルゴリズムをサポートしないで、受け入れるか、またはもう片方の同輩は自由に拒絶できます。
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がアルゴリズムを交渉するので、RPCSEC_GSSによるLIPKEYのGSS_Wrap()とGSS_GetMIC()へのその後の呼び出しは0(ゼロ)の保護価値の品質を使用するでしょう。 説明に関して[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 server. 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を使用します。サーバでいったんユーザ名とパスワードを受け入れると、LIPKEY文脈への呼び出しをSPKM-3文脈に向け直します。 その他の詳細に関して[RFC2847]を見てください。
Shepler, et al. Standards Track [Page 26] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[26ページ]RFC3530NFSバージョン4 プロトコル2003年4月
3.2.1.3. SPKM-3 as a security triple
3.2.1.3. セキュリティとしてのSPKM-3は3倍になります。
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メカニズムは、実装されて、以下のセキュリティ三重を提供しなければなりません。 コラムの定義は前の小区分「セキュリティ三重としてのケルベロス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
1 2 3 4 5 -------------------------------------------------------------------- 390009 _390010spkm3i1.3.6の.1の.3の交渉されたrpc.1.5.5_gss_svc_保全390011spkm3p1.3.6.1.5.5.1.3が交渉しなかったspkm3 1.3.6の.3の交渉されたrpc_gss_svc.1.5.5.1なにもrpcな_gss_svc_プライバシー
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がアルゴリズムを交渉するので、RPCSEC_GSSによるSPKM3のGSS_Wrap()とGSS_GetMIC()へのその後の呼び出しは0(ゼロ)の保護価値の品質を使用するでしょう。 説明に関して[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は、創始者(クライアント)が匿名である、または創始者がそれ自身の証明書を持っている状況を扱うために義務的なセットの三重として指定されます。 創始者が匿名であるなら、目標(サーバ)に送るユーザ名とパスワードがないでしょう。 創始者にそれ自身の証明書があるなら、パスワードを使用するのは余計です。
3.3. Security Negotiation
3.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 filesystem 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. See the section "Security Considerations" for further discussion.
クライアントとサーバとのセキュリティ交渉は、第三者が交渉系列を傍受する可能性を排除するために安全なチャンネルで終わって、クライアントとサーバに必要である、または望まれているより低レベルのセキュリティを選ぶことにさせるのであるに違いありません。 さらなる議論に関して「セキュリティ問題」というセクションを見てください。
Shepler, et al. Standards Track [Page 27] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[27ページ]RFC3530NFSバージョン4 プロトコル2003年4月
3.3.1. SECINFO
3.3.1. SECINFO
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 operation 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操作で、クライアントは、filehandle基礎あたりのaでどんなセキュリティがサーバアクセサリーに3倍使用されるかことであるかと決心できるでしょう。 一般に、サーバかそれともクライアントがいつサーバに方針限界を横断するかとの初期のコミュニケーション以外に、クライアントはSECINFO操作を使用する必要はないでしょう。サーバの方針がしたがって、クライアントが3倍やむを得ず新しいセキュリティを交渉するクライアントの相互作用の間変化するのは、可能です。
3.3.2. Security Error
3.3.2. セキュリティ誤り
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 filesystem 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. See the section for the "SECINFO" operation for further discussion of how the client will respond to the NFS4ERR_WRONGSEC error and use SECINFO.
各NFSバージョン4クライアントとサーバが最小のセキュリティ(すなわち、LIPKEY、SPKM-3、およびRPCSEC_GSSの下のケルベロス-V5)をサポートしなければならないという仮定に基づいて、NFSクライアントは最小量のセキュリティ三重の1つからサーバとのコミュニケーションを始めるでしょう。 サーバとのコミュニケーションの間、クライアントはNFS4ERR_WRONGSECのNFS誤りを受けるかもしれません。 この誤りで、サーバは、サーバのファイルシステムリソースへのアクセスには、現在3倍使用されるセキュリティが適切でないようにクライアントに通知できます。 どんなセキュリティ三重がサーバで利用可能であり、クライアントにとって、適切なものを選ぶかを決定するのにクライアントはその時、責任があります。 クライアントがどうNFS4ERR_WRONGSEC誤りに応じて、SECINFOを使用するかに関するさらなる議論のための"SECINFO"操作に関してセクションを見てください。
3.4. Callback RPC Authentication
3.4. コールバックRPC認証
Except as noted elsewhere in this section, the callback RPC (described later) MUST mutually authenticate the NFS server to the principal that acquired the clientid (also described later), using the security flavor the original SETCLIENTID operation used.
別掲のとおりこのセクションを除いて、コールバックRPC(後で説明される)は互いにclientid(また、後で説明される)を入手した主体にNFSサーバを認証しなければなりません、オリジナルのSETCLIENTID操作が使用したセキュリティ風味を使用して。
For AUTH_NONE, there are no principals, so this is a non-issue.
AUTH_NONEのために、主体が全くないので、これはどうでもいい問題です。
AUTH_SYS has no notions of mutual authentication or a server principal, so the callback from the server simply uses the AUTH_SYS credential that the user used when he 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
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.
ホストとドメインがサーバー・ホストの名前に対応する変数とそれがNetwork情報システムドメインやDNSドメインのように住んでいるディレクトリサービスドメインであるところ。
Shepler, et al. Standards Track [Page 28] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[28ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
LIPKEYがSPKM-3の上で層にされるので、クライアントがSETCLIENTIDにLIPKEYを使用したとしても、サーバがコールバックにLIPKEYではなく、SPKM-3を使用するのは、許されています。
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-APIでGSS_C_NT_HOSTBASED_SERVICE名前タイプでそれ自体を特定しなければなりません。 GSS_C_NT_HOSTBASED_SERVICE名はフォームのものです:
service@hostname
service@hostname
For NFS, the "service" element is
NFSに関しては、「サービス」要素はそうです。
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@hostname を変換するでしょう。ケルベロスV5とLIPKEYに関して、以下のフォームはRECOMMENDEDです:
nfs/hostname
nfs/ホスト名
For Kerberos V5, nfs/hostname would be a server principal in the Kerberos Key Distribution Center database. This is the same principal the client acquired a GSS-API context for when it issued the SETCLIENTID operation, therefore, the realm name for the server principal must be the same for the callback as it was for the SETCLIENTID.
ケルベロスV5に関しては、nfs/ホスト名はケルベロスKey Distributionセンターデータベースのサーバ元本でしょう。 SETCLIENTID操作を発行したとき、これがクライアントがGSS-API文脈を取得した同じ主体である、したがって、コールバックに、サーバ主体のための分野名はそれがSETCLIENTIDのためのものであったのと同じであるに違いありません。
For LIPKEY, this would be the username passed to the target (the NFS version 4 client that receives the callback).
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クライアントがユーザイド/パスワードを使用するので、LIPKEYがコールバックのために働かないかもしれないのが有名であるべきです。 コールバックを受けるNFSクライアントがNFSサーバのユーザ名前/パスワード組を認証できて、ユーザである、NFSサーバが認証している、公開鍵証明書(それが扱うその時)を持っています。
In situations where the 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クライアントがLIPKEYを使用して、SETCLIENTID操作に1ホストあたり1つの元本を使用する状況で、SETCLIENTIDにLIPKEYを使用することの代わりに、互いの認証があるSPKM-3が使用されるのは、RECOMMENDEDです。 事実上、これは、クライアントがNFSサーバの目標に創始者を認証して、特定するのに証明書を使用することを意味します。LIPKEYではなく、SPKM-3を使用するのにおいて、以下の利点があります:
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
o サーバがコールバックをすると、それはSETCLIENTIDで使用される主体に認証されなければなりません。 LIPKEYがSPKM-3の上で層にされるのでLIPKEYが使用されていても、NFSクライアントは、使用するでしょう。
Shepler, et al. Standards Track [Page 29] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[29ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
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が目標のための証明書を超えて追加インフラストラクチャ要件を最小にすることを意図して、期待は創始者のために既存のパスワードインフラストラクチャを利用することができるということです。 いくつかの環境で、1ホストあたり1つのパスワードはまだ存在していません。 証明書がどんな1ホストあたりの主体にも使用されるなら、当時の追加パスワードインフラストラクチャは必要ではありません。
o In cases when a host is both an NFS client and server, it can
share the same per-host certificate.
o ホストであることの場合では、それは、両方がNFSクライアントとサーバであることを共有できます。同じ1ホストあたりの証明書。
4. Filehandles
4. Filehandles
The filehandle in the NFS protocol is a per server unique identifier for a filesystem 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 filesystem object.
ファイルシステム対象物のためのサーバのユニークな識別子あたりNFSプロトコルのfilehandleはaです。 クライアントにとって、filehandleの内容は不明瞭です。 したがって、サーバはファイルシステム対象物の内部の表現にfilehandleを翻訳するのに原因となります。
4.1. Obtaining the First Filehandle
4.1. 最初のFilehandleを入手します。
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 filesystem path name to a filehandle which can then be used by the NFS protocols.
NFSプロトコルの操作は1filehandlesに関して定義されます。 したがって、クライアントは、filehandleがサーバとのコミュニケーションを開始する必要があります。NFSバージョン2プロトコル[RFC1094]とNFSバージョン3プロトコル[RFC1813]で、付属のプロトコルは、この最初のfilehandleを入手するために存在しています。 山のプロトコル(RPCプログラム番号100005)は次にNFSプロトコルで使用できるfilehandleにストリングのベースのファイルシステムパス名を翻訳するメカニズムを提供します。
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 operation 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.
山のプロトコルはセキュリティと使用の領域にファイアウォールで欠乏を持っています。 これは[RFC2054]と[RFC2055]で公共のfilehandleの使用を導入した1つの理由です。 NFSバージョン2と3プロトコルにおけるLOOKUP操作と組み合わせた公共のfilehandleの使用で、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プロトコルはストリングのベースのパス名からfilehandleまでの翻訳に付属のプロトコルを使用しないでしょう。 2の特別なfilehandlesはNFSクライアントに出発点として使用されるでしょう。
Shepler, et al. Standards Track [Page 30] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[30ページ]RFC3530NFSバージョン4 プロトコル2003年4月
4.1.1. Root Filehandle
4.1.1. 根のFilehandle
The first of the special filehandles is the ROOT filehandle. The ROOT filehandle is the "conceptual" root of the filesystem 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 operation. A complete discussion of the server name space is in the section "NFS Server Name Space".
特別なfilehandlesの1番目はROOT filehandleです。 ROOT filehandleはスペースというNFSサーバにおけるファイルシステム名の「概念的な」根です。クライアントは、PUTROOTFH操作を使うことによって、ROOT filehandleから使用するか、または始まります。 PUTROOTFH操作は、「現在」のfilehandleをサーバのファイル木のROOTに設定するようサーバに命令します。 かつて、このPUTROOTFH操作が使用されている、そして、クライアントはLOOKUP操作でサーバのファイル木の全体を横断できます。 スペースというサーバー名の完全な議論が「NFSサーバー名スペース」というセクションにあります。
4.1.2. Public Filehandle
4.1.2. 公共のFilehandle
The second special filehandle is the PUBLIC filehandle. Unlike the ROOT filehandle, the PUBLIC filehandle may be bound or represent an arbitrary filesystem 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 filesystem 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 filesystem object. The client may not make any assumptions about this binding. The client uses the PUBLIC filehandle via the PUTPUBFH operation.
2番目の特別なfilehandleはPUBLIC filehandleです。 ROOT filehandleと異なって、PUBLIC filehandleは制限されているか、またはサーバで任意のファイルシステム対象物を表すかもしれません。サーバはこの結合に原因となります。 多分、PUBLIC filehandleとROOT filehandleは同じファイルシステム対象物について言及します。 しかしながら、PUBLIC filehandleとサーバファイルシステム対象物の結合を定義するのはサーバアドミニストレータのサーバと方針で管理ソフトウェアまで達しています。 クライアントはこの結合に関する少しの仮定もしないかもしれません。 クライアントはPUTPUBFH操作でPUBLIC filehandleを使用します。
4.2. Filehandle Types
4.2. Filehandleはタイプします。
In the NFS version 2 and 3 protocols, there was one type of filehandle with a single set of semantics. This type of filehandle is termed "persistent" in NFS Version 4. The semantics of a persistent filehandle remain the same as before. A new type of filehandle introduced in NFS Version 4 is the "volatile" filehandle, which attempts to accommodate certain server environments.
NFSバージョン2と3プロトコルには、filehandleの1つのタイプが1セットの意味論と共にありました。 filehandleのこのタイプはNFSバージョン4で「永続的な」状態で呼ばれます。 永続的なfilehandleの意味論は従来と同様同じままで残っています。 NFSバージョン4で導入されたfilehandleの新しいタイプは「揮発性」のfilehandleです。(そのfilehandleはあるサーバ環境を収容するのを試みます)。
The volatile filehandle type was introduced to address server functionality or implementation issues which make correct implementation of a persistent filehandle infeasible. Some server environments do not provide a filesystem level invariant that can be used to construct a persistent filehandle. The underlying server filesystem may not provide the invariant or the server's filesystem 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 filesystem reorganization or migration. However, the volatile filehandle increases the implementation burden for the client.
永続的なfilehandleの正しい実装を実行不可能にするサーバの機能性か導入問題を扱うために揮発性のfilehandleタイプを導入しました。 いくつかのサーバ環境は永続的なfilehandleを組み立てるのに使用できるファイルシステムレベル不変式を提供しません。 基本的なサーバファイルシステムが不変式を提供しないかもしれませんか、またはサーバのファイルシステムプログラミングインターフェースは必要な不変式へのアクセスを提供しないかもしれません。 揮発性のfilehandlesは階層的な保管管理、ファイルシステム再編成または移行などのサーバの機能性の実装を緩和するかもしれません。 しかしながら、揮発性のfilehandleはクライアントのために実装負担を増強します。
Shepler, et al. Standards Track [Page 31] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[31ページ]RFC3530NFSバージョン4 プロトコル2003年4月
Since the client will need to handle persistent and volatile filehandles differently, a file attribute is defined which may be used by the client to determine the filehandle types being returned by the server.
クライアントが、永続的で揮発性のfilehandlesを異なって扱う必要があるので、ファイル属性は定義されます(filehandleがサーバで返しながらタイプされることを決定するのにクライアントによって使用されるかもしれません)。
4.2.1. General Properties of a Filehandle
4.2.1. Filehandleの一般特性
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. 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. Further discussion of filehandle and attribute comparison in the context of data caching is presented in the section "Data Caching and File Identity".
filehandleはサーバが個々のファイルを区別するために必要とするすべての情報を含んでいます。 クライアントにとって、filehandleは不透明です。 クライアントは、後の要求における使用のためにfilehandlesを保存して、平等のために同じサーバからバイトごとに比較することによって、2filehandlesを比較できます。 しかしながら、そうでなければ、クライアントはfilehandlesのコンテンツを解釈してはいけません。 同じサーバからの2filehandlesが等しいなら、彼らは同じファイルを示さなければなりません。 サーバSHOULDはfilehandlesとファイルとの1〜1つの通信を維持しようとしますが、これは必要ではありません。 クライアントはfilehandle比較を使用しなければなりませんが、どんな正しい振舞いによっても性能を向上させません。 クライアントが2filehandlesがオブジェクトとそのような場合における同じくらい指示するかどうかは決定できない状況のために準備されるのが必要であり、不正確な振舞いを引き起こすかもしれない無効の仮定をするのを避けるすべて。 データキャッシュの文脈におけるfilehandleと属性比較のさらなる議論は「データキャッシュとファイルのアイデンティティ」というセクションに示されます。
As an example, in the case that two different path names when traversed at the server terminate at the same filesystem 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つの異なったパス名が同じファイルシステム対象物で終わって、サーバSHOULDは同じfilehandleを各経路に返します。 ハードリンクが同じ基本的なファイルオブジェクトについて言及する2つのファイル名と関連データを作成するのに使用されるなら、これは起こることができます。 例えば、経路の/a/b/cと/a/d/cが同じファイルを示すなら、サーバSHOULDは両方のパス名縦断のために同じfilehandleを返します。
4.2.2. Persistent Filehandle
4.2.2. 永続的なFilehandle
A persistent filehandle is defined as having a fixed value for the lifetime of the filesystem object to which it refers. Once the server creates the filehandle for a filesystem 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 filesystem is migrated, the new NFS server must honor the same filehandle as the old NFS server.
永続的なfilehandleはそれが参照されるファイルシステム対象物の生涯のための一定の価値を持っていると定義されます。 サーバがファイルシステム対象物のためにいったんfilehandleを作成すると、サーバはオブジェクトの生涯のためのオブジェクトのために同じfilehandleを受け入れなければなりません。 サーバが再開するか、またはリブートされるなら、NFSサーバはそれとしての値がサーバの前の具体化でした同じfilehandleを尊敬しなければなりません。 同様に、ファイルシステムがそうなら、移行して、新しいNFSサーバは古いNFSサーバとして同じようにfilehandleを尊敬しなければなりません。
The persistent filehandle will be become stale or invalid when the filesystem 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 filesystem containing the object is no longer available. The file
永続的filehandleはそうになるでしょう。ファイルシステム対象物が取り外されたら聞き古した無効になってください。 削除されたオブジェクトについて言及する永続的なfilehandleをサーバに与えるとき、それはNFS4ERR_STALEの誤りを返さなければなりません。 オブジェクトを含むファイルシステムがもう利用可能でないときに、filehandleは聞き古したであるなるかもしれません。 ファイル
Shepler, et al. Standards Track [Page 32] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[32ページ]RFC3530NFSバージョン4 プロトコル2003年4月
system may become unavailable if it exists on removable media and the media is no longer available at the server or the filesystem in whole has been destroyed or the filesystem has simply been removed from the server's name space (i.e., unmounted in a UNIX environment).
リムーバブル・メディアに存在しているなら、システムは入手できなくなるかもしれません、そして、メディアがもうサーバで利用可能でないか、全体のファイルシステムを破壊してあるか、またはファイルシステムはサーバの名前スペース(すなわち、unix環境で取り外される)から単に移されました。
4.2.3. Volatile Filehandle
4.2.3. 揮発性のFilehandle
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.
揮発性のfilehandleは永続的なfilehandleの同じ寿命の特性を共有しません。 サーバは、揮発性のfilehandleが時間内にもう多くの異なったポイントで有効でないことを決定するかもしれません。 サーバが、揮発性のfilehandleが取り除かれたオブジェクトについて言及することを決定的に決定できるなら、サーバはNFS4ERR_STALEをクライアントに返すべきです(永続的なfilehandlesのためにそうであるように)。 サーバがもう揮発性のfilehandleを使用できないことを決定する他のすべての場合では、それは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 filesystem. This attribute is a bitmask with the following values:
義務的な属性、「fh_は_タイプを吐き出すこと」が、サーバがfilehandleのどんなタイプを特定のファイルシステムに提供しているかを決定するのにクライアントによって使用されます。 この属性は以下の値があるビットマスクです:
FH4_PERSISTENT
The value of FH4_PERSISTENT is used to indicate a
persistent filehandle, which is valid until the object is
removed from the filesystem. 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の値は、永続的なfilehandleを示すのに使用されます。(filehandleはファイルシステムからオブジェクトを取り除くまで有効です)。 サーバはこのfilehandleのためにNFS4ERR_FHEXPIREDを返さないでしょう。 FH4_PERSISTENTは以下で指定されたビットのいずれも設定されない値と定義されます。
FH4_VOLATILE_ANY
The filehandle may expire at any time, except as
specifically excluded (i.e., FH4_NO_EXPIRE_WITH_OPEN).
FH4_VOLATILE、_少しも、明確に除かれるのを除いて(すなわち、FH4_いいえ、_EXPIRE_WITH_オープン)、filehandleはいつでも、期限が切れるかもしれません。
FH4_NOEXPIRE_WITH_OPEN
May only be set when FH4_VOLATILE_ANY is set. If this bit
is set, then the meaning of FH4_VOLATILE_ANY is qualified
to exclude any expiration of the filehandle when it is
open.
セットがいつFH4_VOLATILE_であったかときにだけ、FH4_NOEXPIRE_WITH_オープン5月は少しも決められます。 このビットが設定されるなら、何でもそれが開いているとき、FH4_VOLATILE_の意味がfilehandleのどんな満了も除くのに資格があります。
FH4_VOL_MIGRATION
The filehandle will expire as a result of migration. If
FH4_VOL_ANY is set, FH4_VOL_MIGRATION is redundant.
FH4、_filehandleが望んでいるVOL_MIGRATIONは移行の結果、期限が切れます。 FH4_VOL_が少しも用意ができているなら、FH4_VOL_MIGRATIONは余分です。
Shepler, et al. Standards Track [Page 33] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[33ページ]RFC3530NFSバージョン4 プロトコル2003年4月
FH4_VOL_RENAME
The filehandle will expire during rename. This includes a
rename by the requesting client or a rename by any other
client. If FH4_VOL_ANY is set, FH4_VOL_RENAME is
redundant.
FH4、_filehandleが望んでいるVOL_RENAMEが期限が切れる、改名します。 aが要求しているクライアントかaで改名するこのインクルードはいかなる他のクライアントも改名します。 FH4_VOL_が少しも用意ができているなら、FH4_VOL_RENAMEは余分です。
Servers which provide volatile filehandles that may expire while open (i.e., if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should deny a RENAME or REMOVE that would affect an OPEN file of any of the components leading to the OPEN file. In addition, the server should deny all RENAME or REMOVE requests during the grace period upon server restart.
削除、期限が切れるかもしれない揮発性のfilehandlesを提供するサーバが戸外をゆったり過ごします(すなわち、FH4_VOL_MIGRATIONかFH4_VOL_RENAMEが用意ができたか、FH4_VOLATILE_が少しも用意ができて、またはFH4_NOEXPIRE_WITH_オープンがセットしなかったなら)、とRENAMEが否定するはずですか、またはそれはオープンがファイルするオープンファイルにつながるコンポーネントのどれかの感情を否定するでしょう。 さらに、サーバはすべてのRENAMEを否定するべきですか、削除。据置期間の間の要求はサーバで再開します。
Note that the bits FH4_VOL_MIGRATION and FH4_VOL_RENAME allow the client to determine that expiration has occurred whenever a specific event occurs, without an explicit filehandle expiration error from the server. FH4_VOL_ANY does not provide this form of information. In situations where the server will expire many, but not all filehandles upon migration (e.g., all but those that are open), FH4_VOLATILE_ANY (in this case with FH4_NOEXPIRE_WITH_OPEN) is a better choice since the client may not assume that all filehandles will expire when migration occurs, and it is likely that additional expirations will occur (as a result of file CLOSE) that are separated in time from the migration event itself.
特定のイベントがサーバから明白なfilehandle満了誤りなしで起こるときはいつも、ビットのFH4_VOL_MIGRATIONとFH4_VOL_RENAMEが満了が起こったとクライアントを決心させることに注意してください。FH4_VOL_は少しもこのフォームの情報を前提としません。 サーバが_何か移行(例えば、開いているもの以外のすべて)、FH4_VOLATILEまですべてのfilehandlesではなく、多くを吐き出す状況、(この場合、FH4_NOEXPIRE_WITH_オープン) クライアントが移行が起こるとき、すべてのfilehandlesが期限が切れて、追加満期が起こるために(ファイルCLOSEの結果、)望んでいそうであると仮定しないかもしれなくて以来の移行イベントから時間内に切り離されたより良い選択はそれ自体ですか?
4.2.4. One Method of Constructing a Volatile Filehandle
4.2.4. 揮発性のFilehandleを組み立てる1つのメソッド
A volatile filehandle, while opaque to the client could contain:
クライアントへの不透明なものが以下を含むかもしれない揮発性のfilehandle
[volatile bit = 1 | server boot time | slot | generation number]
[揮発性の噛み付いている=1| サーバブート時間|スロット|世代番号]
o slot is an index in the server volatile filehandle table
o スロットはサーバの揮発性のfilehandleテーブルのインデックスです。
o generation number is the generation number for the table
entry/slot
o 世代番号はテーブル項目/スロットへの世代番号です。
When the client presents a volatile filehandle, the server makes the following checks, which assume that the check for the volatile bit has passed. 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.
クライアントが揮発性のfilehandleを寄贈すると、サーバは以下のチェックをします。(チェックは揮発性のビットのためのチェックが終わったと仮定します)。 サーバブート時間が現在のサーバブート時間以下であるなら、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であるなら、それは異なった構造がそれに続いている永続的なfilehandleです。
Shepler, et al. Standards Track [Page 34] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[34ページ]RFC3530NFSバージョン4 プロトコル2003年4月
4.3. Client Recovery from Filehandle Expiration
4.3. Filehandle満了からのクライアント回復
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.
できれば、クライアントSHOULDはNFS4ERR_FHEXPIRED誤りの領収書から回復します。 クライアントは、揮発性のfilehandleの満了から回復するために準備できるように追加責任を引き受けなければなりません。 サーバが永続的なfilehandlesを返すなら、クライアントはこれらの追加ステップを必要としません。
For volatile filehandles, most commonly the client will need to store the component names leading up to and including the filesystem 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 filesystem name space.
揮発性のfilehandlesのために、最も一般的に、クライアントは、問題のファイルシステム対象物を含めて先導というコンポーネント名を保存する必要があるでしょう。 これらの名前で、クライアントは、まだ利用可能な名前スペースでfilehandleを見つけるか、またはサーバのファイルシステム名の根でスペースを始めることによって、回復できるべきです。
If the expired filehandle refers to an object that has been removed from the filesystem, obviously the client will not be able to recover from the expired filehandle.
満期のfilehandleがファイルシステムから取り除かれたオブジェクトについて言及すると、明らかに、クライアントは満期の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
また、満期のfilehandleが改名されたファイルを示すのも、可能です。 ファイルが別のクライアントによって改名されたなら、一方、オリジナルのクライアントが回復できないのは、可能です。しかしながら、クライアント自身がファイルを改名していて、ファイルが開いていて. 缶が処理に基づく新しいパス名を決定するクライアントを回復するのがクライアントができるかもしれないのが可能である、要求を改名してください。 そして、クライアントは新しいパス名に基づく新しいfilehandleを作り直すことができます。 また、クライアントは、以下のように1セットの操作を構成するのに複合操作メカニズムを使用できました。 ルックアップB GETFHにBを改名してください。
Note that the COMPOUND procedure does not provide atomicity. This example only reduces the overhead of recovering from an expired filehandle.
COMPOUND手順が最小単位を提供しないことに注意してください。 この例は満期のfilehandleから回復するオーバーヘッドを下げるだけです。
5. File Attributes
5. ファイル属性
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 is able query what attributes the server supports and construct requests with only those supported attributes (or a subset thereof).
非UNIXプラットホームで伸展性と増強された相互運用性に関する必要条件を満たすために、フレキシブルな態度で属性を扱わなければなりません。 NFSバージョン3fattr3構造はすべてのクライアントとどんなサーバもサポートしないで、心配することができない属性の固定リストを含んでいます。 新たな必要性が起こって、非サポートを示す方法を全く提供しないのに従って、fattr3構造を広げることができません。 NFSバージョン4プロトコル、クライアントと共に、サーバがどんな属性をサポートするか、そして、それらだけがある構造物要求が属性(または、それの部分集合)であるとサポートしたできる質問がいます。
Shepler, et al. Standards Track [Page 35] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[35ページ]RFC3530NFSバージョン4 プロトコル2003年4月
To this end, attributes are 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プロトコルに追加されるかもしれません。 さらなる議論に関して「小さい方のVersioning」というセクションを見てください。
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はオブジェクトにfilehandleを取って、属性階層構造のためにfilehandleを返します。 命名された属性のためのfilehandleは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
ルックアップ"foo"。 ファイルGETATTR attrbits OPENATTRを見上げてください。 アクセスfooは属性LOOKUP"x11icon"と命名されました。 特定の属性READ0、4096を見上げてください。 バイトのストリームを読んでください。
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クライアント実装でというよりむしろアプリケーションで必要であるデータのために意図します。 IETF標準化過程プロセスにそれらを持って来るのによる属性が推薦されるので、NFS作成者が彼らの新しい属性を定義するよう強く奨励されます。
The set of attributes which are classified as mandatory is deliberately small since servers must do whatever it takes to support them. A server should support as many of the recommended attributes as possible but by their definition, the server is not required to support all of them. 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.
サーバがそれらをサポートするのに要することなら何でもしなければならないので、義務的であるとして分類される属性のセットは故意に小さいです。 サーバはできるだけ多くのお勧めの属性をサポートするべきですが、彼らの定義で、サーバは、それらを皆、サポートするのに必要ではありません。 サポートがサーバで提供されないとき、多くのクライアントがともに必要であり、そうでなければ、データが合理的に計算できないなら、属性は義務的であるとクライアントによって考えられます。
Note that the hidden directory returned by OPENATTR is a convenience for protocol processing. The client should not make any assumptions about the server's implementation of named attributes and whether the underlying filesystem at the server has a named attribute directory or not. Therefore, operations such as SETATTR and GETATTR on the named attribute directory are undefined.
OPENATTRによって返された隠されたディレクトリがプロトコル処理のための便利であることに注意してください。 クライアントは命名された属性とサーバにおける基本的なファイルシステムには命名された属性ディレクトリがあるかどうかに関するサーバの実装に関する少しの仮定もするべきではありません。 したがって、命名された属性ディレクトリの上のSETATTRやGETATTRなどの操作は未定義です。
Shepler, et al. Standards Track [Page 36] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[36ページ]RFC3530NFSバージョン4 プロトコル2003年4月
5.1. Mandatory Attributes
5.1. 義務的な属性
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要求に少しセットすることによって返されるように頼むかもしれません、そして、サーバはそれらの値を返さなければなりません。
5.2. Recommended Attributes
5.2. お勧めの属性
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 the client is better positioned decide whether and how to fabricate or construct an attribute or whether to do without the attribute.
これらの属性はNFSバージョン4プロトコルにおけるサポートを保証できるくらいよく理解されています。 しかしながら、それらはすべてのクライアントとサーバでサポートされないかもしれません。 クライアントは、これらの属性のどれかがGETATTR要求に少しセットすることによって返されるように頼むかもしれませんが、サーバがそれらを返さないケースを扱わなければなりません。 クライアントは、サーバがサポートする属性のセットを求めるかもしれなくて、サーバがサポートしない属性を要求するべきではありません。 サーバは、サポートされない属性を求める要求において許容性があって、要求が誤りであると考えるより絶対にむしろそれらを返すべきではありません。 サーバがそれらがゆったりサポートすることができるすべての属性をサポートして、彼らの操作環境でサポートするのが難しい属性はサポートするだけではないと予想されます。 彼らがクライアントに「嘘をつく必要はない」ときはいつも、サーバは属性を提供するべきです。 正確な時間であるべきであるかサーバはサポートするべきではありません。例えば、クライアントにとって快適ですが、これがいつもなるというわけではないクライアントを置くほうがよいファイル変更時間は、どのように属性を構成して作るか、構成するか、そして、または属性なしで構成するかどうか決めます。
5.3. Named Attributes
5.3. 属性と命名されます。
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 filesystem 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操作は仮想の「属性ディレクトリ」のためにfilehandleを返します、そして、スペースという名前のさらなる熟読はこのfilehandleでREADDIRとLOOKUP操作を使用し終わるかもしれません。 次に、命名された属性は、正常なREADとWRITEが調べられるか、または変えられるかもしれません、そして、filehandlesにおけるCREATE操作はREADDIRとLOOKUPから戻りました。 命名された属性に、属性があるかもしれません。
Shepler, et al. Standards Track [Page 37] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[37ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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 filesystem. 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.
サーバが任意の命名された属性をサポートするのは、お勧めです。 クライアントはサーバのファイルシステムにおける属性といういずれも保存する能力に依存するべきではありません。 サーバが命名された属性をサポートするなら、また、それらを扱うことができるクライアントは完全な透明で1つの位置からもう1つの位置までファイルのデータとメタデータをコピーできるべきです。 これは、また、命名された属性名に、定期的なディレクトリエントリーに許容された名前が妥当であることを含意するでしょう。
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問題」というセクションを見てください。
5.4. Classification of Attributes
5.4. 属性の分類
Each of the Mandatory and Recommended attributes can be classified in one of three categories: per server, per filesystem, or per filesystem object. Note that it is possible that some per filesystem attributes may vary within the filesystem. See the "homogeneous" attribute for its definition. Note that the attributes time_access_set and time_modify_set are not listed in this section because they are write-only attributes corresponding to time_access and time_modify, and are used in a special instance of SETATTR.
3つのカテゴリの1つでそれぞれのMandatoryとRecommended属性を分類できます: サーバ、ファイルシステム、またはファイルシステム対象物単位で。 ファイルシステム属性あたりの或るものがファイルシステムの中で異なるのが、可能であることに注意してください。 定義に関して「均質」の属性を見てください。 それらが注意するので__が設定したアクセスと時間_が_セットを変更する属性時がこのセクションで記載されていないことに注意してください、書く、-単に、時間_アクセスと時間_に対応する属性は、SETATTRの特別なインスタンスが、変更して、使用されています。
o The per server attribute is:
o 1サーバあたり、属性は以下の通りです。
lease_time
リース_時間
o The per filesystem attributes are:
o 1ファイルシステムあたり、属性は以下の通りです。
supp_attr, fh_expire_type, link_support, symlink_support,
unique_handles, aclsupport, cansettime, case_insensitive,
case_preserving, chown_restricted, files_avail, files_free,
files_total, fs_locations, homogeneous, maxfilesize, maxname,
maxread, maxwrite, no_trunc, space_avail, space_free, space_total,
time_delta
supp_attr、fh_は_タイプを吐き出します、リンク_サポート、symlink_サポート、ユニークな_ハンドル、aclsupport、cansettime、ケース_神経が鈍いです、ケース_が保存されて、_が制限したchown、ファイル_利益、ファイル_から自由です、ファイル_合計、均質の位置がmaxfilesizeするfs_、maxname、maxread、maxwrite、いいえ_trunc、スペース_利益、自由なスペース_、スペース_合計、時間_デルタ
o The per filesystem object attributes are:
o 1ファイルシステム対象物あたり、属性は以下の通りです。
type, change, size, named_attr, fsid, rdattr_error, filehandle,
ACL, archive, fileid, hidden, maxlink, mimetype, mode, numlinks,
owner, owner_group, rawdev, space_used, system, time_access,
time_backup, time_create, time_metadata, time_modify,
mounted_on_fileid
タイプ、変化、_attrというサイズ、fsid、rdattr_誤り、filehandle、ACL、アーカイブ、fileid、隠されます、maxlink、mimetype、モード、numlinks、所有者_グループの所有者、rawdev、_が使用したスペース、システム、時間_アクセス、時間_バックアップ、_が作成する時間、時間_メタデータ(_が変更する時間)は_fileidに_を取り付けました。
For quota_avail_hard, quota_avail_soft, and quota_used see their definitions below for the appropriate classification.
_が_一生懸命役に立つ割当て_利益_に柔らかい割当てと_が使用した割当てに関しては、適切な分類に関して以下での彼らの定義を見てください。
Shepler, et al. Standards Track [Page 38] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[38ページ]RFC3530NFSバージョン4 プロトコル2003年4月
5.5. Mandatory Attributes - Definitions
5.5. 義務的な属性--定義
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. The
scope of this
attribute applies to
all objects with a
matching fsid.
名前#データ型式アクセス記述___________________________________________________________________ このオブジェクトのためにサポートされるすべての義務的でお勧めの属性を検索する噛み付いているベクトルのsupp_attr0ビットマップREAD。 この属性の範囲は合っているfsidですべてのオブジェクトに適用されます。
type 1 nfs4_ftype READ The type of the object
(file, directory,
symlink, etc.)
オブジェクトのタイプの1nfs4_ftype READをタイプしてください。(ファイル、ディレクトリ、symlinkなど)
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_は期限が切れます。_タイプ2uint32 READ Serverは、クライアントへのfilehandle満了の振舞いを指定するのにこれを使用します。 追加記述に関して「Filehandles」というセクションを見てください。
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_metadata
attribute for this
attribute's value but
only if the filesystem
object can not be
updated more
frequently than the
resolution of
time_metadata.
クライアントがオブジェクトのファイルデータ、ディレクトリコンテンツまたは属性が変更されたかどうか決定するのに使用できるサーバによって作成された3uint64 READ A値を変えてください。 サーバは、この属性の値にもかかわらず、時間_メタデータの解決より頻繁にファイルシステム対象物をアップデートできるだけではないかどうかのためにオブジェクトの時間_メタデータ属性を返すかもしれません。
size 4 uint64 R/W The size of the object
in bytes.
バイトで表現されるオブジェクトのサイズのサイズ4uint64 R/W。
Shepler, et al. Standards Track [Page 39] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[39ページ]RFC3530NFSバージョン4 プロトコル2003年4月
link_support 5 bool READ True, if the object's
filesystem supports
hard links.
オブジェクトのファイルシステムがハードリンクをサポートするなら、_サポート5bool READ Trueをリンクしてください。
symlink_support 6 bool READ True, if the object's
filesystem supports
symbolic links.
symlink_サポート6bool READ True、オブジェクトのものであるなら、ファイルシステムはシンボリックリンクをサポートします。
named_attr 7 bool READ True, if this object
has named attributes.
In other words, object
has a non-empty named
attribute directory.
このオブジェクトが属性を命名したなら、_attr7bool READ Trueと命名されます。 言い換えれば、オブジェクトには、非空の命名された属性ディレクトリがあります。
fsid 8 fsid4 READ Unique filesystem
identifier for the
filesystem holding
this object. fsid
contains major and
minor components each
of which are uint64.
. このオブジェクトfsidを持っているファイルシステムのためのfsid8fsid4 READ Uniqueファイルシステム識別子はそれぞれそれのコンポーネントがuint64である少佐と未成年者を含みます。
unique_handles 9 bool READ True, if two distinct
filehandles guaranteed
to refer to two
different filesystem
objects.
2の異なったfilehandlesが、2個の異なったファイルシステム対象物について言及するのを保証したなら、ユニークな_は9bool READ Trueを扱います。
lease_time 10 nfs_lease4 READ Duration of leases at
server in seconds.
秒にサーバで_リースの時間10nfs_lease4 READ Durationを賃貸してください。
rdattr_error 11 enum READ Error returned from
getattr during
readdir.
rdattr_誤り11enum READ Errorはreaddirの間、getattrから戻りました。
filehandle 19 nfs_fh4 READ The filehandle of this
object (primarily for
readdir requests).
filehandle19は_fh4 READをnfsします。このオブジェクト(主としてreaddir要求のための)のfilehandle。
Shepler, et al. Standards Track [Page 40] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[40ページ]RFC3530NFSバージョン4 プロトコル2003年4月
5.6. Recommended Attributes - Definitions
5.6. お勧めの属性--定義
Name # Data Type Access Description
_____________________________________________________________________
ACL 12 nfsace4<> R/W The access control
list for the object.
名前#データ型アクセス記述_____________________________________________________________________ ACL12nfsace4<>R/W、オブジェクトのためのアクセスコントロールリスト。
aclsupport 13 uint32 READ Indicates what types
of ACLs are
supported on the
current filesystem.
aclsupport13uint32 READ Indicates、ACLsのどんなタイプが現在のファイルシステムでサポートされますか?
archive 14 bool R/W True, if this file
has been archived
since the time of
last modification
(deprecated in favor
of time_backup).
14bool R/W Trueを格納してください、最後の変更(時間_バックアップを支持して推奨しない)の時間以来このファイルが格納されているなら。
cansettime 15 bool READ True, if the server
is able to change
the times for a
filesystem object as
specified in a
SETATTR operation.
cansettime15bool READ TrueサーバがSETATTR操作における指定されるとしてのファイルシステム対象物のために回を変えることができるなら。
case_insensitive 16 bool READ True, if filename
comparisons on this
filesystem are case
insensitive.
このファイルシステムにおけるファイル名比較が大文字と小文字を区別しないなら、_神経の鈍い16bool READ Trueをケースに入れてください。
case_preserving 17 bool READ True, if filename
case on this
filesystem are
preserved.
このファイルシステムのファイル名ケースが保存されるなら17bool READ Trueを保存する_をケースに入れてください。
chown_restricted 18 bool 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
Windows 2000 the
chown_が18bool READ If TRUEを制限して、サーバが訪問者が特権ユーザでないならファイルに関連している所有者かグループのどちらかを変えるというどんな要求も拒絶する、(例えば、UNIX操作環境かWindows2000における「根」
Shepler, et al. Standards Track [Page 41] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[41ページ]RFC3530NFSバージョン4 プロトコル2003年4月
"Take Ownership"
privilege).
「Ownershipを取ってください」という特権)
fileid 20 uint64 READ A number uniquely
identifying the file
within the
filesystem.
ファイルシステムの中で唯一ファイルを特定するfileid20uint64 READ A番号。
files_avail 21 uint64 READ File slots available
to this user on the
filesystem
containing this
object - this should
be the smallest
relevant limit.
このユーザにとって、このオブジェクトを含むファイルシステムで利用可能なファイル_利益21uint64 READ Fileスロット--これは最も小さい関連限界であるべきです。
files_free 22 uint64 READ Free file slots on
the filesystem
containing this
object - this should
be the smallest
relevant limit.
_の有でない22uint64 READ Freeファイルがこのオブジェクトを含むファイルシステムで溝をつけるファイル--これは最も小さい関連限界であるべきです。
files_total 23 uint64 READ Total file slots on
the filesystem
containing this
object.
_の総23uint64 READ Totalファイルがこれを含むファイルシステムで溝をつけるファイルは反対します。
fs_locations 24 fs_locations READ Locations where this
filesystem may be
found. If the
server returns
NFS4ERR_MOVED
as an error, this
attribute MUST be
supported.
このファイルシステムが見つけられるかもしれないfs_位置24のfs_位置のREAD Locations。 サーバが誤りとしてNFS4ERR_MOVEDを返すなら、この属性をサポートしなければなりません。
hidden 25 bool R/W True, if the file is
considered hidden
with respect to the
Windows API.
ファイルがWindows APIに関して隠されると考えられるなら、25bool R/W Trueを隠します。
homogeneous 26 bool READ True, if this
object's filesystem
is homogeneous,
i.e., are per
filesystem
attributes the same
すなわち、このオブジェクトのファイルシステムが均質の均質の26bool READ True、ファイルシステム属性単位で同じようにあります。
Shepler, et al. Standards Track [Page 42] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[42ページ]RFC3530NFSバージョン4 プロトコル2003年4月
for all filesystem's
objects?
すべてのファイルシステムのオブジェクトのために?
maxfilesize 27 uint64 READ Maximum supported
file size for the
filesystem of this
object.
maxfilesizeする、27 uint64 READ Maximumはこのオブジェクトのファイルシステムのためにファイルサイズをサポートしました。
maxlink 28 uint32 READ Maximum number of
links for this
object.
このオブジェクトのためのリンクのmaxlink28uint32 READ Maximum番号。
maxname 29 uint32 READ Maximum filename
size supported for
this object.
このオブジェクトのためにサポートされたmaxname29uint32 READ Maximumファイル名サイズ。
maxread 30 uint64 READ Maximum read size
supported for this
object.
maxread30uint64 READ Maximumはこのオブジェクトのためにサポートされたサイズを読みます。
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.
maxwrite31uint64 READ Maximumはこのオブジェクトのためにサポートされたサイズを書きます。 これはSHOULDを結果と考えます。ファイルが書き込み可能であるなら、サポートされます。 この属性の不足は帯域幅を浪費するか、または受け取らない中で性能最も良いクライアントに通じることができます。
mimetype 32 utf8<> R/W MIME body
type/subtype of this
object.
このオブジェクトのmimetype32utf8<>R/W MIMEボディータイプ/「副-タイプ」。
mode 33 mode4 R/W UNIX-style mode and
permission bits for
this object.
このオブジェクトのためのモード33mode4R/W UNIX-スタイルモードと許可ビット。
no_trunc 34 bool READ True, if a name
longer than name_max
is used, an error be
returned and name is
not truncated.
いいえ_trunc34bool READ True、使用される名前_最大、誤りより長い名前であるなら返されてください。そうすれば、名前は端が欠けていません。
Shepler, et al. Standards Track [Page 43] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[43ページ]RFC3530NFSバージョン4 プロトコル2003年4月
numlinks 35 uint32 READ Number of hard links
to this object.
これへのハードリンクのnumlinks35uint32 READ Numberは反対します。
owner 36 utf8<> R/W The string name of
the owner of this
object.
ストリングがこの所有者について命名する所有者36utf8<>R/Wは反対します。
owner_group 37 utf8<> R/W The string name of
the group ownership
of this object.
ストリングが命名するこのオブジェクトのグループ所有権の所有者_グループ37utf8<>R/W。
quota_avail_hard 38 uint64 READ For definition see
"Quota Attributes"
section below.
割当て_利益_困難な38uint64 READ For定義は下の「割当て属性」セクションを見ます。
quota_avail_soft 39 uint64 READ For definition see
"Quota Attributes"
section below.
割当て_利益_柔らかい39uint64 READ For定義は下の「割当て属性」セクションを見ます。
quota_used 40 uint64 READ For definition see
"Quota Attributes"
section below.
割当て_の中古の40uint64 READ For定義は下の「割当て属性」セクションを見ます。
rawdev 41 specdata4 READ Raw device
identifier. UNIX
device major/minor
node information.
If the value of
type is not
NF4BLK or NF4CHR,
the value return
SHOULD NOT be
considered useful.
rawdev41specdata4 READ Rawデバイス識別子。 UNIXのデバイスの主要であるか小さい方のノード情報。 役に立った状態で考えられて、タイプの値がNF4BLKでなくて、またNF4CHR、または値のリターンSHOULD NOTでもないなら。
space_avail 42 uint64 READ Disk space in bytes
available to this
user on the
filesystem
containing this
object - this should
be the smallest
relevant limit.
このユーザにとって、このオブジェクトを含むファイルシステムで有効なバイトによるスペース_利益42uint64 READ Diskスペース--これは最も小さい関連限界であるべきです。
space_free 43 uint64 READ Free disk space in
bytes on the
filesystem
containing this
object - this should
このオブジェクトを含むファイルシステムのバイトで表現されるスペースの_の自由な43uint64 READ Free椎間腔--これはそうするべきです。
Shepler, et al. Standards Track [Page 44] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[44ページ]RFC3530NFSバージョン4 プロトコル2003年4月
be the smallest
relevant limit.
最も小さい関連限界になってください。
space_total 44 uint64 READ Total disk space in
bytes on the
filesystem
containing this
object.
このオブジェクトを含むファイルシステムのバイトで表現されるスペース_合計44uint64 READ Total椎間腔。
space_used 45 uint64 READ Number of filesystem
bytes allocated to
this object.
スペース_はこのオブジェクトに割り当てられたファイルシステムバイトの45uint64 READ Numberを使用しました。
system 46 bool R/W True, if this file
is a "system" file
with respect to the
Windows API.
システム46bool R/W True、このファイルが「システム」であるなら、Windows APIに関してファイルしてください。
time_access 47 nfstime4 READ The time of last
access to the object
by a read that was
satisfied by the
server.
それが読まれたaによるオブジェクトへの最後のアクセスの時間の時間_アクセス47nfstime4 READはサーバで満足しました。
time_access_set 48 settime4 WRITE Set the time of last
access to the
object. SETATTR
use only.
時間_アクセス_は最後のアクセスの時に48settime4 WRITE Setをオブジェクトに設定しました。 SETATTR使用専用。
time_backup 49 nfstime4 R/W The time of last
backup of the
object.
時間_は最終時間がバックアップをとるオブジェクトの49nfstime4 R/Wのバックアップをとります。
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".
時間_は50nfstime4 R/Wを作成します。オブジェクトの創案の時間。 この属性に、"ctime"か「変化時間」という伝統的なUNIXファイル属性との少しの関係もありません。
time_delta 51 nfstime4 READ Smallest useful
server time
granularity.
時間_デルタ51のnfstime4 READ Smallestの役に立つサーバ時間粒状。
Shepler, et al. Standards Track [Page 45] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[45ページ]RFC3530NFSバージョン4 プロトコル2003年4月
time_metadata 52 nfstime4 READ The time of last
meta-data
modification of the
object.
オブジェクトの最後のメタデータ変更の時間の時間_メタデータ52nfstime4 READ。
time_modify 53 nfstime4 READ The time of last
modification to the
object.
時間_はオブジェクトへの最後の変更の時に53nfstime4 READを変更します。
time_modify_set 54 settime4 WRITE Set the time of last
modification to the
object. SETATTR use
only.
時間_はオブジェクトへの最後の変更の時に_セット54settime4 WRITE Setを変更します。 SETATTR使用専用。
mounted_on_fileid 55 uint64 READ Like fileid, but if
the target
filehandle is the
root of a filesystem
return the fileid of
the underlying
directory.
_fileid55uint64 READ Like fileidにもかかわらず、目標filehandleがファイルシステムの根が基本的なディレクトリのfileidを返すということであるかどうかに関して、_を取り付けました。
5.7. Time Access
5.7. 時間アクセス
As defined above, the time_access attribute represents the time of last access to the object by a read that was satisfied by the server. The notion of what is an "access" depends on server's operating environment and/or the server's filesystem semantics. For example, for servers obeying POSIX semantics, time_access would be updated only by the READLINK, READ, and READDIR operations and not any of the operations that modify the content of the object. Of course, setting the corresponding time_access_set attribute is another way to modify the time_access attribute.
上で定義されるように、時間_アクセス属性はサーバによって満たされた示度でオブジェクトへの最後のアクセスの時間を表します。「アクセス」であることに関する概念はサーバの操作環境、そして/または、サーバのファイルシステム意味論によります。 例えば、POSIX意味論に従うサーバにおいて、単に操作のどれかではなく、オブジェクトの内容を変更するREADLINK、READ、およびREADDIR操作で時間_アクセスをアップデートするでしょう。 もちろん、対応する時間_アクセス_セット属性を設定するのは、時間_アクセス属性を変更する別の方法です。
Whenever the file object resides on a writable filesystem, the server should make best efforts to record time_access into stable storage. However, to mitigate the performance effects of doing so, and most especially whenever the server is satisfying the read of the object's content from its cache, the server MAY cache access time updates and lazily write them to stable storage. It is also acceptable to give administrators of the server the option to disable time_access updates.
ファイルオブジェクトが書き込み可能なファイルシステムに住んでいるときはいつも、サーバは時間_アクセスを安定貯蔵に記録するための最善の努力をするべきです。 しかしながら、特にキャッシュからのオブジェクトの内容の示度を満たしているときはいつも、サーバは、そうするという性能効果、および大部分緩和するために、アクセスタイムアップデートをキャッシュして、怠惰にそれらを安定貯蔵まで書くかもしれません。 また、時間_アクセスがアップデートであると無効にするためにサーバの管理者にオプションを与えるのも許容できます。
Shepler, et al. Standards Track [Page 46] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[46ページ]RFC3530NFSバージョン4 プロトコル2003年4月
5.8. Interpreting owner and owner_group
5.8. 所有者と所有者_グループを解釈します。
The recommended attributes "owner" and "owner_group" (and also users and groups within the "acl" attribute) 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.
お勧めの属性「所有者」と「所有者_グループ」(そして、"acl"属性の中のユーザともグループ)はUTF-8ストリングで表されます。 クライアントかサーバで特定の基本的な実装に結ばれる表現を避けるために、UTF-8ストリングの使用は選ばれました。 [RFC2624]のセクション6.1が追加原理を提供することに注意してください。 クライアントとサーバには所有者と地方のストレージかプレゼンテーションのためにエンドユーザに慣れている所有者_グループの地元の代理があると予想されます。 したがって、ローカルの表現がフォーム" user@dns_domain "の構文に翻訳されるのによるこれらの属性であるときに、予想されて、クライアントとサーバの間にそれを移すということです。 これは同じローカルの表現を使用しないクライアントとサーバのために両方で解釈できる一般的な構文に翻訳する能力を許容するでしょう。
Similarly, security principals may be represented in different ways by different security mechanisms. Servers normally translate these representations into a common format, generally that used by local storage, to serve as a means of identifying the users corresponding to these security principals. When these local identifiers are translated to the form of the owner attribute, associated with files created by such principals they identify, in a common format, the users associated with each corresponding set of security principals.
同様に、セキュリティ主体は異なったセキュリティー対策によって異なった方法で表されるかもしれません。通常、サーバは、これらのセキュリティ主体に対応するユーザを特定する手段として機能するように一般的な形式へのこれらの表現、一般に地方のストレージで使用されるそれを翻訳します。 これらのローカルの識別子が所有者属性のフォームに翻訳されていて、それらが特定するそのような主体によって作成されるファイルに関連しているとき、一般的な形式では、ユーザはそれぞれの対応するセットのセキュリティ主体と交際しました。
The translation used to interpret owner and group strings 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. A server may provide a more general service, not limited by any particular translation (which would only translate a limited set of possible strings) by storing the owner and owner_group attributes in local storage without any translation or it may augment a translation method by storing the entire string for attributes for which no translation is available while using the local representation for those cases in which a translation is available.
所有者とグループストリングを解釈するのに使用される翻訳はプロトコルの一部として指定されません。 これは、様々なソリューションが使われるのを許容します。 例えば、数値の間で user@dns_domain 構文にイドを写像するローカルの変換テーブルは相談されるかもしれません。 また、名前サービスは、翻訳を実行するのに利用されるかもしれません。 サーバがどんな特定の翻訳(限られたセットの可能なストリングを翻訳するだけである)でも所有者と所有者_グループ属性を保存することによって制限されるのではなく、少しも翻訳なしで、より一般的なサービスを地方のストレージに提供するかもしれませんか、またはそれは、翻訳がないのが翻訳が利用可能であるそれらの場合のローカルの表現を使用している間利用可能である属性のために全体のストリングを保存することによって、翻訳メソッドを増大させるかもしれません。
Servers that do not provide support for all possible values of the owner and owner_group attributes, should return an error (NFS4ERR_BADOWNER) when a string is presented that has no translation, as the value to be set for a SETATTR of the owner, owner_group, or acl attributes. When a server does accept an owner or owner_group value as valid on a SETATTR (and similarly for the owner and group strings in an acl), it is promising to return that same string when a corresponding GETATTR is done. Configuration changes and ill-constructed name translations (those that contain
所有者と所有者_グループ属性のすべての可能な値のサポートを提供しないサーバ、ストリングを贈るときの所有者_グループの所有者のSETATTRに設定されるために値として翻訳を全く持っていない誤り(NFS4ERR_BADOWNER)、またはacl属性を返すべきです。 サーバがSETATTRで有効であるとして所有者か所有者_階級値を認める、(同様である、aclの所有者とグループストリング)、対応するGETATTRが完了しているとき、その同じストリングを返すのは有望です。 構成変更とほとんど組み立てられなかった名前翻訳、(それが含むもの
Shepler, et al. Standards Track [Page 47] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[47ページ]RFC3530NFSバージョン4 プロトコル2003年4月
aliasing) may make that promise impossible to honor. Servers should make appropriate efforts to avoid a situation in which these attributes have their values changed when no real change to ownership has occurred.
エイリアシング) 光栄に思うのが不可能であるその約束をするかもしれません。 サーバは、所有権への本当の変化が全く起こっていないときこれらの属性でそれらの値を変える状況を避けるために適切な取り組みを作るべきです。
The "dns_domain" portion of the owner string is meant to be a DNS domain name. For example, user@ietf.org. Servers should accept as valid a set of users for at least one domain. A server may treat other domains as having no valid translations. A more general service is provided when a server is capable of accepting users for multiple domains, or for all domains, subject to security constraints.
所有者ストリングの「dns_ドメイン」一部がDNSドメイン名であることが意味されます。 例えば、 user@ietf.org 。 サーバは同じくらい有効なセットのユーザを少なくとも1つのドメインに受け入れるべきです。 サーバはどんな有効な翻訳も持っていないとして他のドメインを扱うかもしれません。 サーバがセキュリティ規制を条件として複数のドメイン、またはすべてのドメインにユーザを受け入れることができるとき、より一般的なサービスを提供します。
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 at the sender and that the receiver of the attribute should not use that string as a basis for translation into its own internal format. 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.
クライアントかサーバに利用可能などんな翻訳もない場合では、"@"なしで属性値を構成しなければなりません。 したがって、所有者か所有者_グループ属性からの@の不在は、どんな翻訳も送付者で利用可能でなく、属性の受信機がそれ自身の内部の形式への翻訳の基礎としてそのストリングを使用するはずがないのを意味します。 属性値を翻訳できませんが、それはまだ役に立っているかもしれません。 クライアントの場合では、属性ストリングは所有権の地方のディスプレイに使用されるかもしれません。
To provide a greater degree of compatibility with previous versions of NFS (i.e., v2 and v3), which identified users and groups by 32-bit unsigned uid's and gid's, owner and group strings that consist of decimal numeric values with no leading zeros can be given a special interpretation by clients and servers which choose to provide such support. The receiver may treat such a user or group string as representing the same user as would be represented by a v2/v3 uid or gid having the corresponding numeric value. A server is not obligated to accept such a string, but may return an NFS4ERR_BADOWNER instead. To avoid this mechanism being used to subvert user and group translation, so that a client might pass all of the owners and groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER error when there is a valid translation for the user or owner designated in this way. In that case, the client must use the appropriate name@domain string and not the special form for compatibility.
先行ゼロなしで10進数値から成る32ビットのuidの未署名のものとヒツジ暈倒病のもの、所有者、およびグループストリングでユーザとグループを特定したNFS(すなわち、v2とv3)の旧バージョンをより大きい度合いの互換性に提供するようにそのようなサポートを提供するのを選ぶクライアントとサーバによる特別な解釈をすることができます。 受信機は対応する数値を持っているv2/v3 uidかヒツジ暈倒病によって表されるような同じユーザの代理をするとしてのユーザかグループストリングを扱うかもしれません。 サーバは、そのようなストリングを受け入れるのは義務付けられませんが、代わりにNFS4ERR_BADOWNERを返すかもしれません。 クライアントが通るかもしれなくて、ユーザとグループ翻訳を打倒するのに使用されるこのメカニズムを避けるために、数値の所有者とグループのすべてが形成されます、SHOULDがこのように任命されたユーザか所有者にとって、有効な翻訳があるときのNFS4ERR_BADOWNER誤りを返すサーバ。 その場合、クライアントは互換性に特別なフォームではなく、適切な name@domain ストリングを使用しなければなりません。
The owner string "nobody" may be used to designate an anonymous user, which will be associated with a file created by a security principal that cannot be mapped through normal means to the owner attribute.
所有者ストリング「だれも」は、匿名のユーザを任命するのに使用されないかもしれません。(そのユーザは、正常な手段で所有者属性に写像できないセキュリティ元本によって作成されるファイルに関連するでしょう)。
Shepler, et al. Standards Track [Page 48] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[48ページ]RFC3530NFSバージョン4 プロトコル2003年4月
5.9. Character Case Attributes
5.9. キャラクターケース属性
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".
属性、キャラクタ(どのUTF-8エンコード)が持っている各UCS-4を保存するケース_神経の鈍い、そして、ケース_に関して、そうするかもしれない「長い描写的である名前」[RFC1345]は「首都」という言葉を含んでいたか、「小さい。」 SMALLかCAPITALの存在はNFSサーバに大文字と小文字を区別しない比較、およびケースを保存しないストレージのための駆動マッピングを明白で効率的なテーブルに実装させます。 一般的なキャラクタ取り扱いと国際化問題に関しては、「国際化」というセクションを見てください。
5.10. Quota Attributes
5.10. 割当て属性
For the attributes related to filesystem 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_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_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.
割当て_はことによると多くのこのファイルかディレクトリによって使用されるディスクスペースの量と他の同様のファイルかディレクトリを表すバイトで値を使用して、「同様」のセットが少なくとも割り当てがどんなファイルやディレクトリにも区切る評価基準を満たすところでセットでは、「割当て_は_一生懸命役に立つこと」が減少しているでしょう。セットにおけるあらゆる他のファイルかディレクトリについて。
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".
サーバは、それらのセットのどれかを選ぶのにおいて自由ですが、そう反復可能方法でするべきです。 規則が構成されるかもしれない、-、ファイルシステム、「最もわずかな割当てがあるセットを選んでください」はそうです。
Shepler, et al. Standards Track [Page 49] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[49ページ]RFC3530NFSバージョン4 プロトコル2003年4月
5.11. Access Control Lists
5.11. アクセスコントロールリスト
The NFS version 4 ACL attribute is an array of access control entries (ACE). Although, the client can read and write the ACL attribute, the NFSv4 model is the server does all access control based on the server's interpretation of the ACL. If at any point the client wants to check access without issuing an operation that modifies or reads data or metadata, the client can use the OPEN and ACCESS operations to do so. There are various access control entry types, as defined in the Section "ACE type". The server is able to communicate which ACE types are supported by returning the appropriate value within the aclsupport attribute. Each ACE covers one or more operations on a file or directory as described in the Section "ACE Access Mask". It may also contain one or more flags that modify the semantics of the ACE as defined in the Section "ACE flag".
NFSバージョン4ACL属性はアクセス制御エントリー(ACE)の配列です。 クライアントはACL属性を読み書きできて、NFSv4モデルはサーバがサーバのACLの解釈に基づくすべてのアクセス制御をするということです。 クライアントが任意な点でデータかメタデータを変更するか、または読む操作を発行しないでアクセスをチェックしたいなら、クライアントは、そうするのにオープンとACCESS操作を使用できます。 様々なアクセス制御エントリータイプが「ACEタイプ」というセクションで定義されるようにあります。 サーバは、どのACEタイプがaclsupport属性の中で適切な値を返すことによってサポートされるかを伝えることができます。 各ACEはセクション「ACEアクセスマスク」で説明されるようにファイルかディレクトリにおける1つ以上の操作をカバーしています。 また、それは「ACE旗」というセクションで定義されるようにACEの意味論を変更する複数の旗を含むかもしれません。
The NFS ACE attribute is defined as follows:
NFS ACE属性は以下の通り定義されます:
typedef uint32_t acetype4;
typedef uint32_t aceflag4;
typedef uint32_t acemask4;
typedef uint32_t acetype4。 typedef uint32_t aceflag4。 typedef uint32_t acemask4。
struct nfsace4 {
acetype4 type;
aceflag4 flag;
acemask4 access_mask;
utf8str_mixed who;
};
struct nfsace4、aceflag4旗; acemask4アクセス_マスク; utf8str_がだれを混ぜたかというacetype4タイプ。
To determine if a 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 access still has unALLOWED bits in common with the "access_mask" of the ACE, the request is denied. However, unlike the ALLOWED and DENIED ACE types, the ALARM and AUDIT ACE types do not affect a requester's access, and instead are for triggering events as a result of a requester's access attempt.
要求が成功するかどうか決定するために、それぞれのnfsace4エントリーはサーバによって整然とした状態で処理されます。リクエスタに合っている「人」を持っているACEだけが考えられます。 各ACEは優にリクエスタのアクセスのビットがALLOWEDになるまで処理されます。 しばらく(以下を見る)がいったんACCESS_ALLOWED_ACEによるALLOWEDになると、それはもう後のACEの処理で考えられません。 ACCESS_DENIED_ACEがリクエスタのアクセスがまだACEの「アクセス_マスク」と共用してunALLOWEDビットを持っているところで遭遇するなら、要求は否定されます。 しかしながら、ALARMとAUDIT ACEタイプは、ALLOWEDとDENIED ACEタイプと異なって、リクエスタのアクセスに影響しないで、代わりにリクエスタのアクセス試みの結果、引き金となる出来事に賛成します。
Therefore, all AUDIT and ALARM ACEs are processed until end of the ACL. When the ACL is fully processed, if there are bits in requester's mask that have not been considered whether the server allows or denies the access is undefined. If there is a mode attribute on the file, then this cannot happen, since the mode's MODE4_*OTH bits will map to EVERYONE@ ACEs that unambiguously specify the requester's access.
したがって、すべてのAUDITとALARM ACEはACLの端まで処理されます。 ACLが完全に処理されるとき、リクエスタのマスクの考えられていないビットがあれば、サーバがアクセスを許容するか、または拒絶するかが、未定義です。 ファイルの上にモード属性があれば、これは起こることができません、モードのMODE4_*OTHビットが@明白にリクエスタのアクセサリーを指定するACEをEVERYONEに写像するので
Shepler, et al. Standards Track [Page 50] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[50ページ]RFC3530NFSバージョン4 プロトコル2003年4月
The NFS version 4 ACL model is quite rich. Some server platforms may provide access control functionality that goes beyond the UNIX-style mode attribute, but which is not as rich as the NFS ACL model. So that users can take advantage of this more limited functionality, the server may indicate that it supports ACLs as long as it follows the guidelines for mapping between its ACL model and the NFS version 4 ACL model.
NFSバージョン4ACLモデルはかなり金持ちです。 いくつかのサーバプラットホームが越えていますが、UNIX-スタイルモード属性がNFS ACLがモデル化するほど豊かでないアクセス制御の機能性を提供するかもしれません。 ユーザがこのより限られた機能性を利用できるように、サーバは、ACLモデルとNFSの間でバージョン4ACLモデルを写像するためのガイドラインに従う限り、ACLsをサポートするのを示すかもしれません。
The situation is complicated by the fact that a server may have multiple modules that enforce ACLs. For example, the enforcement for NFS version 4 access may be different from the enforcement for local access, and both may be different from the enforcement for access through other protocols such as SMB. So it may be useful for a server to accept an ACL even if not all of its modules are able to support it.
サーバにはACLsを実施する複数のモジュールがあるかもしれないという事実によって状況は複雑にされます。 例えば、NFSバージョン4アクセスのための実施は地方のアクセスのための実施と異なるかもしれません、そして、両方がアクセスのための実施からSMBなどの他のプロトコルまで異なっているかもしれません。 それで、モジュールのすべてがそれをサポートすることができるというわけではなくても、サーバがACLを受け入れるのは、役に立つかもしれません。
The guiding principle in all cases is that the server must not accept ACLs that appear to make the file more secure than it really is.
すべての場合における指導原理はサーバがファイルを本当より安全にするように見えるACLsを受け入れてはいけないということです。
5.11.1. ACE type
5.11.1. ACEタイプ
Type Description
_____________________________________________________
ALLOW Explicitly grants the access defined in
acemask4 to the file or directory.
型記述_____________________________________________________ ALLOW Explicitlyはacemask4でファイルかディレクトリと定義されたアクセスを承諾します。
DENY Explicitly denies the access defined in
acemask4 to the file or directory.
DENY Explicitlyはacemask4でファイルかディレクトリと定義されたアクセスを拒絶します。
AUDIT LOG (system dependent) any access
attempt to a file or directory which
uses any of the access methods specified
in acemask4.
AUDIT LOGの(システムに依存する)のいずれも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.
どんなアクセス試みもアクセス法のためのファイルかディレクトリにするとき、ALARM Generate aシステムALARM(システムに依存する)はacemask4で指定しました。
A server need not support all of the above ACE types. The bitmask constants used to represent the above definitions within the
サーバは上のACEタイプのすべてをサポートする必要はありません。 ビットマスク定数は以前はよく上の定義を表していました。
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;
const ACL4_SUPPORT_ALLOW_ACL=0x00000001。 const ACL4_SUPPORT_DENY_ACL=0x00000002。 const ACL4_SUPPORT_AUDIT_ACL=0x00000004。 const ACL4_SUPPORT_ALARM_ACL=0x00000008。
Shepler, et al. Standards Track [Page 51] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[51ページ]RFC3530NFSバージョン4 プロトコル2003年4月
The semantics of the "type" field follow the descriptions provided above.
「タイプ」分野の意味論は上に提供された記述に続きます。
The constants used for the type field (acetype4) are as follows:
タイプ分野(acetype4)に使用される定数は以下の通りです:
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;
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。
Clients should not attempt to set an ACE unless the server claims support for that ACE type. If the server receives a request to set an ACE that it cannot store, it MUST reject the request with NFS4ERR_ATTRNOTSUPP. If the server receives a request to set an ACE that it can store but cannot enforce, the server SHOULD reject the request with NFS4ERR_ATTRNOTSUPP.
サーバクレームが、それのためにACEがタイプであるとサポートしないなら、クライアントは、ACEを設定するのを試みるべきではありません。 サーバがそれが保存できないACEを設定するという要求を受け取るなら、それはNFS4ERR_ATTRNOTSUPPとの要求を拒絶しなければなりません。 サーバが保存できますが、それが実施できないACEを設定するという要求を受け取るなら、サーバSHOULDはNFS4ERR_ATTRNOTSUPPとの要求を拒絶します。
Example: suppose a server can enforce NFS ACLs for NFS access but cannot enforce ACLs for local access. If arbitrary processes can run on the server, then the server SHOULD NOT indicate ACL support. On the other hand, if only trusted administrative programs run locally, then the server may indicate ACL support.
例: サーバがNFSアクセスのためにNFS ACLsを実施できますが、地方のアクセサリーのためにACLsは実施できないと仮定してください。 任意のプロセスがサーバで動くことができるなら、サーバSHOULD NOTはACLサポートを示します。 他方では、信じられた管理プログラムだけが局所的に動くなら、サーバはACLサポートを示すかもしれません。
5.11.2. ACE Access Mask
5.11.2. ACEアクセスマスク
The access_mask field contains values based on the following:
アクセス_マスク分野は以下に基づく値を含んでいます:
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
アクセス記述_______________________________________________________________ ディレクトリREAD_NAMED_ATTRS Permissionにサブディレクトリを作成するためにファイルADD_SUBDIRECTORY Permissionにデータを追加するためにディレクトリAPPEND_DATA Permissionに新しいファイルを加えるようにファイルのデータADD_FILE Permissionを変更するためにディレクトリWRITE_DATA Permissionのコンテンツを記載するためにファイルLIST_ディレクトリPermissionに関するデータを読むREAD_DATA Permission; ディレクトリREAD_ATTRIBUTESの中でファイルかディレクトリを削除するためにファイルDELETE_CHILD Permissionを実行するためにファイルEXECUTE Permissionの命名された属性を書くためにファイルWRITE_NAMED_ATTRS Permissionの命名された属性を読むために、ファイルWRITE_ATTRIBUTES Permissionの基本的な属性(非acls)を読み込む能力は基本的な属性を変えます。
Shepler, et al. Standards Track [Page 52] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[52ページ]RFC3530NFSバージョン4 プロトコル2003年4月
(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 Permissionを変えるWrite ACL WRITE_OWNER PermissionへのRead ACL WRITE_ACL PermissionへのDeleteファイルREAD_ACL PermissionへのファイルDELETE Permissionの(非acls)は、読んで、書きます。
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;
const ACE4_READ_DATA=0x00000001。 const ACE4_LIST_ディレクトリ=0×00000001。 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。
Server implementations need not provide the granularity of control that is implied by this list of masks. For example, POSIX-based systems might not distinguish APPEND_DATA (the ability to append to a file) from WRITE_DATA (the ability to modify existing contents); both masks would be tied to a single "write" permission. When such a server returns attributes to the client, it would show both APPEND_DATA and WRITE_DATA if and only if the write permission is enabled.
サーバ実装はマスクのこのリストによって含意されるコントロールの粒状を提供する必要はありません。 例えば、POSIXベースのシステムはWRITE_DATA(既存のコンテンツを変更する能力)とAPPEND_DATA(ファイルに追加する能力)を区別しないかもしれません。 両方のマスクは「書いてください」というただ一つの許可に接続されるでしょう。 許可を書いてください。そのようなサーバが属性をクライアントに返すとき、APPEND_DATAとWRITE_DATAの両方を見せているだろう、唯一、可能にされます。
If a server receives a SETATTR request that it cannot accurately implement, it should error in the direction of more restricted access. For example, suppose a server cannot distinguish overwriting data from appending new data, as described in the previous paragraph. If a client submits an ACE where APPEND_DATA is set but WRITE_DATA is not (or vice versa), the server should reject the request with NFS4ERR_ATTRNOTSUPP. Nonetheless, if the ACE has type DENY, the server may silently turn on the other bit, so that both APPEND_DATA and WRITE_DATA are denied.
サーバがそれが正確に実装することができないSETATTR要求を受け取るなら、受け取るべきである、以上の向きに誤りはアクセサリーを制限しました。 例えば、サーバが、前のパラグラフで説明されるように新しいデータを追加するのとデータを上書きするのを区別できないと仮定してください。 クライアントがAPPEND_DATAが用意ができていますが、WRITE_DATAが用意ができているというわけではないACE(逆もまた同様である)を提出するなら、サーバはNFS4ERR_ATTRNOTSUPPとの要求を拒絶するべきです。 それにもかかわらず、ACEにタイプDENYがあるなら、サーバは静かにもう片方のビットをつけるかもしれません、APPEND_DATAとWRITE_DATAの両方が否定されるように。
Shepler, et al. Standards Track [Page 53] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[53ページ]RFC3530NFSバージョン4 プロトコル2003年4月
5.11.3. ACE flag
5.11.3. ACE旗
The "flag" field contains values based on the following descriptions.
「旗」分野は以下の記述に基づく値を含んでいます。
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.
ACE4_FILE_INHERIT_ACE Canは、ディレクトリに置かれて、このACEが作成されたそれぞれの新しい非ディレクトリファイルに追加されるべきであるのを示します。
ACE4_DIRECTORY_INHERIT_ACE
Can be placed on a directory and indicates that this ACE should be
added to each new directory created.
ACE4_ディレクトリ_INHERIT_ACE Canは、ディレクトリに置かれて、この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_INHERIT、_唯一の_ACE Canはディレクトリに置かれますが、ディレクトリに適用しません、指定されるとしての上の2個の旗による新たに作成されたファイル/ディレクトリだけに。
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.
_いいえ、_PROPAGATE_INHERIT_ACE Can。ACE4、ディレクトリに置かれます。 新しいディレクトリが作成されて、ACEがACL4_ディレクトリ_INHERIT_ACEであるとマークされる親ディレクトリの上に存在するとき、通常、2つのACEが新しいディレクトリに関して課されます。 ディレクトリのためのもの自体と新たに作成されたディレクトリのための相続可能なACEであるもの。 この旗は、作成されたディレクトリに関するサブディレクトリで相続可能な新たに作成されたディレクトリに関してACEを課さないようにサーバに言います。
ACE4_SUCCESSFUL_ACCESS_ACE_FLAG
ACE4の_のうまくいっている_アクセス_ACE_旗
ACL4_FAILED_ACCESS_ACE_FLAG
The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and
ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits relate only to
ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE
(ALARM) ACE types. If during the processing of the file's ACL,
the server encounters an AUDIT or ALARM ACE that matches the
principal attempting the OPEN, the server notes that fact, and the
presence, if any, of the SUCCESS and FAILED flags encountered in
the AUDIT or ALARM ACE. Once the server completes the ACL
processing, and the share reservation processing, and the OPEN
call, it then notes if the OPEN succeeded or failed. If the OPEN
succeeded, and if the SUCCESS flag was set for a matching AUDIT or
ALARM, then the appropriate AUDIT or ALARM event occurs. If the
OPEN failed, and if the FAILED flag was set for the matching AUDIT
or ALARM, then the appropriate AUDIT or ALARM event occurs.
Clearly either or both of the SUCCESS or FAILED can be set, but if
neither is set, the AUDIT or ALARM ACE is not useful.
FLAG(SUCCESS)、_FLAG(FAILED)フラグビットが_ACE4_SYSTEM_AUDIT_ACE TYPE(AUDIT)だけに関係づけるACE4_FAILED_ACCESS_ACE、およびACE4_SYSTEM_ALARM_ACE_TYPE(ALARM)ACEがタイプする_ACL4_FAILED_ACCESS_ACE FLAG ACE4_SUCCESSFUL_ACCESS_ACE_。 サーバがファイルのACLの処理の間、オープンを試みる校長に合っているAUDITかALARM ACEに遭遇するなら、サーバは旗がAUDITかALARM ACEで遭遇したSUCCESSとFAILEDについてもしあればその事実、および存在に注意します。 一度、サーバはACL処理、シェア予約処理、およびオープン呼び出しを完了して、次に、それは、オープンが成功したか、または失敗したかに注意します。 オープンが成功して、SUCCESS旗が合っているAUDITかALARMに設定されたなら、適切なAUDITかALARMイベントが現れます。 オープンが失敗して、FAILED旗が合っているAUDITかALARMに設定されたなら、適切なAUDITかALARMイベントが現れます。 明確に、SUCCESSかFAILEDのどちらかか両方を設定できますが、どちらも設定されないなら、AUDITかALARM ACEが役に立ちません。
Shepler, et al. Standards Track [Page 54] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[54ページ]RFC3530NFSバージョン4 プロトコル2003年4月
The previously described processing applies to that of the ACCESS
operation as well. The difference being that "success" or
"failure" does not mean whether ACCESS returns NFS4_OK or not.
Success means whether ACCESS returns all requested and supported
bits. Failure means whether ACCESS failed to return a bit that
was requested and supported.
また、以前に説明された処理はACCESS操作のものに適用されます。 その「成功」か「失敗」である違いは、ACCESSがNFS4_OKを返すかどうかを意味しません。 成功は、ACCESSがビットであると要求されていて、サポートされたすべてを返すかどうかを意味します。 失敗は、ACCESSがそれを少し返さなかったかどうかが要求されて、サポートされたことを意味します。
ACE4_IDENTIFIER_GROUP
Indicates that the "who" refers to a GROUP as defined under UNIX.
ACE4_IDENTIFIER_GROUP Indicates、「だれ」はUNIXの下で定義されるa GROUPを示すか。
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;
const ACE4_FILE_INHERIT_ACE=0×00000001。 const ACE4_ディレクトリ_INHERIT_ACE=0×00000002。 const ACE4_いいえ、_PROPAGATE_INHERIT_ACE=0×00000004。 const ACE4_INHERIT、__ACEだけ=0×00000008。 const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG=0x00000010。 const ACE4_FAILED_ACCESS_ACE_FLAG=0x00000020。 const ACE4_IDENTIFIER_GROUP=0x00000040。
A server need not support any of these flags. If the server supports flags that are similar to, but not exactly the same as, these flags, the implementation may define a mapping between the protocol-defined flags and the implementation-defined flags. Again, the guiding principle is that the file not appear to be more secure than it really is.
サーバはこれらの旗のいずれも支える必要はありません。 サーバがプロトコルで定義された旗と実装で定義された旗の間で同様の、しかし、まさにこれらの旗であり、実装がマッピングを定義するかもしれないのと同じでない旗を支えるなら。 一方、指導原理はファイルが本当より安全であるように見えないということです。
For example, suppose a client tries to set an ACE with ACE4_FILE_INHERIT_ACE set but not ACE4_DIRECTORY_INHERIT_ACE. If the server does not support any form of ACL inheritance, the server should reject the request with NFS4ERR_ATTRNOTSUPP. If the server supports a single "inherit ACE" flag that applies to both files and directories, the server may reject the request (i.e., requiring the client to set both the file and directory inheritance flags). The server may also accept the request and silently turn on the ACE4_DIRECTORY_INHERIT_ACE flag.
例えば、クライアントがACE4_ディレクトリ_INHERIT_ACEではなく、INHERIT_ACEが設定したACE4_FILE_でACEを設定しようとすると仮定してください。 サーバがどんなフォームのACL継承もサポートしないなら、サーバはNFS4ERR_ATTRNOTSUPPとの要求を拒絶するべきです。 サーバが「ACEを引き継いでください」というファイルとディレクトリの両方に適用されるただ一つの旗を支えるなら、サーバは要求(すなわち、クライアントがファイルとディレクトリ継承旗の両方を設定するのが必要である)を拒絶するかもしれません。 サーバは、また、要請を受け入れて、静かにACE4_ディレクトリ_INHERIT_ACE旗をつけるかもしれません。
5.11.4. ACE who
5.11.4. ACE、だれ
There are several special identifiers ("who") which need to be
understood universally, rather than in the context of a particular
DNS domain. 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, even if none of the access methods
on the server understands the identifiers.
一般に、むしろ理解される必要があるいくつかの特別な識別子(「だれ」)が特定のDNSドメインの文脈よりあるか。 NFSクライアントがサーバにアクセスするとき、これらの識別子のいくつかを理解できませんが、地方のプロセスがファイルにアクセスするときには意味を持ってください。 これらの許容を表示して、変更する能力はNFSの上で受入れられます、サーバのアクセス法のいずれも識別子を理解していなくても。
Shepler, et al. Standards Track [Page 55] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[55ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
だれ、記述_______________________________________________________________ ファイルの所有者の"OWNER"。 「GROUP、」 グループはファイルと交際しました。 「EVERYONE、」 世界。 会話型端末装置からの"INTERACTIVE"Accessed。 ネットワークを通した"NETWORK"Accessed。 . 「バッチ」がバッチ・ジョブからアクセスしたサーバへのダイアルアップユーザとしての"DIALUP"Accessed。 少しも認証のない「更生会」Accessed。 "AUTHENTICATED"Anyはシステムサービスからユーザ(更生会の反対側)「サービス」アクセスを認証しました。
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@」(注意: "@"の後のドメイン名がない)に現れるべきであるということです。 例えば: 匿名の@。
5.11.5. Mode Attribute
5.11.5. モード属性
The NFS version 4 mode attribute is based on the UNIX mode bits. The following bits are defined:
NFSバージョン4モード属性はUNIXモードビットに基づいています。 以下のビットは定義されます:
const MODE4_SUID = 0x800; /* set user id on execution */
const MODE4_SGID = 0x400; /* set group id on execution */
const MODE4_SVTX = 0x200; /* save text even after use */
const MODE4_RUSR = 0x100; /* read permission: owner */
const MODE4_WUSR = 0x080; /* write permission: owner */
const MODE4_XUSR = 0x040; /* execute permission: owner */
const MODE4_RGRP = 0x020; /* read permission: group */
const MODE4_WGRP = 0x010; /* write permission: group */
const MODE4_XGRP = 0x008; /* execute permission: group */
const MODE4_ROTH = 0x004; /* read permission: other */
const MODE4_WOTH = 0x002; /* write permission: other */
const MODE4_XOTH = 0x001; /* execute permission: other */
const MODE4_スード=0x800。 /*は実行*/const MODE4_SGID=0x400にユーザイドを設定しました。 /*は実行*/const MODE4_SVTX=0x200にグループイドを設定しました。 /*は、使用の後のテキストさえ*/const MODE4_RUSR=0x100であると保存します。 /*は許可を読みました: 所有者*/const MODE4_WUSR=0x080。 /*は許可を書きます: 所有者*/const MODE4_XUSR=0x040。 /*は許可を実行します: 所有者*/const MODE4_RGRP=0x020。 /*は許可を読みました: */const MODE4_WGRP=0x010を分類してください。 /*は許可を書きます: */const MODE4_XGRP=0x008を分類してください。 /*は許可を実行します: */const MODE4_ロス=0x004を分類してください。 /*は許可を読みました: 他の*/const MODE4_WOTH=0x002。 /*は許可を書きます: 他の*/const MODE4_XOTH=0x001。 /*は許可を実行します: 他の*/
Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal identified in the owner attribute. Bits MODE4_RGRP, MODE4_WGRP, and
ビットのMODE4_RUSR、MODE4_WUSR、およびMODE4_XUSRは所有者属性で特定された主体に適用します。 そしてビットMODE4_RGRP、MODE4_WGRP。
MODE4_XGRP apply to the principals identified in the owner_group attribute. Bits MODE4_ROTH, MODE4_WOTH, MODE4_XOTH apply to any principal that does not match that in the owner group, and does not have a group matching that of the owner_group attribute.
MODE4_XGRPは所有者_グループ属性で特定された主体に適用します。 Bits MODE4_ロス、MODE4_WOTH、MODE4_XOTHは所有者グループでそれを合わせないで、また所有者_グループ属性のものに合っているグループを持っていないどんな校長にも適用します。
The remaining bits are not defined by this protocol and MUST NOT be used. The minor version mechanism must be used to define further bit usage.
残っているビットを、このプロトコルで定義しないで、使用してはいけません。 さらなる噛み付いている用法を定義するのに小さい方のバージョンメカニズムを使用しなければなりません。
Shepler, et al. Standards Track [Page 56] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[56ページ]RFC3530NFSバージョン4 プロトコル2003年4月
Note that in UNIX, if a file has the MODE4_SGID bit set and no MODE4_XGRP bit set, then READ and WRITE must use mandatory file locking.
ファイルでMODE4_SGIDビットを設定して、MODE4_XGRPビットが全くセットしなかったならUNIXでは、READとWRITEが義務的なファイルのロックを使用しなければならないことに注意してください。
5.11.6. Mode and ACL Attribute
5.11.6. モードとACL属性
The server that supports both mode and ACL must take care to synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the ACEs which have respective who fields of "OWNER@", "GROUP@", and "EVERYONE@" so that the client can see semantically equivalent access permissions exist whether the client asks for owner, owner_group and mode attributes, or for just the ACL.
@」 クライアントが意味的に同等であることを見ることができるそうは許容にアクセスします。そして、モードとACLの両方をサポートするサーバがそれぞれのであるそうした注意するMODE4_*USRを連動させるために、MODE4_*GRP、およびACEがあるMODE4_*OTHビット取らなければならない、だれ、「グループ@」という「所有者@」の分野、「皆、クライアントが所有者、所有者_グループ、およびモード属性を求めるか、またはまさしくACLには、存在してください。
Because the mode attribute includes bits (e.g., MODE4_SVTX) that have nothing to do with ACL semantics, it is permitted for clients to specify both the ACL attribute and mode in the same SETATTR operation. However, because there is no prescribed order for processing the attributes in a SETATTR, the client must ensure that ACL attribute, if specified without mode, would produce the desired mode bits, and conversely, the mode attribute if specified without ACL, would produce the desired "OWNER@", "GROUP@", and "EVERYONE@" ACEs.
モード属性がACL意味論と関係ないビット(例えば、MODE4_SVTX)を含んでいるので、それはクライアントがACL属性と同じSETATTR操作におけるモードの両方を指定することが許可されています。 そして、しかしながら、SETATTRで属性を処理する注文を定めないので、クライアントは、モードなしで指定されるならACL属性が逆に必要なモードビットを作り出すのを保証しなければなりません、モード属性、ACLなしで指定されるなら、「グループ@」という必要な「所有者@」を生産するだろう、「皆、@」 ACE。
5.11.7. mounted_on_fileid
5.11.7. _fileidの上の取り付けられた_
UNIX-based operating environments connect a filesystem into the namespace by connecting (mounting) the filesystem onto the existing file object (the mount point, usually a directory) of an existing filesystem. When the mount point's parent directory is read via an API like readdir(), the return results are directory entries, each with a component name and a fileid. The fileid of the mount point's directory entry will be different from the fileid that the stat() system call returns. The stat() system call is returning the fileid of the root of the mounted filesystem, whereas readdir() is returning the fileid stat() would have returned before any filesystems were mounted on the mount point.
既存のファイルシステムの既存ファイルオブジェクト(マウントポイント、通常ディレクトリ)にファイルシステムを接続することによって(取り付けます)、UNIXベースの操作環境はファイルシステムを名前空間に関連づけます。 マウントポイントの親ディレクトリがreaddir()のようなAPIを通して読まれるとき、リターン結果はディレクトリエントリーです、それぞれコンポーネント名とfileidで。 マウントポイントのディレクトリエントリのfileidはstat()システムコールが返すfileidと異なるでしょう。 stat()システムコールは取り付けられたファイルシステムの根のfileidを返していて、readdir()は戻る予定ですが、どんなファイルシステムもマウントポイントに取り付けられる前にfileid stat()は戻ったでしょう。
Unlike NFS version 3, NFS version 4 allows a client's LOOKUP request to cross other filesystems. The client detects the filesystem crossing whenever the filehandle argument of LOOKUP has an fsid attribute different from that of the filehandle returned by LOOKUP. A UNIX-based client will consider this a "mount point crossing". UNIX has a legacy scheme for allowing a process to determine its current working directory. This relies on readdir() of a mount point's parent and stat() of the mount point returning fileids as previously described. The mounted_on_fileid attribute corresponds to the fileid that readdir() would have returned as described previously.
NFSバージョン3と異なって、NFSバージョン4は他のファイルシステムに交差するというクライアントのLOOKUP要求を許します。LOOKUPのfilehandle議論にLOOKUPによって返されたfilehandleのものと異なったfsid属性があるときはいつも、クライアントはファイルシステム交差点を検出します。 UNIXベースのクライアントは、これが「マウントポイント交差点」であると考えるでしょう。 UNIXには、プロセスが現在の働くディレクトリを決定するのを許容することのレガシー体系があります。 これは以前に説明されているとしてマウントポイントのマウントポイントの戻っているfileidsの親とstat()のreaddir()を当てにします。 _fileid属性の取り付けられた_はreaddir()が以前に説明されるように返したfileidに対応しています。
Shepler, et al. Standards Track [Page 57] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[57ページ]RFC3530NFSバージョン4 プロトコル2003年4月
While the NFS version 4 client could simply fabricate a fileid corresponding to what mounted_on_fileid provides (and if the server does not support mounted_on_fileid, the client has no choice), there is a risk that the client will generate a fileid that conflicts with one that is already assigned to another object in the filesystem. Instead, if the server can provide the mounted_on_fileid, the potential for client operational problems in this area is eliminated.
NFSバージョン4クライアントは単にfileidが提供する_に_を取り付けたことに対応するfileidを作ることができましたが(サーバが_fileidの上の取り付けられた_をサポートしないなら、クライアントは選択の余地がありません)、クライアントがファイルシステムで既に別のオブジェクトに割り当てられるものと衝突するfileidを生成するリスクがあります。 代わりに、サーバが_fileidの上の取り付けられた_を提供できるなら、この領域のクライアント運転上の問題の可能性は排除されます。
If the server detects that there is no mounted point at the target file object, then the value for mounted_on_fileid that it returns is the same as that of the fileid attribute.
サーバがそれを検出するなら目標ファイルオブジェクトのポイントが取り付けられないで、次に、_それが返すfileidの上の取り付けられた_のための値はfileid属性のものと同じです。
The mounted_on_fileid attribute is RECOMMENDED, so the server SHOULD provide it if possible, and for a UNIX-based server, this is straightforward. Usually, mounted_on_fileid will be requested during a READDIR operation, in which case it is trivial (at least for UNIX- based servers) to return mounted_on_fileid since it is equal to the fileid of a directory entry returned by readdir(). If mounted_on_fileid is requested in a GETATTR operation, the server should obey an invariant that has it returning a value that is equal to the file object's entry in the object's parent directory, i.e., what readdir() would have returned. Some operating environments allow a series of two or more filesystems to be mounted onto a single mount point. In this case, for the server to obey the aforementioned invariant, it will need to find the base mount point, and not the intermediate mount points.
_fileid属性の取り付けられた_はRECOMMENDEDです、そして、したがって、できれば、サーバSHOULDはそれを提供します、そして、UNIXベースのサーバにおいて、これは簡単です。 通常、_fileidの上の取り付けられた_はREADDIR操作の間、要求されるでしょう。(それがreaddir()によって返されたディレクトリエントリのfileidと等しいので、返すのが些細である(少なくともUNIXのベースのサーバのための)ケースは_fileidにそれで_を取り付けました)。 _fileidの上の取り付けられた_がGETATTR操作で要求されるなら、サーバはそれがオブジェクトの親ディレクトリ(すなわち、readdir()が返したもの)においてファイルオブジェクトのエントリーと等しい値を返す不変式に従うべきです。 いくつかの操作環境で、一連の2つ以上のファイルシステムが単一のマウントポイントに上がります。 この場合、サーバが前述の不変式に従うように、それは、ベースが中間的マウントポイントではなく、マウントポイントであることがわかる必要があるでしょう。
6. Filesystem Migration and Replication
6. ファイルシステム移行と模写
With the use of the recommended attribute "fs_locations", the NFS version 4 server has a method of providing filesystem migration or replication services. For the purposes of migration and replication, a filesystem 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 filesystem 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 filesystem. Depending on the type of service being provided, the list will provide a new location or a set of alternate locations for the filesystem. The client will use this information to redirect its requests to the new server.
fs_位置の属性はファイルシステム位置のリストを提供します。 これらの位置は、サーバー名(DNSドメインかIPアドレスのどちらか)とファイルシステムの根を表すパス名を提供することによって、指定されます。 提供されるサービスのタイプに頼っていて、リストは新しい位置か代替の位置のセットをファイルシステムに提供するでしょう。 クライアントは、新しいサーバに要求を向け直すのにこの情報を使用するでしょう。
6.1. Replication
6.1. 模写
It is expected that filesystem replication will be used in the case of read-only data. Typically, the filesystem will be replicated on two or more servers. The fs_locations attribute will provide the
ファイルシステム模写が書き込み禁止データの場合に使用されると予想されます。 通常、ファイルシステムは2つ以上のサーバで模写されるでしょう。 fs_位置の属性は提供されるでしょう。
Shepler, et al. Standards Track [Page 58] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[58ページ]RFC3530NFSバージョン4 プロトコル2003年4月
list of these locations to the client. On first access of the filesystem, 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.
クライアントへのこれらの位置のリスト。 最初に、ファイルシステムのアクセスのときに、クライアントは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.
適切であるなら、クライアントは、有効なfilehandlesを新しいサーバから取り戻すために善処しなければなりません。これはさらに詳細に以下のセクションで説明されます。
6.2. Migration
6.2. 移行
Filesystem migration is used to move a filesystem from one server to another. Migration is typically used for a filesystem 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 filesystem 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.
ファイルシステム移行は、1つのサーバから別のサーバまでファイルシステムを動かすのに使用されます。 移行は、書き込み可能なファイルシステムに通常使用されて、ただ一つのコピーを持っています。 移行の予想された使用はロードバランシングか一般的なリソース再配分のためのものです。 プロトコルはファイルシステムがどうサーバの間に動かされるかを指定しません。 サーバからサーバへのこのトランスファ・メカニズムはサーバ作成者に任せます。 しかしながら、クライアントとサーバの間の移行イベントを伝えるのに使用されるメソッドはここで指定されます。
Once the servers participating in the migration have completed the move of the filesystem, 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 PUTFH and 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を返すでしょう。PUTFHとGETATTR以外のすべての操作のためにNFS4ERR_MOVED誤りを返します。 NFS4ERR_MOVED誤りを受けると、クライアントはfs_位置の属性の値を得るでしょう。 次に、クライアントは、指定されたサーバに要求を向け直すのに属性のコンテンツを使用するでしょう。また、GETATTRの使用を容易にするために、サーバは移行したファイルシステムのfilehandlesのために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 filesystem 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検証を書きます。 サーバは、プロセスと移行プロセスの後のクライアントで影響を最小にするように努力するべきです。
Shepler, et al. Standards Track [Page 59] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[59ページ]RFC3530NFSバージョン4 プロトコル2003年4月
6.3. Interpretation of the fs_locations Attribute
6.3. fs_位置のAttributeの解釈
The fs_location attribute is structured in the following way:
fs_位置の属性は以下の方法で構造化されます:
struct fs_location {
utf8str_cis server<>;
pathname4 rootpath;
};
struct fs_位置のutf8str_cisサーバ<>(pathname4 rootpath)。
struct fs_locations {
pathname4 fs_root;
fs_location locations<>;
};
pathname4 fs_が根づかせる; fs_位置の位置の<>;struct fs_位置。
The fs_location struct is used to represent the location of a filesystem by providing a server name and the path to the root of the filesystem. 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_位置のstructは、サーバー名と経路をファイルシステムの根に提供することによってファイルシステムの位置を表すのに使用されます。 a、マルチ、家へ帰り、同じrootpathを使用するサーバのサーバかセット、サーバー名の勢ぞろいを提供するかもしれません。 サーバ配列におけるエントリーは、UTF8ストリングであり、伝統的なDNSホスト名、IPv4アドレス、またはIPv6アドレスの1つを表します。 それは同じrootpathを共有するすべてのサーバが1つのfs_位置のstructに記載されているという要件ではありません。 サーバー名の勢ぞろいを便利に提供します。 また、同じrootpathを共有するサーバはfs_位置の属性における別々のfs_位置のエントリーに記載されているかもしれません。
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 filesystem 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 filesystem at the various servers listed.
そして、fs_位置のstructと属性は位置の配列を含んでいます。 それぞれのサーバの名前スペースが異なって構成されるかもしれないので、「fs_根」野原を供給します。 fs_根によって表された経路はサーバの名前スペースにファイルシステムの位置を表します。 したがって、fs_根の経路はfs_位置の属性が得られたサーバに関連しているだけです。 fs_根の経路は様々なサーバでファイルシステムの場所を見つけることにおけるクライアントが記載した援助に意味されます。
As an example, there is a replicated filesystem located at two servers (servA and servB). At servA the filesystem is located at path "/a/b/c". At servB the filesystem is located at path "/x/y/z". In this example the client accesses the filesystem 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 filesystem'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
例として、2つのサーバ(servAとservB)で位置する模写されたファイルシステムがあります。 servAでは、ファイルシステムは経路"/a/b/c"に位置しています。 servBでは、ファイルシステムは経路"/x/y/z"に位置しています。 この例では、クライアントは最初に、"/a/b/c/d"の多成分系のルックアップ経路があるservAでファイルシステムにアクセスします。 クライアントが"/a/b/c/d"でfilehandleを入手するのに多成分系のルックアップを使用したので、ファイルシステムの根が"/a/b/c"のservAの名前スペースに位置しているのは、気づきません。 クライアントがservBに切り替わるとき、それは、それが最初にservAで参照をつけたディレクトリが現在servBの経路"/x/y/z/d"によって表されることを決定する必要があるでしょう。 これを容易にするために、servAによって提供されたfs_位置の属性はfs_位置の"/a/b/c"と2つのエントリーのfs_根の値を持っているでしょう。 fs_位置での、あるエントリーがそれ自体(servA)のためにものになるでしょう、そして、もう片方がservBのためにaをもってものになるでしょう。
Shepler, et al. Standards Track [Page 60] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[60ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
"/x/y/z"の経路。 この情報で、クライアントは新しいサーバに使用するアクセス経路と構造物"/x/y/z/d"の始めに"/x/y/z"を"/a/b/c"の代わりに用いることができます。
See the section "Security Considerations" for a discussion on the recommendations for the security flavor to be used by any GETATTR operation that requests the "fs_locations" attribute.
セキュリティ風味が「fs_位置」属性を要求するどんなGETATTR操作でも使用されるという推薦についての議論に関して「セキュリティ問題」というセクションを見てください。
6.4. Filehandle Recovery for Migration or Replication
6.4. 移行か模写のためのFilehandle回復
Filehandles for filesystems that are replicated or migrated generally have the same semantics as for filesystems that are not replicated or migrated. For example, if a filesystem has persistent filehandles and it is migrated to another server, the filehandle values for the filesystem will be valid at the new server.
模写されたか移行したファイルシステムには同じ意味論がファイルシステムのように一般にあるので、Filehandlesは模写もしませんでしたし、移行もしませんでした。 例えばファイルシステムには永続的なfilehandlesがあって、別のサーバに移行します、ファイルシステムのためのfilehandle値が新しいサーバで有効になるということであるなら。
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 filehandle to the new server. The client will start its communication with the new server by recovering its filehandles using the saved file names.
揮発性のfilehandlesに関しては、おそらくかかわるサーバはfilehandle形式と内容を自分たちの間に移すメカニズムを持っていません。 したがって、古いサーバからの揮発性のfilehandleがNFS4ERR_FHEXPIREDの誤りを返すはずであるかどうか決定する際にサーバは苦労するかもしれません。 したがって、クライアントは知識があって、fh_の使用で、タイプが結果と考える_を吐き出してください、揮発性のfilehandlesが移行か模写イベントで期限が切れるか否かに関係なく。 _ビットFH4_VOL_MIGRATIONがfhで用意ができているなら、タイプが結果と考える_を吐き出してください、そして、まるでサーバがNFS4ERR_FHEXPIRED誤りを返したかのようにクライアントは揮発性のfilehandleを扱わなければなりません。 FH4_VOL_MIGRATIONビットがあるとき移行か模写イベントでは、クライアントはオリジナルの、または、古い揮発性のfilehandleを新しいサーバに寄贈しないでしょう。クライアントは、保存ファイル名を使用することでfilehandlesを回収することによって、新しいサーバとのコミュニケーションを始めるでしょう。
7. NFS Server Name Space
7. NFSサーバー名スペース
7.1. Server Exports
7.1. サーバ輸出
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 filesystem 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プロトコルの旧バージョンでは、山のプロトコルを通して各輸出のための根のfilehandleを入手します。 クライアントは名前スペースの輸出を特定するストリングを送ります、そして、サーバはそれのために根のfilehandleを返します。 山のプロトコルはサーバの輸出を列挙するEXPORTS手順をサポートします。
Shepler, et al. Standards Track [Page 61] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[61ページ]RFC3530NFSバージョン4 プロトコル2003年4月
7.2. Browsing Exports
7.2. ブラウジング輸出
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を通してこれらの輸出にfilehandlesを入手するのに使用できる根のfilehandleを提供します。 一般的なユーザー・エクスペリエンスはディレクトリツリーを通した進歩的なブラウジングでファイルを見つけるのに、グラフィカルユーザーインターフェース(恐らくファイル「開く」対話ウィンドウ)を使用することです。 クライアントはただ一つのコンポーネント、進歩的な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 filesystem. 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 filesystem" that allows the user to browse from one mounted filesystem 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.
クライアントの上のオートマウンタは、山のプロトコルのEXPORTS手順を用いることでサーバの名前スペースのスナップを得ることができます。 サーバのパス名構文を理解しているなら、それはサーバの名前スペースのイメージをクライアントに作成できます。 サーバによってエクスポートされないスペースという名前の部分はユーザが1つの取り付けられたファイルシステムから別のファイルシステムまでブラウズできる「疑似ファイルシステム」で記入されます。 クライアントにおけるサーバの名前スペースのこの表現への欠点があります: それは静的です。 サーバアドミニストレータが新しい輸出品を加えると、クライアントはそれで気づかなくなるでしょう。
7.3. Server Pseudo Filesystem
7.3. サーバ、疑似ファイルシステム
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 filesystem" that provides a view of exported directories only. A pseudo filesystem has a unique fsid and behaves like a normal, read only filesystem.
NFSバージョン4サーバは、ただ一つのサーバー名スペースのフレームワークの中にすべての輸出を提示することによって、この名前宇宙矛盾を避けます。 NFSバージョン4クライアントは、シームレスに1つの輸出から別の輸出までブラウズするのにLOOKUPとREADDIR操作を使用します。 エクスポートされないスペースというサーバー名の部分はエクスポートしているディレクトリだけに関する意見を提供する「疑似ファイルシステム」を通してブリッジされます。 疑似ファイルシステムは、ユニークなfsidを持って、正常な書き込み禁止ファイルシステムのように振る舞います。
Based on the construction of the server's name space, it is possible that multiple pseudo filesystems may exist. For example,
サーバの名前スペースの工事に基づいて、複数の疑似ファイルシステムが存在するのは、可能です。 例えば
/a pseudo filesystem /a/b real filesystem /a/b/c pseudo filesystem /a/b/c/d real filesystem
/は本当の疑似ファイルシステムのファイルシステム/a/b/c疑似ファイルシステム/a/b/c/d本当の/a/bファイルシステムです。
Each of the pseudo filesystems are considered separate entities and therefore will have a unique fsid.
それぞれの疑似ファイルシステムは、別々の実体であると考えられて、したがって、ユニークなfsidを持つでしょう。
Shepler, et al. Standards Track [Page 62] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[62ページ]RFC3530NFSバージョン4 プロトコル2003年4月
7.4. Multiple Roots
7.4. 重解
The DOS and Windows operating environments are sometimes described as having "multiple roots". Filesystems are commonly represented as disk letters. MacOS represents filesystems 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サーバがこれらの根の名を超えて疑似ファイルシステムを構成できるので、ディスク手紙かボリューム名が単に疑似根がディレクトリ名です。
7.5. Filehandle Volatility
7.5. Filehandleの不安定さ
The nature of the server's pseudo filesystem is that it is a logical representation of filesystem(s) available from the server. Therefore, the pseudo filesystem is most likely constructed dynamically when the server is first instantiated. It is expected that the pseudo filesystem 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 filesystem, 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.
サーバの疑似ファイルシステムの本質はそれがサーバから利用可能なファイルシステムの論理的な表現であるということです。したがって、サーバが最初に例示されるとき、疑似ファイルシステムはたぶんダイナミックに構成されます。 疑似ファイルシステムがそうしていないかもしれないと予想されない、ディスク対応者、永続的なfilehandlesを組み立てることができた。 サーバが永続的なfilehandlesを疑似ファイルシステムに提供するのが、望ましいのですが、NFSクライアントは、疑似ファイルシステムfilehandlesが不安定であると予想するべきです。 問題のそれらのfilehandlesがないかどうか「fh_は_タイプを吐き出す」という関連属性をチェックすることによって、これを確認できます。 filehandlesが不安定であるなら、NFSクライアントはNFS4ERR_FHEXPIREDの誤りを受けるときにはfilehandle値(例えば、多成分系のLOOKUPと)を回復する用意ができていなければなりません。
7.6. Exported Root
7.6. 根であるとエクスポートされます。
If the server's root filesystem is exported, one might conclude that a pseudo-filesystem is not needed. This would be wrong. Assume the following filesystems on a server:
サーバの根のファイルシステムがエクスポートされるなら、人は、疑似ファイルシステムが必要でないと結論を下すかもしれません。 これは間違っているでしょう。 サーバで以下のファイルシステムを仮定してください:
/ disk1 (exported)
/a disk2 (not exported)
/a/b disk3 (exported)
/disk1(エクスポートされる)/はdisk2(エクスポートされない)/a/b disk3です。(エクスポートされます)
Because disk2 is not exported, disk3 cannot be reached with simple LOOKUPs. The server must bridge the gap with a pseudo-filesystem.
disk2がエクスポートされないので、disk3に簡単なLOOKUPsと共に達することができません。 サーバは疑似ファイルシステムで間隙を塞がなければなりません。
7.7. Mount Point Crossing
7.7. 山のポイント交差点
The server filesystem environment may be constructed in such a way that one filesystem contains a directory which is 'covered' or mounted upon by a second filesystem. For example:
サーバファイルシステム環境は1つのファイルシステムが2番目のファイルシステムによって'カバーされる'か、または取り付けられるディレクトリを含んでいるような方法で構成されるかもしれません。 例えば:
/a/b (filesystem 1)
/a/b/c/d (filesystem 2)
/a/b(ファイルシステム1)/a/b/c/d(ファイルシステム2)
Shepler, et al. Standards Track [Page 63] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[63ページ]RFC3530NFSバージョン4 プロトコル2003年4月
The pseudo filesystem for this server may be constructed to look like:
このサーバのための疑似ファイルシステムは似るように構成されるかもしれません:
/ (place holder/not exported)
/a/b (filesystem 1)
/a/b/c/d (filesystem 2)
/(場所所有者/エクスポートしていない)/a/b(ファイルシステム1)/a/b/c/d(ファイルシステム2)
It is the server's responsibility to present the pseudo filesystem 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 filesystem "/a/b/c/d". In previous versions of the NFS protocol, the server would respond with the filehandle of directory "/a/b/c/d" within the filesystem "/a/b".
クライアントにとって完全であるのは、疑似ファイルシステムを提示するサーバの責任です。 クライアントが経路"/a/b/c/d"を求めるルックアップ要求を送るなら、サーバの応答はファイルシステム"/a/b/c/d"のfilehandleです。 NFSプロトコルの旧バージョンでは、サーバはファイルシステム"/a/b"の中でディレクトリのfilehandleで"/a/b/c/d"を反応させるでしょう。
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"属性の値における変化でサーバマウントポイントに交差するかどうか決定できるでしょう。
7.8. Security Policy and Name Space Presentation
7.8. 安全保障政策と名前宇宙プレゼンテーション
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 filesystem 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 filesystem, the server may effectively hide filesystems from a client that may otherwise have legitimate access.
サーバの安全保障政策の適用は、作成者によって慎重に考えられる必要があります。 適切にそれ自体を認証するクライアントの能力に関するサーバの知覚に基づく疑似ファイルシステムの部分のviewabilityを制限するのを選ぶかもしれません。 しかしながら、複数のセキュリティー対策のサポートとこれらのメカニズムの適切な使用を交渉する能力に、サーバは、クライアントがそれ自体を認証できるかどうか適切に決定できません。 サーバが、方針に基づいて疑似ファイルシステムのコンテンツを制限するのを選ぶなら、事実上、サーバはそうでなければ正統のアクセサリーを持っているかもしれないクライアントからファイルシステムを隠すかもしれません。
As suggested practice, the server should apply the security policy of a shared resource in the server's namespace to the components of the resource's ancestors. For example:
提案された習慣として、サーバはサーバの名前空間における共用資源の安全保障政策をリソースの先祖のコンポーネントに適用するべきです。 例えば:
/
/a/b
/a/b/c
/ /a/b /a/b/c
The /a/b/c directory is a real filesystem and is the shared resource. The security policy for /a/b/c is Kerberos with integrity. The server should apply the same security policy to /, /a, and /a/b. This allows for the extension of the protection of the server's namespace to the ancestors of the real shared resource.
/a/b/cディレクトリは、本当のファイルシステムであり、共用資源です。 /a/b/cのための安全保障政策は保全があるケルベロスです。 サーバは//、a、および/a/bに同じ安全保障政策を当てはまるべきです。 これは本当の共用資源の先祖にとってサーバの名前空間の保護の拡大を考慮します。
Shepler, et al. Standards Track [Page 64] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[64ページ]RFC3530NFSバージョン4 プロトコル2003年4月
For the case of the use of multiple, disjoint security mechanisms in the server's resources, the security for a particular object in the server's namespace should be the union of all security mechanisms of all direct descendants.
サーバの名前空間における特定のオブジェクトがすべてのダイレクト子孫のすべてのセキュリティー対策の組合であるべきであるので、倍数の使用に関するケースには、サーバのリソース、セキュリティでセキュリティー対策をばらばらにならせてください。
8. File Locking and Share Reservations
8. ファイルのロックとシェア予約
Integrating locking into the NFS protocol necessarily causes it to be stateful. With the inclusion of share reservations 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プロトコルを閉じ込めながら統合するのは、それがstatefulであることを必ず引き起こします。 シェアの予約の包含によると、プロトコルは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 reservations 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 NFS version 3 methodology 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にサポートするために、オープンかCREATEがファイルします。 別々のシェア/非シェア操作を持っているのはWin32 OpenFile APIの正しい実装を許容しないでしょう。 正しくシェア意味論を実装するために、ファイルが開かれるか、または作成されるとき使用される前のNFSプロトコルメカニズム(LOOKUP、CREATE、ACCESS)は、取り替えられる必要があります。 NFSバージョン4プロトコルには、LOOKUP、CREATE、およびACCESSのNFSバージョン3方法論を包括するオープン操作があります。 しかしながら、多くの操作がfilehandleを必要とするので、伝統的なLOOKUPはサーバの状態を設置しないでファイル名をfilehandleに写像するために保存されます。アクセスを承諾するか、またはファイルを変更する方針はクライアントの状態に基づくサーバによって管理されます。 これらのメカニズムは完全な義務的なロックにロックされるだけである状況報告から変化する政策を実施できます。
8.1. Locking
8.1. ロックします。
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操作と比べると錠を操作するのがまれであると思われます。 また、クラッシュとネットワークパーティションが比較的まれであると思われます。 したがって、保持された錠を所有しているならREADとWRITE操作には示す軽量のメカニズムがあるのは、重要です。 ロック要求は錠を設立して、唯一ロック所有者を定義するのに必要であるヘビー級の情報を含んでいます。
Shepler, et al. Standards Track [Page 65] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[65ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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までの変遷について説明します。
8.1.1. Client ID
8.1.1. クライアントID
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. A sequence of a SETCLIENTID operation followed by a SETCLIENTID_CONFIRM operation is required to establish the identification onto the server. Establishment of identification by a new incarnation of the client also has the effect of immediately breaking any leased state that a previous incarnation of the client might have had on the server, as opposed to forcing the new client incarnation to wait for the leases to expire. Breaking the lease state amounts to the server removing all lock, share reservation, and, where the server is not supporting the CLAIM_DELEGATE_PREV claim type, all delegation state associated with same client with the same identity. For discussion of delegation state recovery, see the section "Delegation Recovery".
これは正しいロック識別を考慮して、回復を墜落させるほどそのような方法で完了しています。 SETCLIENTID_CONFIRM操作があとに続いたSETCLIENTID操作の系列が、識別をサーバに確立するのに必要です。また、クライアントの新しい肉体化による識別の設立には、すぐにの効果がクライアントの前の肉体化がサーバに持っていたどんな賃貸された状態も壊しながら、あります、新しいクライアント肉体化をリースが期限が切れるのを待たせることと対照的に。 すべての錠を取り外すサーバにリース州の量を切り出して、予約、およびサーバがクレーム_DELEGATE_がPREVクレームタイプであるとサポートしていないところの同じアイデンティティで同じクライアントに関連しているすべての委譲状態を共有してください。 委譲州の回復の議論に関しては、「委譲回復」というセクションを見てください。
Client identification is encapsulated in the following structure:
クライアント識別は以下の構造でカプセル化されます:
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
struct nfs_クライアント_id4、verifier4検証(不明瞭なイド<NFS4_OPAQUE_LIMIT>)。
The first field, verifier is a client incarnation verifier that is used to detect client reboots. Only if the verifier is different from that which the server has previously recorded the client (as identified by the second field of the structure, id) does the server start the process of canceling the client's leased state.
最初の分野であり、検証はクライアントリブートを検出するのに使用されるクライアント肉体化検証です。 検証がサーバが以前に記録したそれと異なる場合にだけ、クライアント(構造の2番目の分野、イドによって特定されるように)はクライアントを取り消すプロセスが賃貸したサーバ始めに状態をします。
The second field, id is a variable length string that uniquely defines the client.
2番目の分野であり、イドは唯一クライアントを定義する可変長ストリングです。
There are several considerations for how the client generates the id string:
クライアントがどうイドストリングを生成するかいくつかの問題があります:
o The string should be unique so that multiple clients do not
present the same string. The consequences of two clients
presenting the same string range from one client getting an error
to one client having its leased state abruptly and unexpectedly
canceled.
o ストリングがユニークであるべきであるので、複数のクライアントは同じストリングを贈りません。 2人のクライアントが同じ誤りを得る1人のクライアントから突然に不意に賃貸された状態を持っている1人のクライアントまでのストリング範囲を提示する結果は取り消されました。
Shepler, et al. Standards Track [Page 66] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[66ページ]RFC3530NFSバージョン4 プロトコル2003年4月
o The string should be selected so the subsequent incarnations
(e.g., reboots) of the same client cause the client to present the
same string. The implementor is cautioned against an approach
that requires the string to be recorded in a local file because
this precludes the use of the implementation in an environment
where there is no local disk and all file access is from an NFS
version 4 server.
o ストリングが選択されるべきであるので、同じクライアントのその後の肉体化(例えば、リブートする)はクライアントに同じストリングを贈らせます。 作成者はこれがローカルディスクが全くなくて、すべてのファイルアクセスがNFSバージョン4サーバから来ている環境における実装の使用を排除するのでストリングがローカルファイルに記録されるのを必要とするアプローチに対して警告されます。
o The string should be different for each server network address
that the client accesses, rather than common to all server network
addresses. The reason is that it may not be possible for the
client to tell if the same server is listening on multiple network
addresses. If the client issues SETCLIENTID with the same id
string to each network address of such a server, the server will
think it is the same client, and each successive SETCLIENTID will
cause the server to begin the process of removing the client's
previous leased state.
o クライアントがアクセスするそれぞれのサーバネットワーク・アドレスにおいて、すべてのサーバネットワーク・アドレスに共通であるというよりむしろストリングは異なっているべきです。 理由はクライアントが、同じサーバが複数のネットワーク・アドレスで聴かれているかどうか言うのが、可能でないかもしれないということです。 クライアントが同じイドひもでそのようなサーバの各ネットワーク・アドレスにSETCLIENTIDを発行すると、サーバは、それが同じクライアントであると思うでしょう、そして、それぞれの連続したSETCLIENTIDはサーバにクライアントの前の賃貸された状態を取り除くプロセスを開始させるでしょう。
o The algorithm for generating the string should not assume that the
client's network address won't change. This includes changes
between client incarnations and even changes while the client is
stilling running in its current incarnation. This means that if
the client includes just the client's and server's network address
in the id string, there is a real risk, after the client gives up
the network address, that another client, using a similar
algorithm for generating the id string, will generate a
conflicting id string.
o ストリングを生成するためのアルゴリズムは、クライアントのネットワーク・アドレスが変化しないと仮定するべきではありません。 クライアントが現在の肉体化へ駆け込みながら静まっている間、これはクライアント肉体化と変化の間の変化さえ含んでいます。 これは、クライアントがイドストリングでまさしくクライアントとサーバのネットワーク・アドレスを入れるなら、本当のリスクがあることを意味して、クライアントがあきらめた後にネットワーク・アドレス(イドストリングを生成するための別のクライアントの、そして、そんなに使用している同様のアルゴリズム)は闘争しているイドストリングを生成するでしょう。
Given the above considerations, an example of a well generated id string is one that includes:
上の問題を考えて、よく生成しているイドストリングに関する例はである:ものです。
o The server's network address.
o サーバのネットワーク・アドレス。
o The client's network address.
o クライアントのネットワーク・アドレス。
o For a user level NFS version 4 client, it should contain
additional information to distinguish the client from other user
level clients running on the same host, such as a process id or
other unique sequence.
o ユーザレベルNFSバージョン4クライアントに関しては、同じホストで走っている他のユーザレベルクライアントとクライアントを区別する追加情報を含むべきです、プロセスイドや他のユニーク配列のように。
o Additional information that tends to be unique, such as one or
more of:
o 1つや、より多くであることのように特有である傾向がある追加情報:
- The client machine's serial number (for privacy reasons, it is
best to perform some one way function on the serial number).
- クライアントマシンの通し番号(プライバシー理由で、何らかの一方通行の機能を通し番号に実行するのは最も良いです)。
- A MAC address.
- MACアドレス。
Shepler, et al. Standards Track [Page 67] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[67ページ]RFC3530NFSバージョン4 プロトコル2003年4月
- The timestamp of when the NFS version 4 software was first
installed on the client (though this is subject to the
previously mentioned caution about using information that is
stored in a file, because the file might only be accessible
over NFS version 4).
- NFSバージョン4ソフトウェアが最初にクライアントの上にインストールされた(これは情報を使用することに関して以前に言及された警告を受けることがありますが、それはファイルに保存されます、ファイルがNFSバージョン4の上でアクセス可能であるだけであるかもしれないので)時に関するタイムスタンプ。
- A true random number. However since this number ought to be
the same between client incarnations, this shares the same
problem as that of the using the timestamp of the software
installation.
- 正しい乱数。 クライアント肉体化の間で同じであることで、しかしながら、これは、この数がそうであるべきであるので、使用についてそれと同じ問題を共有します。ソフトウェアインストールに関するタイムスタンプ。
As a security measure, the server MUST NOT cancel a client's leased state if the principal established the state for a given id string is not the same as the principal issuing the SETCLIENTID.
安全対策、サーバが取り消されてはいけないので、校長が与えられたイドストリングのために状態を設置したなら、クライアントの賃貸された状態はSETCLIENTIDを発行する校長と同じではありません。
Note that SETCLIENTID and SETCLIENTID_CONFIRM has a secondary purpose of establishing the information the server needs to make callbacks to the client for purpose of supporting delegations. It is permitted to change this information via SETCLIENTID and SETCLIENTID_CONFIRM within the same incarnation of the client without removing the client's leased state.
注意のそのSETCLIENTIDとSETCLIENTID_CONFIRMには、委譲をサポートする目的のためにサーバがクライアントにコールバックを作るために必要とする情報を確立する副次目的があります。 それがSETCLIENTIDを通してこの情報を変えるのが可能にされて、クライアントを外すことのないクライアントの同じ肉体化の中のSETCLIENTID_CONFIRMは状態を賃貸しました。
Once a SETCLIENTID and SETCLIENTID_CONFIRM sequence has successfully completed, the client uses the shorthand client identifier, of type clientid4, instead of the longer and less compact nfs_client_id4 structure. This shorthand client identifier (a clientid) is assigned by the server and 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").
かつてのSETCLIENTIDとCONFIRM系列が首尾よく持っているSETCLIENTID_が完成して、クライアントはタイプclientid4に関する速記クライアント識別子を使用します、より長くてそれほどコンパクトでないnfs_クライアント_id4構造の代わりに。 それは以前にサーバによって割り当てられる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 "lock_owner and stateid Definition" for details).
また、現在のclientidから得られたstateidを使用することでNFS4ERR_STALE_STATEID誤りを受けるとき、クライアントはSETCLIENTID操作を使わなければなりません、また、これが既存のclientid(次のセクションが詳細のために「_所有者とstateid Definitionをロックすること」を見る)を無効にしたサーバリブートを示すので。
See the detailed descriptions of SETCLIENTID and SETCLIENTID_CONFIRM for a complete specification of the operations.
操作の完全な仕様に関してSETCLIENTIDとSETCLIENTID_CONFIRMの詳述を見てください。
Shepler, et al. Standards Track [Page 68] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[68ページ]RFC3530NFSバージョン4 プロトコル2003年4月
8.1.2. Server Release of Clientid
8.1.2. Clientidのサーバリリース
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をリリースしないでしょう。
Note that if the id string in a SETCLIENTID request is properly constructed, and if the client takes care to use the same principal for each successive use of SETCLIENTID, then, barring an active denial of service attack, NFS4ERR_CLID_INUSE should never be returned.
次に、SETCLIENTID要求におけるイドストリングが適切に構成されて、クライアントがSETCLIENTIDのそれぞれの連続した使用に同じ主体を使用するために注意するなら、サービス攻撃の活発な否定以外に、NFS4ERR_CLID_椚瀬が決して返されるべきでないことに注意してください。
However, client bugs, server bugs, or perhaps a deliberate change of the principal owner of the id string (such as the case of a client that changes security flavors, and under the new flavor, there is no mapping to the previous owner) will in rare cases result in NFS4ERR_CLID_INUSE.
しかしながら、イドストリング(セキュリティ風味を変えるクライアントの場合などと、そして、新しい風味の下では、前の所有者に写像してはいけない)の主要な所有者のクライアントバグ、サーババグ、または恐らく慎重な変化がたまにはNFS4ERR_CLID_椚瀬をもたらすでしょう。
In that event, when the server gets a SETCLIENTID for a client id that currently has no state, or it has state, but the lease has expired, rather than returning NFS4ERR_CLID_INUSE, the server MUST allow the SETCLIENTID, and confirm the new clientid if followed by the appropriate SETCLIENTID_CONFIRM.
その場合には、適切なSETCLIENTID_CONFIRMによって続かれているなら、サーバが現在状態を全く持っていないクライアントイドのためにSETCLIENTIDを手に入れるか、それには状態がありますが、またはリースがCLID_椚瀬をNFS4ERR_に返すよりむしろ期限が切れたとき、サーバは、SETCLIENTIDを許容して、新しいclientidを確認しなければなりません。
8.1.3. lock_owner and stateid Definition
8.1.3. _所有者とstateid Definitionをロックしてください。
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 lock_owner and the definition of those fields are:
錠を要求するとき、クライアントは要求された錠の所有者のためにclientidと識別子をサーバに提示しなければなりません。 錠と呼ばれた_所有者とそれらの定義がさばくこれらの2つの分野は以下の通りです。
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.
これは、スレッドイド、プロセスイド、または他のユニークな値であるかもしれません。
Shepler, et al. Standards Track [Page 69] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[69ページ]RFC3530NFSバージョン4 プロトコル2003年4月
When the server grants the lock, it responds with a unique stateid. The stateid is used as a shorthand reference to the lock_owner, since the server will be maintaining the correspondence between them.
サーバが錠を与えるとき、それはユニークなstateidで応じます。 stateidは錠_所有者についての速記言及として使用されます、サーバがそれらの間の通信を維持するので。
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.
o 以前のサーバインスタンス(すなわち、サーバリブートの前の)によってstateidは生成されました。 誤り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.
o stateidはもうstateidだけが問題のlockowner-ファイル組のために現在のロック状態を命名している現在のサーバインスタンスによって生成されました(すなわち、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を使用する入出力要求が傑出していますが、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.
o stateidは現在のサーバインスタンスによって生成されましたが、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,
これらの要件を満たすのに使用されるかもしれない1つのメカニズムがサーバのためのものです。
o divide the "other" field of each stateid into two fields:
o それぞれのstateidの「他」の分野を2つの分野に分割してください:
- A server verifier which uniquely designates a particular server
instantiation.
- 唯一特定のサーバ具体化を指定するサーバ検証。
- An index into a table of locking-state structures.
- ロック州の構造のテーブルへのインデックス。
Shepler, et al. Standards Track [Page 70] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[70ページ]RFC3530NFSバージョン4 プロトコル2003年4月
o utilize the "seqid" field of each stateid, such that seqid is
monotonically incremented for each stateid that is associated with
the same index into the locking-state table.
o それぞれのstateidの"seqid"分野を利用してください、seqidがロックステートテーブルへの同じインデックスに関連しているそれぞれのstateidのために単調に増加されるように。
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が有効でないなら、適切な誤りをクライアントに提供できます。
8.1.4. Use of the stateid and Locking
8.1.4. stateidとLockingの使用
All READ, WRITE and SETATTR operations contain a stateid. For the purposes of this section, SETATTR operations which change the size attribute of a file are treated as if they are writing the area between the old and new size (i.e., the range truncated or added to the file by means of the SETATTR), even where SETATTR is not explicitly mentioned in the text.
すべてのREAD、WRITE、およびSETATTR操作はstateidを含んでいます。 このセクションの目的のために、まるで古くて新しいサイズ(すなわち、SETATTRによってファイルに先端を切られるか、または追加された範囲)の間の領域を書いているかのようにファイルのサイズ属性を変えるSETATTR操作は扱われます、SETATTRがテキストで明らかに言及さえされないところで。
If the lock_owner performs a READ or WRITE in a situation in which it has established a lock or share reservation on the server (any OPEN constitutes a share reservation) the stateid (previously returned by the server) must be used to indicate what locks, including both record locks and share reservations, are held by the lockowner. If no state is established by the client, either record lock or share reservation, a stateid of all bits 0 is used. Regardless whether a stateid of all bits 0, or a stateid returned by the server is used, if there is a conflicting share reservation or mandatory record lock held on the file, the server MUST refuse to service the READ or WRITE operation.
錠_所有者がそれがサーバの錠かシェアの予約を確立した状況でREADかWRITEを実行するなら(どんなオープンもシェアの予約を成立させます)、記録的な錠とシェアの予約の両方を含むどんな錠がlockownerによって持たれているかを示すのに、stateid(以前に、サーバで戻る)を使用しなければなりません。 状態が全くクライアント(記録的な錠かシェアの予約のどちらか)によって設置されないなら、すべてのビット0のstateidは使用されています。 不注意に、ファイルの上で持たれていた闘争しているシェアの予約か義務的な記録的な錠があれば使用されて、サーバは、すべてのビット0のstateid、またはサーバによって返されたstateidがそうであるか否かに関係なく、READかWRITE操作を調整するのを拒否しなければなりません。
Share reservations are established by OPEN operations and by their nature are mandatory in that when the OPEN denies READ or WRITE operations, that denial results in such operations being rejected with error NFS4ERR_LOCKED. Record locks may be implemented by the server as either mandatory or advisory, or the choice of mandatory or advisory behavior may be determined by the server on the basis of the file being accessed (for example, some UNIX-based servers support a "mandatory lock bit" on the mode attribute such that if set, record locks are required on the file before I/O is possible). When record locks are advisory, they only prevent the granting of conflicting lock requests and have no effect on READs or WRITEs. Mandatory record locks, however, prevent conflicting I/O operations. When they are attempted, they are rejected with NFS4ERR_LOCKED. When the client gets NFS4ERR_LOCKED on a file it knows it has the proper share reservation for, it will need to issue a LOCK request on the region
オープンがREADかWRITEに対して操作を否定するとき、その否定が誤りNFS4ERR_LOCKEDと共に拒絶されるそのような操作をもたらすので、シェアの予約は、オープン操作で設立されて、本質的に義務的です。 記録的な錠が義務的であるか顧問としてサーバによって実装されるかもしれませんか、またはアクセスされていて、義務的であるか顧問の振舞いの選択はファイルに基づいてサーバで決定するかもしれません(例えば、いくつかのUNIXベースのサーバがモード属性の「義務的なロックビット」をサポートするので、入出力が可能になる前に、設定されるなら、記録的な錠がファイルの上で必要です)。 記録的な錠が顧問であるときに、それらは、闘争しているロック要求を与えることを防ぐだけであり、READsかWRITEsで効き目がありません。 しかしながら、義務的な記録的な錠は闘争している入出力操作を防ぎます。 試みられるとき、それらはNFS4ERR_LOCKEDと共に拒絶されます。 クライアントが持っているそれが適切なシェアの予約を知っているファイルでNFS4ERR_LOCKEDを手に入れるとき、それは、領域に関するLOCK要求を出す必要があるでしょう。
Shepler, et al. Standards Track [Page 71] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[71ページ]RFC3530NFSバージョン4 プロトコル2003年4月
of the file that includes the region the I/O was to be performed on, with an appropriate locktype (i.e., READ*_LT for a READ operation, WRITE*_LT for a WRITE operation).
of the file that includes the region the I/O was to be performed on, with an appropriate locktype (i.e., READ*_LT for a READ operation, WRITE*_LT for a WRITE operation).
With NFS version 3, there was no notion of a stateid so there was no way to tell if the application process of the client sending the READ or WRITE operation had also acquired the appropriate record lock on the file. Thus there was no way to implement mandatory locking. With the stateid construct, this barrier has been removed.
stateidの概念が全くなかったので、NFSバージョン3と共に、また、クライアントがREADかWRITEに操作を送るアプリケーション・プロセスがファイルの上で適切な記録的な錠を入手したかどうか言う方法が全くありませんでした。 したがって、義務的なロックを実装する方法が全くありませんでした。 stateid構造物で、このバリアを取り除きました。
Note that for UNIX environments that support mandatory file locking, the distinction between advisory and mandatory locking is subtle. In fact, advisory and mandatory record locks are exactly the same in so far as the APIs and requirements on implementation. If the mandatory lock attribute is set on the file, the server checks to see if the lockowner has an appropriate shared (read) or exclusive (write) record lock on the region it wishes to read or write to. If there is no appropriate lock, the server checks if there is a conflicting lock (which can be done by attempting to acquire the conflicting lock on the behalf of the lockowner, and if successful, release the lock after the READ or WRITE is done), and if there is, the server returns NFS4ERR_LOCKED.
義務的なファイルのロックをサポートするunix環境に、顧問の、そして、義務的なロックの区別が微妙であることに注意してください。 事実上、顧問の、そして、義務的な記録的な錠はまさに今までのところ実装に関するAPIと要件と同じです。 義務的なロック属性がファイルの上に設定されるなら、サーバは、lockownerが(書きます)適切な共有(読まれる)にされるのであるか排他的な記録にそれが読み込みたいか、または書きたがっている領域をつながせるかどうか確認するためにチェックします。 どんな適切な錠もなければ、サーバは、闘争錠があるかどうか(lockownerに代わって闘争錠を入手するのを試みることによって、どれができるか、そして、うまくいくなら、READかWRITEが完了していた後に錠をリリースしてください)チェックします、そして、あれば、サーバはNFS4ERR_LOCKEDを返します。
For Windows environments, there are no advisory record locks, so the server always checks for record locks during I/O requests.
ウィンドウズ環境のために、どんな顧問記録的な錠もないので、サーバは入出力要求の間、記録的な錠がないかどうかいつもチェックします。
Thus, the NFS version 4 LOCK operation does not need to distinguish between advisory and mandatory record locks. It is the NFS version 4 server's processing of the READ and WRITE operations that introduces the distinction.
したがって、NFSバージョン4LOCK操作は顧問の、そして、義務的な記録的な錠を見分ける必要はありません。 それは区別を導入するNFSバージョン4サーバのREADとWRITE操作の処理です。
Every stateid other than the special stateid values noted in this section, whether returned by an OPEN-type operation (i.e., OPEN, OPEN_DOWNGRADE), or by a LOCK-type operation (i.e., LOCK or LOCKU), defines an access mode for the file (i.e., READ, WRITE, or READ- WRITE) as established by the original OPEN which began the stateid sequence, and as modified by subsequent OPENs and OPEN_DOWNGRADEs within that stateid sequence. When a READ, WRITE, or SETATTR which specifies the size attribute, is done, the operation is subject to checking against the access mode to verify that the operation is appropriate given the OPEN with which the operation is associated.
戻るか否かに関係なく、特別なstateid値以外のあらゆるstateidがこのセクションで注意した、オープンタイプ、操作、(すなわち、オープン、オープン_DOWNGRADE)、aで、操作(すなわち、LOCKかLOCKU)をLOCKタイプして、その後のOPENsとオープン_DOWNGRADEsによるstateid系列を始めた元のオープンであり、変更されているのと同じくらい確立したファイル(すなわち、READ、WRITE、またはREAD- WRITE)のためにそのstateid系列の中でアクセス・モードを定義します。 READ(サイズ属性を指定するWRITE、またはSETATTR)が完了しているとき、確かめるアクセス・モードに対して操作が関連しているオープンを考えて、操作が適切であることをチェックするのを操作は受けることがあります。
In the case of WRITE-type operations (i.e., WRITEs and SETATTRs which set size), the server must verify that the access mode allows writing and return an NFS4ERR_OPENMODE error if it does not. In the case, of READ, the server may perform the corresponding check on the access mode, or it may choose to allow READ on opens for WRITE only, to accommodate clients whose write implementation may unavoidably do
WRITE-タイプ操作(すなわち、WRITEsとサイズを設定するSETATTRs)の場合では、返さないなら、サーバは、アクセス・モードが、書くのを許容することを確かめて、NFS4ERR_OPENMODE誤りを返さなければなりません。 READでは、サーバが場合では、アクセス・モードに対応するチェックを実行するかもしれないか、またはREADを許容するのを選ぶかもしれない、オンである、WRITEだけのためにクライアントを収容するために開く、だれのもの、書く、実装はやむを得ずするかもしれません。
Shepler, et al. Standards Track [Page 72] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[72ページ]RFC3530NFSバージョン4 プロトコル2003年4月
reads (e.g., due to buffer cache constraints). However, even if READs are allowed in these circumstances, the server MUST still check for locks that conflict with the READ (e.g., another open specify denial of READs). Note that a server which does enforce the access mode check on READs need not explicitly check for conflicting share reservations since the existence of OPEN for read access guarantees that no conflicting share reservation can exist.
読書(例えば、バッファキャッシュ規制による)。 しかしながら、READsがこういう事情ですから許容されていても、サーバは錠がないかどうかまだREADとのその衝突をチェックしなければなりません(例えば、別の戸外はREADsの否定を指定します)。 アクセス保証が読まれる場合その闘争していないシェアの予約が存在できるのでREADsのモードチェックが闘争するのがないかどうか明らかにチェックする必要はないアクセスを実施するサーバがオープンの存在以来の予約を共有することに注意してください。
A stateid of all bits 1 (one) MAY allow READ operations to bypass locking checks at the server. However, WRITE operations with a stateid with bits all 1 (one) MUST NOT bypass locking checks and are treated exactly the same as if a stateid of all bits 0 were used.
サーバでチェックをロックして、すべてのビット1(1)のstateidは迂回させる操作をREADに許すかもしれません。まるですべてのビット0のstateidが使用されるかのように、しかしながら、1(1)ビットがあるstateidとのWRITE操作は、ロックチェックを迂回させてはいけなくて、まさに同じように扱われます。
A lock may not be granted while a READ or WRITE operation using one of the special stateids is being performed and the range of the lock request conflicts with the range of the READ or WRITE operation. For the purposes of this paragraph, a conflict occurs when a shared lock is requested and a WRITE operation is being performed, or an exclusive lock is requested and either a READ or a WRITE operation is being performed. A SETATTR that sets size is treated similarly to a WRITE as discussed above.
錠は特別なstateidsの1つを使用するREADかWRITE操作がREADかWRITE操作の範囲とのロック要求闘争の実行されて、範囲である間、与えられないかもしれません。 共有された錠が要求されていて、WRITE操作が実行されているか、排他的な錠が要求されていて、またはREADかWRITE操作のどちらかが実行されているとき、このパラグラフの目的のために、闘争は起こります。 サイズを設定するSETATTRは上で議論するように同様にWRITEに扱われます。
8.1.5. Sequencing of Lock Requests
8.1.5. ロック要求の配列
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 lock_owners have different sequences. The server maintains the last sequence number (L) received and the response that was returned. The first request issued for any given lock_owner is issued with a sequence number of zero.
ロックが必要であるようにほとんどのNFS操作と異なっている、「-、だいたいの1つ、」 意味論はONCRPCを提供しませんでした。 ロック要求の系列が複数のTCP接続にかかるかもしれないので、信頼できる輸送の上のONCRPCは十分ではありません。 「再-トランスミッション」か再命令に直面して、錠かアンロック要求には、よく定義されて、一貫した振舞いがなければなりません。 これを達成するために、それぞれのロック要求は連続して増加する整数である一連番号を含んでいます。 異なった錠_所有者には、異なった系列があります。 サーバは(L)が受けた最後の一連番号と返された応答を維持します。 どんな与えられた錠_所有者のためにも出された最初の要求はゼロの一連番号で出されます。
Note that for requests that contain a sequence number, for each lock_owner, there should be no more than one outstanding request.
一連番号を含む要求、各錠_所有者のために、1つ未満の傑出している要求があるべきであることに注意してください。
If a request (r) 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 SETCLIENTID/SETCLIENTID_CONFIRM sequence changes the client verifier.
前の一連番号(r<L)がある要求(r)が受信されているなら、それは誤りNFS4ERR_BAD_SEQIDの復帰で拒絶されます。 適切に機能しているクライアントを考えて、最後の要求(L)を送る前に(r)への応答を受けたに違いありません。 最後の要求(r=L)の写しが受け取られているなら、保存された応答を返します。 次の系列(r=L+2)を超えた要求が受信されているなら、それは誤りNFS4ERR_BAD_SEQIDの復帰で拒絶されます。 SETCLIENTID/SETCLIENTID_CONFIRM系列がクライアント検証を変えるときはいつも、系列歴史は再初期化されます。
Shepler, et al. Standards Track [Page 73] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[73ページ]RFC3530NFSバージョン4 プロトコル2003年4月
Since the sequence number is represented with an unsigned 32-bit integer, the arithmetic involved with the sequence number is mod 2^32. For an example of modulo arithmetic involving sequence numbers see [RFC793].
一連番号が未署名の32ビットの整数で表されるので、一連番号にかかわる演算はモッズ風の2^32です。 一連番号にかかわるモジュロ演算の例に関しては、[RFC793]を見てください。
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 lock_owner must be cached as long as the lock state exists on the server.
それは重要です。サーバは、最後の応答が写し非ベキ等元要求の、より信頼できるキャッシュを提供するために[Juszczak]で説明された伝統的なキャッシュのものよりクライアントに発信したと主張します。 伝統的な写し要求キャッシュは、不要な要求を取り除くのに最も最近でない中古のアルゴリズムを使用します。 しかしながら、ロック状態がサーバに存在している限り、与えられた錠_所有者における最後のロック要求と応答をキャッシュしなければなりません。
The client MUST monotonically increment the sequence number for the CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE operations. This is true even in the event that the previous operation that used the sequence number received an error. The only exception to this rule is if the previous operation received one of the following errors: NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID, NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR, NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE.
クライアントはCLOSE、LOCK、LOCKU、オープン、オープン_CONFIRM、およびオープン_DOWNGRADE操作のために一連番号を単調に増加しなければなりません。 一連番号を使用した古い手術痕が誤りを受けさえしたなら、これは本当です。 この規則への唯一の例外は古い手術痕が以下の誤りの1つを受け取ったかどうかということです: _の聞き古した_NFS4ERR CLIENTID、_の聞き古した_NFS4ERR STATEID、_の悪い_NFS4ERR STATEID、_の悪い_NFS4ERR SEQID、NFS4ERR_BADXDR、NFS4ERR_リソース、NFS4ERR_NOFILEHANDLE。
8.1.6. Recovery from Replayed Requests
8.1.6. 再演された要求からの回復
As described above, the sequence number is per lock_owner. 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 (lock_owner, sequence number) state as long as there are open files or closed files with locks outstanding.
上で説明されるように、一連番号が錠_所有者単位であります。 サーバが、最後の一連番号が上で説明されたメソッドを受けて、従うと主張する限り、古い要求を再送する込み入ったルータのリスクが全くありません。 オープン・ファイルか錠が傑出しているメガネ・ファイルがある限り、サーバは(_所有者をロックしてください、一連番号)状態を維持するだけでよいです。
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 lock_owner state.
したがって、LOCK、LOCKU、オープン、オープン_DOWNGRADE、およびそれぞれCLOSEは一連番号を含んでいて、サーバは錠_所有者状態を維持しますが、望まれない効果をもたらすこれらの操作の再生のリスクは実在しません。
8.1.7. Releasing lock_owner State
8.1.7. ロック_所有者州をリリースします。
When a particular lock_owner no longer holds open or file locking state at the server, the server may choose to release the sequence number state associated with the lock_owner. 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 lock_owner no longer is being utilized by the client. The server may choose to hold the lock_owner state in the event that retransmitted requests are received. However, the period to hold this state is implementation specific.
特定の錠_所有者がもうサーバで戸外かファイルのロック状態を保持しないとき、サーバは、錠_所有者に関連している一連番号状態をリリースするのを選ぶかもしれません。 サーバはリース満了に基づくこの選択をするかもしれません、サーバメモリ、または他の実装の特定の詳細の改善のために。 とにかく、サーバは錠_所有者であるときにだけ安全にこれができるのが、もうクライアントによって利用しないことにされるのであるということです。 再送された要求が受信されている場合、サーバは、錠_所有者状態を保持するのを選ぶかもしれません。 しかしながら、この状態を保持する期間は実装特有です。
Shepler, et al. Standards Track [Page 74] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[74ページ]RFC3530NFSバージョン4 プロトコル2003年4月
In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is retransmitted after the server has previously released the lock_owner state, the server will find that the lock_owner has no files open and an error will be returned to the client. If the lock_owner does have a file open, the stateid will not match and again an error is returned to the client.
サーバが以前に錠_所有者状態をリリースした後にLOCK、LOCKU、オープン_DOWNGRADE、またはCLOSEが再送されて、サーバは、錠_所有者がファイルを全く開かせないのがわかるでしょう、そして、誤りはクライアントに返されるでしょう。 錠_所有者がファイルを開かせると、stateidは合わないでしょう、そして、一方、誤りはクライアントに返されます。
8.1.8. Use of Open Confirmation
8.1.8. 開いている確認の使用
In the case that an OPEN is retransmitted and the lock_owner is being used for the first time or the lock_owner 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 lock_owner 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 lock_owner and associated sequence number. Since the OPEN_CONFIRM sequence connects a new open_owner on the server with an existing open_owner on a client, the sequence number may have any value. The OPEN_CONFIRM step assures the server that the value received is the correct one. See the section "OPEN_CONFIRM - Confirm Open" for further details.
オープンが再送されて、錠_所有者が初めて、使用されているか、または錠_所有者状態が以前にサーバによってリリースされて、オープン_CONFIRM操作の使用は不正確な振舞いを防ぐでしょう。 サーバが初めて錠_所有者の使用を観測するとき、それは、_オープンCONFIRMを対応するオープンに実行するようクライアントに指示するでしょう。 この系列はロック_所有者と関連一連番号の使用を確立します。 オープン_CONFIRM系列がクライアントの上の既存のオープンな_所有者と共に新しいオープンな_所有者をサーバに接続するので、一連番号には、どんな値もあるかもしれません。 オープン_CONFIRMステップは、対価領収が正しい方であることをサーバに保証します。 詳細のための「_が確認する戸外--開くように確認してください」というセクションを見てください。
There are a number of situations in which the requirement to confirm an OPEN would pose difficulties for the client and server, in that they would be prevented from acting in a timely fashion on information received, because that information would be provisional, subject to deletion upon non-confirmation. Fortunately, these are situations in which the server can avoid the need for confirmation when responding to open requests. The two constraints are:
オープンを確認するという要件がクライアントとサーバのために困難を引き起こす多くの状況があります、それらは直ちに非確認の削除を条件としてその情報が暫定的でしょう、したがって、受け取られた情報に影響するのが防がれるでしょう、したがって。 幸い、これらは要求を開くために応じるときサーバが確認の必要性を避けることができる状況です。 2つの規制は以下の通りです。
o The server must not bestow a delegation for any open which would
require confirmation.
o サーバは確認を必要とするどんな戸外にも委譲を与えてはいけません。
o The server MUST NOT require confirmation on a reclaim-type open
(i.e., one specifying claim type CLAIM_PREVIOUS or
CLAIM_DELEGATE_PREV).
o サーバはタイプを取り戻している戸外の上で確認を必要としてはいけません(すなわち、1つが_クレームタイプクレーム_PREVIOUSかクレームDELEGATE_PREVを指定して)。
These constraints are related in that reclaim-type opens are the only ones in which the server may be required to send a delegation. For CLAIM_NULL, sending the delegation is optional while for CLAIM_DELEGATE_CUR, no delegation is sent.
これらの規制がそれでタイプを取り戻して関係づけられる、開き、サーバが委譲を送るのに必要であるかもしれない唯一のものがそうです。 クレーム_NULLに関しては、クレーム_DELEGATE_CURに関して委譲を全く送りませんが、委譲を送るのは任意です。
Delegations being sent with an open requiring confirmation are troublesome because recovering from non-confirmation adds undue complexity to the protocol while requiring confirmation on reclaim- type opens poses difficulties in that the inability to resolve
非確認から回復するのが確認を必要としている間、過度の複雑さをプロトコルに追加するので開いている必要さ確認と共に送るのが厄介である委譲がタイプを取り戻す、開き、それにおける困難に決議する無能を引き起こします。
Shepler, et al. Standards Track [Page 75] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[75ページ]RFC3530NFSバージョン4 プロトコル2003年4月
the status of the reclaim until lease expiration may make it difficult to have timely determination of the set of locks being reclaimed (since the grace period may expire).
状態、開墾される錠のセットのタイムリーな決断を持っているのがリース満了で難しくなるかもしれないまで(据置期間が期限が切れるかもしれないので)、開墾します。
Requiring open confirmation on reclaim-type opens is avoidable because of the nature of the environments in which such opens are done. For CLAIM_PREVIOUS opens, this is immediately after server reboot, so there should be no time for lockowners to be created, found to be unused, and recycled. For CLAIM_DELEGATE_PREV opens, we are dealing with a client reboot situation. A server which supports delegation can be sure that no lockowners for that client have been recycled since client initialization and thus can ensure that confirmation will not be required.
タイプを取り戻すことにおける開いている確認が開く必要さはそのようなものが開く環境の本質で回避可能です。します。 PREVIOUSが開くクレーム_に関しては、これがサーバリブート直後あるので、lockownersが作成されて、未使用であることがわかっていて、再生される時間が全くあるべきではありません。 PREVが開くクレーム_DELEGATE_に関しては、私たちはクライアントリブート状況に対処しています。 委譲をサポートするサーバは、クライアント初期化以来そのクライアントのためのlockownersが全く再生されていないのを確信している場合があって、その結果、確認は必要でないことを確実にすることができます。
8.2. Lock Ranges
8.2. ロック範囲
The protocol allows a lock owner to request a lock with a 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 filesystems 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.
プロトコルで、次に、ロック所有者は、初期の錠のサブ範囲をバイト範囲がある錠を要求して、アップグレードするか、またはアンロックします。 これが珍しいタイプの要求になると予想されます。 どのような場合でも、サーバかサーバファイルシステムがサブ範囲ロック意味論をサポートすることができないかもしれません。 サーバがロック所有者のために現在のロック状態のサブ範囲を表すロック要求を受け取る場合、サーバは、サブ範囲ロック操作をサポートしないのを意味するように誤り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.
クライアントはサーバがサブ範囲要求をサポートしないかもしれないのでたまたまただ一つの要求に隣接している範囲をロックする複数の独立者を結合して、ファイルのロック状態のサーバ失敗の場合、回復に関連する理由でがっかりしています。 以下の「サーバ失敗と回復」というセクションで議論するように、サーバは回復の間のロック回復の間のクライアントの振舞いがクライアントがサーバ失敗の前に振舞いをロックするのと同様であるときにだけ力を発揮するある最適化を使うかもしれません。
8.3. Upgrading and Downgrading Locks
8.3. 錠をアップグレードして、格下げします。
If a client has a write lock on a record, it can request an atomic downgrade of the lock to a read lock via the LOCK request, by setting the type to READ_LT. If the server supports atomic downgrade, the request will succeed. If not, it will return NFS4ERR_LOCK_NOTSUPP. The client should be prepared to receive this error, and if appropriate, report the error to the requesting application.
クライアントがaに記録に錠を書かせるなら、LOCK要求で錠の原子ダウングレードを読書錠に要求できます、READ_LTにタイプを設定することによって。 サーバが原子ダウングレードをサポートすると、要求は成功するでしょう。 そうでなければ、それはNFS4ERR_LOCK_NOTSUPPを返すでしょう。 クライアントはこの誤りを受ける用意ができているべきです、そして、適切であるなら、要求アプリケーションに誤りを報告してください。
Shepler, et al. Standards Track [Page 76] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[76ページ]RFC3530NFSバージョン4 プロトコル2003年4月
If a client has a read lock on a record, it can request an atomic upgrade of the lock to a write lock via the LOCK request by setting the type to WRITE_LT or WRITEW_LT. If the server does not support atomic upgrade, it will return NFS4ERR_LOCK_NOTSUPP. If the upgrade can be achieved without an existing conflict, the request will succeed. Otherwise, the server will return either NFS4ERR_DENIED or NFS4ERR_DEADLOCK. The error NFS4ERR_DEADLOCK is returned if the client issued the LOCK request with the type set to WRITEW_LT and the server has detected a deadlock. The client should be prepared to receive such errors and if appropriate, report the error to the requesting application.
クライアントが記録に読書錠を持っているなら、それは、aへの錠の原子アップグレードがWRITE_LTかWRITEW_LTにタイプを設定するのによるLOCK要求で錠を書くよう要求できます。 サーバが原子アップグレードをサポートしないと、それはNFS4ERR_LOCK_NOTSUPPを返すでしょう。 既存の闘争なしでアップグレードを達成できると、要求は成功するでしょう。 さもなければ、サーバはNFS4ERR_DENIEDかNFS4ERR_DEADLOCKのどちらかを返すでしょう。 LOCK要求がタイプで出されたクライアントがWRITEW_LTにセットして、サーバが行き詰まりを検出したなら、誤りNFS4ERR_DEADLOCKを返します。 クライアントはそのような誤りを受ける用意ができているべきです、そして、適切であるなら、要求アプリケーションに誤りを報告してください。
8.4. Blocking Locks
8.4. 錠を妨げます。
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、2つの新しいロックタイプが加えられる、クライアントがブロッキング錠を要求しているのをサーバに示すために、使用されます。 サーバは未定のブロッキング錠の規則正しいリストを維持するべきです。 闘争錠がリリースされるとき、サーバは錠を再要求する最初の待ちクライアントのためにリースの期間を待つかもしれません。 リースの期間が期限が切れた後に、錠は次の待ちクライアント要求に許容されています。 間隔を置いて、クライアントは十分小さく投票しなければなりません。それは直ちに錠を入手しそうです。 サーバは、それが正しい操作ではなく、公正を増強するのに使用されるとき未定の妨げられた錠のリストを維持するのに必要ではありません。 速成の回復の順不同の本質のために、安定貯蔵へのロック状態の保存が、ブロッキング錠を命令された与えることを保証するのに必要でしょう。
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.
また、サーバは闘争錠がリリースされる延長時間を許容するという要求の拒絶を返すロックタイプと遅れに注意するかもしれません、うまくいっているリターンを許容して。 このように、クライアントは錠を妨げるための不必要に頻繁な世論調査の負担を避けることができます。 サーバは、イベントにおける、遅れの長さでクライアントが要求を再送することに注意するべきです。
8.5. Lease Renewal
8.5. リース更新
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.
リースの目的は、サーバがダウンしたクライアントによって持たれている聞き古した錠を取り外すのを許容するためにあるか、またはそうでなければ、手が届きません。 それはキャッシュの一貫性のためのメカニズムではありません、そして、リース間隔が期限が切れていないなら、リース更新は否定されないかもしれません。
Shepler, et al. Standards Track [Page 77] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[77ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
o 有効なclientidとのオープン。
o Any operation made with a valid stateid (CLOSE, DELEGPURGE,
DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE,
READ, RENEW, SETATTR, WRITE). This does not include the special
stateids of all bits 0 or all bits 1.
o どんな操作も有効なstateidで(CLOSE、DELEGPURGE、DELEGRETURN、LOCK、LOCKU、オープン、オープン_CONFIRM、オープン_DOWNGRADE、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/SETCLIENTID_CONFIRM sequence. The use of the
SETCLIENTID/SETCLIENTID_CONFIRM sequence (one that changes the
client verifier) notifies the server to drop the locking state
associated with the client. SETCLIENTID/SETCLIENTID_CONFIRM never
renews a lease.
クライアントがクライアントが再開したか、またはリブートしたなら、SETCLIENTID/SETCLIENTID_CONFIRM系列を発行しないでこれらの要求をしていないことに注意してください。 SETCLIENTID/SETCLIENTID_CONFIRM系列(クライアント検証を変えるもの)の使用は、サーバがクライアントに関連しているロック状態を下げるように通知します。 SETCLIENTID/SETCLIENTID_CONFIRMは決して借地契約を更新しません。
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呼び出しもリース更新に必要ではありません、そして、最悪の場合には1RPCがいつもリースの期間(すなわち、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.
また、新しいリースを作成するすべての操作が既存のリースを更新するので、サーバは与えられたクライアントのためにすべての有効なリースのための一般的なリース満了時間を維持しなければなりません。 そして、暗黙のリース更新動作のときに容易にこのリース時間をアップデートできます。
8.6. Crash Recovery
8.6. クラッシュリカバリ
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.
速成の回復における重要な要件はクライアントとサーバの両方が、もう片方がいつ失敗したかを知っているということです。 さらに、クライアントが、サーバの向こう側の一貫したデータに対する所見が再開するか、またはリブートされるのを見るのが必要です。 クライアントが首尾よくREADとWRITE操作を保護する錠を回収するまで、クライアントかネットワーク・バッファの中に列に並ばせられたかもしれないすべてのREADとWRITE操作は待たなければなりません。
Shepler, et al. Standards Track [Page 78] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[78ページ]RFC3530NFSバージョン4 プロトコル2003年4月
8.6.1. Client Failure and Recovery
8.6.1. クライアント失敗と回復
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 clientid 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の使用を確認します。 そして、不透明な所有者分野と組み合わせたclientidは、ロック所有者をオープンに特定するのにクライアントによって使用されます。 そして、協会のこのチェーンは、特定のクライアントのためにすべての錠を特定するのに使用されます。
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に関連しているすべてをリリースできます。
Note that the verifier must have the same uniqueness properties of the verifier for the COMMIT operation.
検証にはCOMMIT操作のための検証の同じユニークさの特性がなければならないことに注意してください。
8.6.2. Server Failure and Recovery
8.6.2. サーバ失敗と回復
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とWRITE操作を禁じなければなりません。 この回復の期間の持続時間はリースの期間の持続時間と等しいです。
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
クライアントは、サーバ失敗(そして、その結果、ロック状態の損失)が起こったと決心できます、2つの誤りの1つを受け取るとき。 NFS4ERR_STALE_STATEID誤りはリブートか再開で無効にされたstateidを示します。 NFS4ERR_STALE_CLIENTID誤りはaを示します。
Shepler, et al. Standards Track [Page 79] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[79ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
リブートか再開で無効にされた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.
ロック、READs、およびWRITEsの特別な取り扱いの持続時間においてリースの期間と等しい一区切りは「据置期間」と呼ばれます。 据置期間の間、クライアントがタイプを取り戻しているロック要求で錠と準国家を回収する、(すなわち、LOCK要求、開墾、クレーム_PREVIOUSのクレームタイプとの本当、そして、オープン操作へのセット) そして、据置期間の間、サーバがREADとWRITE操作を拒絶しなければならない、非、開墾、ロックはNFS4ERR_グレースの誤りで(すなわち、他のLOCKとオープン操作)を要求します。
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.
クライアント要求を取り戻してください。そして、サーバがaを与えながらそれを確かに決定できる、非、開墾、要求は他のクライアントによる錠の再生と衝突しないでしょう、返すために誤りにはないNFS4ERR_グレース、非、修理できます。 サーバが据置期間の間、READとWRITE操作を調整できます、再びどんな可能な闘争も迫ることの間に起こることができなかったのを保証できなければならないということであるには、要求をロックして、READかWRITE操作を取り戻してください。 サーバがその保証を提供できないなら、NFS4ERR_グレース誤りをクライアントに返さなければなりません。
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_グレース誤りを返すことによって、要求、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.
例えば、当然のことのファイルにおける錠のカウントが利用可能であるなら安定貯蔵、ファイルといつの間の缶の道の開墾された錠がすべて、取り戻すサーバでは、処理されてください、そうした、非、開墾、要求をロックするのは処理されるかもしれません。 サーバがそれを確実にすることができるこの方法、非、開墾、要求をロックして、可能性との闘争は要求を取り戻さないでしょうか? サーバがそこでそれを決定できるのが、未払いのノーであるということであるなら、入出力要求に関して、安定貯蔵か別の同様のメカニズム(通常、要求がファイルのために続かせることができた入出力の処理)からの情報でファイルに関する要求を取り戻してください。
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.
それが許容するサーバのために繰り返す、非、開墾、据置期間の間に処理されるという錠と入出力要求、それは次に開墾されなかった錠が全く拒絶されて、次に開墾されなかった錠が全く据置期間の間に処理されたどんな入出力操作も防いだことを決定しなければなりません。
Shepler, et al. Standards Track [Page 80] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[80ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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 issue is included in [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.
クライアントがNFS4ERR_グレース誤りの復帰のために用意ができているべきである、非、開墾、錠と入出力要求。 この場合、クライアントは要求に再試行メカニズムを使うべきです。 再試行の間の遅れ(数秒の注文での)は、サーバを圧倒するのを避けるのに使用されるべきです。一般答弁のさらなる議論は[フロイド]に含まれています。 そして、クライアントが入出力を実行できるサーバを説明しなければならない、非、開墾、ロックは、それらと同様に据置期間中にそれがそうできないよう要求します。
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.
サーバがリブート以来どんな闘争錠も入出力要求も承諾されていないのを保証するか、または再開できる場合にだけ、サーバの据置期間のタイプを取り戻しているロック要求は成功できます。
A server may, upon restart, establish a new value for the lease period. Therefore, clients should, once a new clientid is established, refetch the lease_time attribute and use it as the basis for lease renewal for the lease associated with that server. However, the server must establish, for this restart event, a grace period at least as long as the lease period for the previous server instantiation. This allows the client state obtained during the previous server instance to be reliably re-established.
再開のときに、サーバはリースの期間のための新しい値を確立するかもしれません。 そのサーバに関連しているリースにリース更新の基礎としてそれを結果と考えて、使用してください。したがって、新しいclientidが一度設立されて、クライアントはそうするべきであり、「再-フェッチ」はサーバがしかしながら、これに関して、イベント(前のサーバ具体化のためのリースの期間としての少なくとも同じくらい長い据置期間)を再開するように証明しなければならないリース_時です。 これは、前のサーバインスタンスの間に得られた属国が確かに復職するのを許容します。
8.6.3. Network Partitions and Recovery
8.6.3. ネットワークパーティションと回復
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が無効であるか聞き古したであるなるでしょう。 クライアントがそのようなネットワークパーティションの後にいったんサーバに達することができると、サーバが誤りNFS4ERR_EXPIREDを返していて、現在無効のstateidsでクライアントによって提出されたすべての入出力が失敗するでしょう。 この誤りがいったん受け取られているようになると、クライアントは適当に錠を支えたアプリケーションに通知するでしょう。
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.
クライアントへの礼儀として、または、最適化として、サーバは、最近のコミュニケーションがリースの期間に広がったクライアントを代表して錠を持ち続けるかもしれません。 サーバがこれらの礼儀錠の1つと衝突する錠か入出力要求を受け取るなら、サーバは、礼儀錠を解放して、新しい要求を承諾しなければなりません。
When a network partition is combined with a server reboot, there are edge conditions that place requirements on the server in order to avoid silent data corruption following the server reboot. Two of these edge conditions are known, and are discussed below.
ネットワークパーティションがサーバリブートに結合されるとき、サーバリブートに続いて、静かなデータの汚染を避けるためにサーバに要件を置く周辺条件があります。 これらの2つの周辺条件について、知られていて、以下で議論します。
Shepler, et al. Standards Track [Page 81] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[81ページ]RFC3530NFSバージョン4 プロトコル2003年4月
The first edge condition has the following scenario:
最初の周辺条件に、以下のシナリオがあります:
1. Client A acquires a lock.
1. クライアントAは錠を入手します。
2. Client A and server experience mutual network partition, such
that client A is unable to renew its lease.
2. クライアントAとサーバが互いのネットワークパーティションになるので、クライアントAはリースを更新できません。
3. Client A's lease expires, so server releases lock.
3. クライアントAのリースが期限が切れるので、サーバリリースはロックされます。
4. Client B acquires a lock that would have conflicted with that
of Client A.
4. クライアントBはClient Aのものと衝突した錠を入手します。
5. Client B releases the lock
5. クライアントBは錠をリリースします。
6. Server reboots
6. サーバリブート
7. Network partition between client A and server heals.
7. クライアントAとサーバの間のネットワークパーティションは回復します。
8. Client A issues a RENEW operation, and gets back a
NFS4ERR_STALE_CLIENTID.
8. クライアントAは、RENEW操作を発行して、NFS4ERR_STALE_CLIENTIDを取り戻します。
9. Client A reclaims its lock within the server's grace period.
9. クライアントAはサーバの据置期間中に錠を開墾します。
Thus, at the final step, the server has erroneously granted client A's lock reclaim. If client B modified the object the lock was protecting, client A will experience object corruption.
したがって、最終的なステップでは、サーバは誤ってAの錠が開墾するクライアントを与えました。 クライアントBが錠が保護していたオブジェクトを変更したなら、クライアントAはオブジェクト不正を経験するでしょう。
The second known edge condition follows:
第2知られている周辺条件は続きます:
1. Client A acquires a lock.
1. クライアントAは錠を入手します。
2. Server reboots.
2. サーバはリブートされます。
3. Client A and server experience mutual network partition, such
that client A is unable to reclaim its lock within the grace
period.
3. クライアントAとサーバは互いのネットワークパーティションになります、クライアントAが据置期間中に錠を開墾できないように。
4. Server's reclaim grace period ends. Client A has no locks
recorded on server.
4. サーバのものは据置期間の終わりを取り戻します。 クライアントAは錠を全くサーバに記録させません。
5. Client B acquires a lock that would have conflicted with that
of Client A.
5. クライアントBはClient Aのものと衝突した錠を入手します。
6. Client B releases the lock.
6. クライアントBは錠をリリースします。
7. Server reboots a second time.
7. サーバはもう一度、リブートされます。
8. Network partition between client A and server heals.
8. クライアントAとサーバの間のネットワークパーティションは回復します。
Shepler, et al. Standards Track [Page 82] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[82ページ]RFC3530NFSバージョン4 プロトコル2003年4月
9. Client A issues a RENEW operation, and gets back a
NFS4ERR_STALE_CLIENTID.
9. クライアントAは、RENEW操作を発行して、NFS4ERR_STALE_CLIENTIDを取り戻します。
10. Client A reclaims its lock within the server's grace period.
10. クライアントAはサーバの据置期間中に錠を開墾します。
As with the first edge condition, the final step of the scenario of the second edge condition has the server erroneously granting client A's lock reclaim.
最初の周辺条件のように、第2周辺条件のシナリオの最終的なステップには誤ってクライアントAの錠を与えると取り戻されるサーバがあります。
Solving the first and second edge conditions requires that the server either assume after it reboots that edge condition occurs, and thus return NFS4ERR_NO_GRACE for all reclaim attempts, or that the server record some information stable storage. The amount of information the server records in stable storage is in inverse proportion to how harsh the server wants to be whenever the edge conditions occur. The server that is completely tolerant of all edge conditions will record in stable storage every lock that is acquired, removing the lock record from stable storage only when the lock is unlocked by the client and the lock's lockowner advances the sequence number such that the lock release is not the last stateful event for the lockowner's sequence. For the two aforementioned edge conditions, the harshest a server can be, and still support a grace period for reclaims, requires that the server record in stable storage information some minimal information. For example, a server implementation could, for each client, save in stable storage a record containing:
いくらかの情報安定貯蔵に1日と周辺条件が、どちらかが周辺条件が現れるのがリブートされた後に仮定して、その結果すべてのためにNFS4ERR_いいえ_グレースを返すサーバが試みを取り戻すのを必要とするか、またはサーバが記録する秒を解決します。 サーバが安定貯蔵に記録する情報量がどれくらい厳しいことに反比例してあるか。周辺条件が現れるときはいつも、サーバはそうしたがっていること。 すべての周辺条件において完全に許容性があるサーバはあらゆる後天的な錠を安定貯蔵に記録するでしょう、クライアントが錠の錠を開いていて、錠のlockownerが一連番号を進めるときだけ、安定貯蔵からロック記録を取り除いてロックリリースはlockownerの系列のための最後のstatefulイベントではありません。 2つの前述の周辺条件、最も厳しい、サーバがあって、サポートa据置期間を静めることができる開墾、サーバが何らかの最小量の情報を安定貯蔵情報に記録するのが必要です。 例えば、各クライアントのために、サーバ実装は安定貯蔵に以下を含む記録を保存するかもしれません。
o the client's id string
o クライアントのイドストリング
o a boolean that indicates if the client's lease expired or if there
was administrative intervention (see the section, Server
Revocation of Locks) to revoke a record lock, share reservation,
or delegation
o 記録的な錠、シェアの予約、または委譲を取り消すためにクライアントのリースが期限が切れたかどうか、または管理介入があったかどうかを(セクションを見てください、LocksのServer Revocation)示す論理演算子
o a timestamp that is updated the first time after a server boot or
reboot the client acquires record locking, share reservation, or
delegation state on the server. The timestamp need not be updated
on subsequent lock requests until the server reboots.
o サーバで予約、または委譲状態を共有してください。サーバブーツかリブートのクライアントが入手する後1回目にロックしながら記録的にアップデートされるタイムスタンプ、サーバがリブートされるまで、その後のロック要求のときにタイムスタンプをアップデートする必要はありません。
The server implementation would also record in the stable storage the timestamps from the two most recent server reboots.
また、サーバ実装は最新のサーバがリブートする2からタイムスタンプを安定貯蔵に記録するでしょう。
Assuming the above record keeping, for the first edge condition, after the server reboots, the record that client A's lease expired means that another client could have acquired a conflicting record lock, share reservation, or delegation. Hence the server must reject a reclaim from client A with the error NFS4ERR_NO_GRACE.
サーバがリブートされた後に最初の周辺条件のために取られる上記の記録を仮定して、クライアントAのリースが期限が切れたという記録は、別のクライアントが闘争の記録的な錠、シェアの予約、または委譲を入手したかもしれないことを意味します。 したがって、サーバはaを拒絶しなければなりません。_クライアントAからの誤りNFS4ERRに伴う_グレースを全く開墾しないでください。
Shepler, et al. Standards Track [Page 83] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[83ページ]RFC3530NFSバージョン4 プロトコル2003年4月
For the second edge condition, after the server reboots for a second time, the record that the client had an unexpired record lock, share reservation, or delegation established before the server's previous incarnation means that the server must reject a reclaim from client A with the error NFS4ERR_NO_GRACE.
サーバの前の肉体化が、サーバがaを拒絶しなければならないと言う前に確立されたサーバがもう一度リブートされた後に第2縁の状態、クライアントが満期になっていない記録的な錠を持っていたという記録、シェアの予約、または委譲には、_クライアントAからの誤りNFS4ERRに伴う_グレースを全く開墾しないでください。
Regardless of the level and approach to record keeping, the server MUST implement one of the following strategies (which apply to reclaims of share reservations, record locks, and delegations):
キープを記録するレベルとアプローチにかかわらずサーバが以下の戦略の1つを実装しなければならない、(申し込む、取り戻す、シェアの予約、記録的な錠、および委譲を)、:
1. Reject all reclaims with NFS4ERR_NO_GRACE. This is superharsh,
but necessary if the server does not want to record lock state
in stable storage.
1. すべてがNFS4ERR_いいえ_グレースと共に開墾する廃棄物。 サーバがロック状態を安定貯蔵に記録したくないなら、これが、superharshであって、しかし、必要です。
2. Record sufficient state in stable storage such that all known
edge conditions involving server reboot, including the two
noted in this section, are detected. False positives are
acceptable. Note that at this time, it is not known if there
are other edge conditions.
2. サーバリブートにかかわるすべての知られている周辺条件、このセクションで2が注意した包含が検出されるように、十分な状態を安定貯蔵に記録してください。 無病誤診は許容できます。 このときそれに注意してください、そして、他の周辺条件があれば、それは知られていません。
In the event, after a server reboot, the server determines that
there is unrecoverable damage or corruption to the the stable
storage, then for all clients and/or locks affected, the server
MUST return NFS4ERR_NO_GRACE.
イベントでは、サーバリブートの後に、サーバは、安定貯蔵への復しない損害か不正があると決心して、クライアント、そして/または、錠が影響した限り、次に、サーバはいいえ_グレースをNFS4ERR_に返さなければなりません。
A mandate for the client's handling of the NFS4ERR_NO_GRACE error is outside the scope of this specification, since the strategies for such handling are very dependent on the client's operating environment. However, one potential approach is described below.
この仕様の範囲の外にクライアントのNFS4ERR_いいえ、_グレース誤りの取り扱いのための命令があります、そのような取り扱いのための戦略がクライアントの操作環境に非常に依存しているので。 しかしながら、1つのポテンシャル法が以下で説明されます。
When the client receives NFS4ERR_NO_GRACE, it could examine the change attribute of the objects the client is trying to reclaim state for, and use that to determine whether to re-establish the state via normal OPEN or LOCK requests. This is acceptable provided the client's operating environment allows it. In otherwords, the client implementor is advised to document for his users the behavior. The client could also inform the application that its record lock or share reservations (whether they were delegated or not) have been lost, such as via a UNIX signal, a GUI pop-up window, etc. See the section, "Data Caching and Revocation" for a discussion of what the client should do for dealing with unreclaimed delegations on client state.
クライアントがNFS4ERR_いいえ_グレースを受けるとき、それは、クライアントが状態を取り戻そうとしているオブジェクトの変化属性を調べて、通常のオープンかLOCK要求で状態を復職させるかどうか決定するのにそれを使用するかもしれません。 クライアントの操作環境がそれを許容するなら、これは許容できます。 otherwordsでは、クライアント作成者が彼のユーザのために振舞いを記録するようにアドバイスされます。 また、クライアントは、その記録的な錠かシェア条件(それらを代表として派遣したか否かに関係なく)がなくされたことをアプリケーションに知らせることができました、UNIX信号、GUIポップアップウィンドウなどで セクションと、クライアントが非開墾された委譲に対処するために属国でするべきであることに関する議論のための「データキャッシュと取消し」を見てください。
For further discussion of revocation of locks see the section "Server Revocation of Locks".
錠の取消しのさらなる議論に関しては、「錠のサーバ取消し」というセクションを見てください。
Shepler, et al. Standards Track [Page 84] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[84ページ]RFC3530NFSバージョン4 プロトコル2003年4月
8.7. Recovery from a Lock Request Timeout or Abort
8.7. ロック要求タイムアウトかアボートからの回復
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 lock_owner. This is straightforward to do without a special re- synchronize operation.
イベントaロック要求回数のときに、外では、クライアントは、要求を再試行しないと決めるかもしれません。 また、それが発行されたプロセスが終えられるとき(例えば、信号によるUNIXの)、クライアントは要求を中止するかもしれません。 もっとも、サーバが要求を受け取って、それに作用したのは、可能です。 これは、変化を意識しているので、サーバでクライアントなしで状態を変えるでしょう。 同じ錠_所有者と共にseqid、そして/または、stateidを連れて行くいかなる他の操作も試みる前にクライアントが状態をサーバと再同期させるのは、最高のです。 これは、特別番組なしで操作を再同時にさせるために簡単です。
Since the server maintains the last lock request and response received on the lock_owner, for each lock_owner, 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 lock_owner, 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 server will return the cached result or if never saw the request, perform it. 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 lock_owner will re-synchronize and in turn the lock state will re-synchronize.
サーバが錠_所有者の上に受け取られた最後のロック要求と応答を維持するので、各錠_所有者に関して、クライアントがそれが送った最後のロック要求をキャッシュするべきであるので、ロック要求は応答を受けませんでした。 これから、それはクライアントが錠_所有者のためのロック操作をする次の時にキャッシュされた要求を送ることができます、決してそうしません。要求を挽いてください、そして、それを実行してください。 引き続いて、クライアントは状態(例えば、LOCKUかCLOSE操作)を取り除くという要求ができます。 このアプローチと、与えられた錠_所有者のためのクライアントとサーバの配列とstateid情報は再同期するでしょう、そして、順番に、ロック状態は再同期するでしょう。
8.8. Server Revocation of Locks
8.8. 錠のサーバ取消し
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 before expiration. 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
2番目のロック取消しイベントは満了の前にリースを更新できないことです。 これがまれであるか珍しいイベントであると考えられている間、クライアントは回復する用意ができていなければなりません。サーバとクライアントは、ともに、リースを更新しないことを検出できて、データの汚染なしで回復できます。 サーバによって、それは、クライアントのために修理された最後の更新イベントを追跡して、リースがいつ期限が切れるかを知っています。 同様に、クライアントはそうする操作を追跡しなければなりません。
Shepler, et al. Standards Track [Page 85] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[85ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
リースの期間を更新してください。 そのような各要求を送った時間と対応する回答を受け取った時間を費やして、クライアントは、対応する更新がサーバに起こったかもしれない時にバウンドして、その結果、リース期間の満了が起こったかもしれないのが、可能であるかどうかと決心するべきです。
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_ADMIN_REVOKED. In this instance the client may assume that only the lock_owner'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.
3番目のロック取消しイベントはリースの期間中に管理介入の結果、起こることができます。 これはめったにない事件であると考えられますが、サーバの管理者が、クライアントによって持たれていた特定の錠をリリースするか、または取り消すと決めたのは、可能です。 取消しの結果、クライアントはNFS4ERR_ADMIN_REVOKEDの誤りを受けるでしょう。 この場合クライアントは、錠_所有者だけの錠がなくされたと仮定するかもしれません。 クライアントは適切にロック所有者に通知します。 クライアントは、リースの期間が失敗した操作の結果、更新されたと仮定しないかもしれません。
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.
クライアントが、リースの期間が期限が切れたかもしれないと決心していると、クライアントは関連リースのために"非有効にする"であることのように持たれていたすべての錠をマークしなければなりません。 これは、クライアントがサーバで適切なロック状態を復職するか、または確認できないことを意味します。速成の回復の前項で説明されるように、リースの期間がクライアントのために期限が切れた後にサーバが錠を闘争に与えるかもしれないシナリオがあります。 リースの期間が期限が切れたのが、可能であるときに、クライアントは現在闘争錠が与えられていないのを保証するために持たれている各錠を有効にしなければなりません。 クライアントは入出力要求を発行することによって、このタスクを達成するかもしれません、と未定の入出力かゼロ・レングスのどちらかが読みます、関連しているはっきりしていない錠でstateidを指定して。 要求への応答が成功であるなら、クライアントは、そのstateidによって治められた錠のすべてを有効にして、それ自体とサーバの間の適切な状態を復職させました。
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に関連している錠の1つ以上はサーバによって取り消されました、そして、クライアントは所有者に通知しなければなりません。
8.9. Share Reservations
8.9. 予約を共有してください。
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.
シェアの予約はファイルへのアクセスを制御するメカニズムです。 それは記録的なロックからの別々の、そして、独立しているメカニズムです。 クライアントがファイルを開くと、それは、他のものを否定するためにアクセスのタイプが必要としたサーバ指定(READ、WRITE、またはBOTH)とアクセスのタイプにオープン操作を発行します(NONE、READ、WRITE、またはBOTHを否定してください)。 オープンが失敗すると、クライアントはアプリケーションの開いている要求に失敗するでしょう。
Pseudo-code definition of the semantics:
意味論の中間コード定義:
if (request.access == 0)
return (NFS4ERR_INVAL)
(request.access=0)が戻るなら(NFS4ERR_INVAL)
Shepler, et al. Standards Track [Page 86] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[86ページ]RFC3530NFSバージョン4 プロトコル2003年4月
else
if ((request.access & file_state.deny)) ||
(request.deny & file_state.access))
return (NFS4ERR_DENIED)
ほか、((request.accessとファイル_state.deny))です。|| (request.denyとファイル_state.access))、リターン(_が否定したNFS4ERR)
This checking of share reservations on OPEN is done with no exception for an existing OPEN for the same open_owner.
同じオープンな_所有者のための既存のオープンにどんな例外でもオープンのシェアの予約のこの照合をしません。
The constants used for the OPEN and OPEN_DOWNGRADE operations for the access and deny fields are as follows:
定数は、オープンとオープンに_アクセスのためのDOWNGRADE操作を使用して、分野は以下の通りであることを否定します:
const OPEN4_SHARE_ACCESS_READ = 0x00000001; const OPEN4_SHARE_ACCESS_WRITE = 0x00000002; const OPEN4_SHARE_ACCESS_BOTH = 0x00000003;
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;
const OPEN4_SHARE_DENY_NONE=0x00000000。 const OPEN4_SHARE_DENY_READ=0x00000001。 const OPEN4_SHARE_DENY_WRITE=0x00000002。 const OPEN4_SHARE_DENY_BOTH=0x00000003。
8.10. OPEN/CLOSE Operations
8.10. 開いているか厳密な操作
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.
クライアントは、正しいシェア意味論を提供するために、初期のfilehandleを入手するのにオープン操作を使用して、必要なアクセスを示さなければなりません。どうなるだろうか、そして、拒絶するどんなアクセス。 クライアントがすべての0かすべての1のstateidを使用するつもりであってもさえ、それは、適切なシェア意味論を適用できるようにオープン操作でまだ通常のファイルにfilehandleを入手しなければなりません。 aに彼らの開いているプログラミングインターフェースが組み込まれたモードを否定させないクライアントに関しては、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.
オープン操作は、NFSプロトコルの旧バージョンで使用されるようにCREATEと共に弛んで、また、通常のファイルのためにCREATE操作を包括します。 これはaを許容します。原子論的に行われるシェアで、作成します。
The CLOSE operation removes all share reservations held by the lock_owner 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, NFS4ERR_LOCKS_HELD, if any locks would exist after the CLOSE.
CLOSE操作はそのファイルの上に錠_所有者によって保持されたすべてのシェアの予約を取り除きます。 記録的な錠が持たれているなら、CLOSEを発行する前に、クライアントSHOULDはすべての錠をリリースします。 サーバはCLOSEの上のすべての傑出している錠を解放するかもしれませんが、いくつかのサーバはまだ記録的な錠を持っているファイルのCLOSEをサポートしないかもしれません。 NFS4ERR_LOCKS_HELD、サーバは失敗を返さなければならなくて、錠はいずれかであるなら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
サーバのどんなロック状態も設置しないで、LOOKUP操作はfilehandleを返すでしょう。有効なstateidがなければ、サーバは、クライアントが最少のアクセサリーを持っていると仮定するでしょう。 例えば、ファイル
Shepler, et al. Standards Track [Page 87] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[87ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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).
開かれる状態で、有効なstateid(すなわち、すべてのビット0かすべてのビット1のstateidを使用する)を持っていないでしょう、したがって、LOOKUPを通して入手されたfilehandleを使用することでREAD/WRITEにアクセスできないことを否定してください。
8.10.1. Close and Retention of State Information
8.10.1. 州の情報の閉鎖と保有
Since a CLOSE operation requests deallocation of a stateid, dealing with retransmission of the CLOSE, may pose special difficulties, since the state information, which normally would be used to determine the state of the open file being designated, might be deallocated, resulting in an NFS4ERR_BAD_STATEID error.
CLOSE操作が、CLOSEの「再-トランスミッション」に対処して、stateidの反配分がポーズをとるかもしれないよう要求するので、州の情報以来、特別な困難は「反-割り当て」られるかもしれません、NFS4ERR_BAD_STATEID誤りをもたらして。(通常、情報は、指定されるオープン・ファイルの事情を決定するのに使用されるでしょう)。
Servers may deal with this problem in a number of ways. To provide the greatest degree assurance that the protocol is being used properly, a server should, rather than deallocate the stateid, mark it as close-pending, and retain the stateid with this status, until later deallocation. In this way, a retransmitted CLOSE can be recognized since the stateid points to state information with this distinctive status, so that it can be handled without error.
サーバは多くの方法でこの問題に対処するかもしれません。 プロトコルがstateidを「反-割り当て」るよりむしろ適切に、サーバがそうするべきである使用していることにされるのであるという最も大きい度合い保証を提供するために、それが同じくらい未定であると近くのマークしてください、そして、この状態があるstateidを保有してください、後の反配分まで。 このように、stateidがこの特有の状態がある州の情報を示すので、再送されたCLOSEを認識できます、誤りなしでそれを扱うことができます。
When adopting this strategy, a server should retain the state information until the earliest of:
この戦略を採用するとき、サーバは以下で最も早くなるまで州の情報を保有するべきです。
o Another validly sequenced request for the same lockowner, that is
not a retransmission.
o 確実に、別のものはすなわち、同じlockowner、「再-トランスミッション」でないのを求める要求を配列しました。
o The time that a lockowner is freed by the server due to period
with no activity.
o lockownerが期間のためサーバによって活動なしで解放される時間。
o All locks for the client are freed as a result of a SETCLIENTID.
o クライアントのためのすべての錠がSETCLIENTIDの結果、解放されます。
Servers may avoid this complexity, at the cost of less complete protocol error checking, by simply responding NFS4_OK in the event of a CLOSE for a deallocated stateid, on the assumption that this case must be caused by a retransmitted close. When adopting this approach, it is desirable to at least log an error when returning a no-error indication in this situation. If the server maintains a reply-cache mechanism, it can verify the CLOSE is indeed a retransmission and avoid error logging in most cases.
サーバはこの複雑さを避けるかもしれません、CLOSEの場合、deallocated stateidのためにNFS4_OKを単に反応させることによってチェックするそれほど完全でないプロトコル誤りの費用で、再送された閉鎖で本件を引き起こさなければならないという前提で。 このアプローチを取るとき、この状況における誤り表示を全く返さないとき、誤りを少なくとも登録するのは望ましいです。 サーバが回答キャッシュメカニズムを維持するなら、それは確かめられることができます。CLOSEは本当に「再-トランスミッション」であり、多くの場合、エラー・ロギングを避けます。
8.11. Open Upgrade and Downgrade
8.11. 開いているアップグレードとダウングレード
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
オープンがファイルのために終わって、戸外が行われているlockownerがファイルを既に開かせるとき、結果は、アクセスを含むようにサーバで維持されたオープン・ファイル状態をアップグレードさせて、ビットが既存のオープンへのそれらと同様に新しいオープンで指定したことを否定することです。 そして結果は1つのオープン・ファイルがあるということです、プロトコルが関係があって、アクセスの組合を含んでいる限り。
Shepler, et al. Standards Track [Page 88] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[88ページ]RFC3530NFSバージョン4 プロトコル2003年4月
deny bits for all of the OPEN requests completed. Only a single CLOSE will be done to reset the effects of both OPENs. 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 OPENs result in the OPENed object being designated by the same filehandle.
要求が終了したオープンのすべてのためにビットを否定してください。 両方のOPENsの効果をリセットするために独身のCLOSEだけをするでしょう。 オープンを発行するとき、クライアントが、事実上、同じファイルが開かれているのを知らないかもしれないことに注意してください。 両方のOPENsが同じfilehandleによって指定されるOPENedオブジェクトをもたらす場合にだけ、上記は適用されます。
When the server chooses to export multiple filehandles corresponding to the same file object and returns different filehandles on two different OPENs 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 OPENs with separate stateids and will require separate CLOSEs to free them.
サーバが選ばれると、輸出倍数に、アクセスは一緒に「OR」ではなく同じファイルオブジェクトと同じファイルオブジェクト、サーバの2異なったOPENsの上の異なったfilehandlesがそうしなければならないリターンに対応しながら、filehandlesされています、そして、ビットを否定してください、そして、2つのオープン・ファイルを合体させてください。 代わりに、サーバは、別々のstateidsと別々のOPENsを主張しなければならなくて、別々のCLOSEsが彼らを解放するのを必要とするでしょう。
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 opens 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.
クライアントの複数のオープン・ファイルがサーバの単一のオープン・ファイルオブジェクトに合併されているとき、オープン・ファイル(クライアントの)の1つの閉鎖は、アクセスの変化を必要として、サーバに関するオープン・ファイルの状態を否定するかもしれません。そして、これがそう、アクセスの組合、残りが開くのでビットが以前によりわずかであるかもしれないことを(すなわち、真部分集合)否定してください。 オープン_DOWNGRADE操作は必要な変更を行うのに使用されます、そして、クライアントがサーバをアップデートするのにそれを使用するべきであるので、他のクライアントによるシェア予約の要請は適切に扱われます。
8.12. Short and Long Leases
8.12. 短くて長いリース
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 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 (the server must wait for the leases to expire and the grace period to elapse 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 would not be an issue.
サーバが非揮発性メモリーにリース状態を保存できるなら、借地契約は使用可能です。 回復では、サーバは、非揮発性メモリーからリース状態を再建して、クライアントと共に操作を続けることができます、そして、したがって、借地契約は問題でないでしょう。
8.13. Clocks, Propagation Delay, and Calculating Lease Expiration
8.13. 時計、伝播遅延、および計算のリース満了
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
連動している時計の必要性を避けるために、サーバは時間デルタとしてリース時間を与えます。 しかしながら、クライアントとサーバ時計が錠の持続時間の上を過度に漂流しないという要件があります。 また、伝播遅延の問題が横切ってあります。
Shepler, et al. Standards Track [Page 89] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[89ページ]RFC3530NFSバージョン4 プロトコル2003年4月
network which could easily be several hundred milliseconds as well as the possibility that requests will be lost and need to be retransmitted.
どれが要求が失われる可能性と同様に容易に数100ミリセカンドであるかもしれないか、そして、再送されるべき必要性をネットワークでつないでください。
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.
伝播遅延を考慮に入れるために、クライアントはリース時間からそれを引き算するべきです(例えば、クライアントが、200msecとして一方向伝播が遅れであると見積もっているなら、それは、リースが既にそれであるなら古いmsecがそれを得る200であると仮定できます)。 さらに、応答をサーバに取り戻すのにもう1 200msecを要するでしょう。クライアントは、リースの前の400msecが吐き出すサーバにロック更新を送らなければならないか、またはデータを書いて戻さなければなりません。
The server's lease period configuration should take into account the network distance of the clients that will be accessing the server's resources. It is expected that the lease period will take into account the network propagation delays and other network delay factors for the client population. Since the protocol does not allow for an automatic method to determine an appropriate lease period, the server's administrator may have to tune the lease period.
サーバのリース期間の構成はサーバのリソースにアクセスするクライアントのネットワーク距離を考慮に入れるべきです。 リースの期間が依頼者群のためのネットワーク伝播遅延と他のネットワーク遅延要素を考慮に入れると予想されます。 プロトコルが適切なリースの期間を決定する自動メソッドを考慮しないので、サーバの管理者はリースの期間を調整しなければならないかもしれません。
8.14. Migration, Replication and State
8.14. 移行、模写、および状態
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, stateids, and clientids) 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".
与えられたファイルシステムを扱うことへの責任を新しいサーバ(移行)に移すか、またはクライアントが、ファイルシステム模写の文脈で代替のサーバ(例えば、サーバ鈍感さに対応した)を使用するのを選ぶとき、以下で説明されるとしてクライアントとサーバ(すなわち、錠、リース、stateids、およびclientids)の間で共有された状態の適切な取り扱いがあります。 取り扱いは移行と模写の間で異なります。 ファイルサーバーの関連する議論のために、そのようなものを述べて、回復してください。「ファイルのロックとシェア予約」の下のセクションを見てください。
If server replica or a server immigrating a filesystem agrees to, or is expected to, accept opaque values from the client that originated from another server, then it is a wise implementation practice for the servers to encode the "opaque" values in network byte order. This way, servers acting as replicas or immigrating filesystems will be able to parse values like stateids, directory cookies, filehandles, etc. even if their native byte order is different from other servers cooperating in the replication and migration of the filesystem.
サーバレプリカかサーバであるなら、移住して、ファイルシステムは、同意するか、または予想されます、別のサーバから発したクライアントから不透明な値を受け入れてください、そして、そして、サーバがネットワークバイトオーダーにおける「不透明な」値をコード化するのは、賢明な実装習慣です。 この道、彼らのネイティブのバイトオーダーがファイルシステムの模写と移行に協力する他のサーバと異なっても、レプリカか移住ファイルシステムが値を分析できるので行動するサーバはstateids、ディレクトリクッキー、filehandlesなどが好きです。
8.14.1. Migration and State
8.14.1. 移行と状態
In the case of migration, the servers involved in the migration of a filesystem 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
移行の場合では、サーバはファイルシステムSHOULD転送の移行にすべてのサーバ状態にオリジナルから新しいサーバまでかかわりました。クライアントにとって、見え透いた方法でこれをしなければなりません。 aであるときに、この州の転送はクライアントの変遷を緩和するでしょう。
Shepler, et al. Standards Track [Page 90] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[90ページ]RFC3530NFSバージョン4 プロトコル2003年4月
filesystem migration occurs. If the servers are successful in transferring all state, the client will continue to use stateids assigned by the original server. Therefore the new server must recognize these stateids as valid. This holds true for the clientid as well. Since responsibility for an entire filesystem 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.
ファイルシステム移行は起こります。 サーバがすべての状態を移すのに成功していると、クライアントは、オリジナルのサーバによって割り当てられたstateidsを使用し続けるでしょう。したがって、新しいサーバは有効であるとしてこれらのstateidsを認めなければなりません。 これはまた、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 old 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のどちらかを受け取る用意ができていなければなりません。次に、クライアントは通常、サーバ失敗に対応して回復するように州の情報を回復するべきです。 新しいサーバは、州の情報の回復を考慮するためにサーバ再開の場合、注意するように注意されなければなりません。
8.14.2. Replication and State
8.14.2. 模写と状態
Since client switch-over in the case of replication is not under server control, the handling of state is different. In this case, leases, stateids and clientids 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.
模写の場合でオーバークライアント切り替わるのがサーバ制御装置の下にないので、状態の取り扱いは異なっています。 この場合、リース、stateids、およびclientidsは1つのサーバから別のサーバまでの変遷の向こう側に正当性を持っていません。 クライアントは新しいサーバで錠を復職させなければなりません。サーバリブートの後のタイプを取り戻している要求によって錠の再設立とこれは比較できます。 違いはサーバには新しい錠を入手するものと錠を開墾する要求を区別するか、または後者を延期する支給が全くないということです。 したがって、クライアントが新しいサーバ(LOCKかオープン要求による)で錠を復職させる場合、闘争錠のため要求を否定させるかもしれません。 模写がファイルシステムの書き込み禁止使用のために意図するので、錠のそのような否定は実際には大きい困難を引き起こすべきではありません。 新しいサーバで錠を復職させる試みが否定されるとき、まるで彼のオリジナルの錠が取り消されたかのようにクライアントは状況を扱うべきです。
Shepler, et al. Standards Track [Page 91] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[91ページ]RFC3530NFSバージョン4 プロトコル2003年4月
8.14.3. Notification of Migrated Lease
8.14.3. 移行したリースの通知
In the case of lease renewal, the client may not be submitting requests for a filesystem that has been migrated to another server. This can occur because of the implicit lease renewal mechanism. The client renews leases for all filesystems when submitting a request to any one filesystem 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 filesystem for which a lease has been moved to a new server.
クライアントが新しいサーバに移動したかもしれないリースの更新の計画をするように、それらのリースが期限が切れる前にクライアントはリース再配置を見つけなければなりません。 これ(リースのどれかが更新される責任を新しいサーバに移したなら(すなわち、オープン、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 an operation on each filesystem 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, the client will receive either NFS4ERR_STALE_CLIENTID or NFS4ERR_STALE_STATEID from the new server, as described above, and the client can then recover state information as it does in the event of server failure.
クライアントがNFS4ERR_LEASE_MOVED誤りを受けるとき、それは関連しているサーバがはっきりしていなかった状態でそれぞれのファイルシステムに操作を実行するべきです。 クライアントがNFS4ERR_MOVED誤りを受けるとき、クライアントは、新しいサーバ情報を得るために正常なプロセスの後をつけて(fs_位置の属性を通して)、新しいサーバにおけるそれらのリースの更新を実行できます。サーバで透過的に状態をそれに移していないと、クライアントは上で説明されるように新しいサーバからNFS4ERR_STALE_CLIENTIDかNFS4ERR_STALE_STATEIDのどちらかを受け取るでしょう、そして、次に、クライアントはそれとしての情報がサーバ失敗の場合、する状態を回復できます。
8.14.4. Migration and the Lease_time Attribute
8.14.4. 移行とリース_時間属性
In order that the client may appropriately manage its leases in the case of migration, the destination server must establish proper values for the lease_time attribute.
クライアントが移行の場合で適切にリースを管理するかもしれなくて、目的地サーバはリース_時間属性のために固有値を確立しなければなりません。
When state is transferred transparently, that state should include the correct value of the lease_time attribute. The lease_time attribute on the destination server must never be less than that on the source since this would result in premature expiration of leases granted by the source server. Upon migration in which state is transferred transparently, the client is under no obligation to re- fetch the lease_time attribute and may continue to use the value previously fetched (on the source server).
透過的に状態を移すとき、その州はリース_時間属性の正しい値を含めるべきです。 目的地サーバの属性が決してそうしてはいけないリース_時代に、これ以来のソースのそれがソースサーバによって承諾されたリースの時期尚早な満了をもたらすだろうより少なくいてください。状態が透過的に移される移行では、クライアントは、リース_時間属性を再とって来るどんな義務の下にもいないで、以前にとって来られた(ソースサーバで)値を使用し続けてもよいです。
If state has not been transferred transparently (i.e., the client sees a real or simulated server reboot), the client should fetch the value of lease_time on the new (i.e., destination) server, and use it
状態が透過的に移されていないなら(すなわち、クライアントは、本当の、または、シミュレートされたサーバがリブートされるのを見ます)、クライアントは、_新しい(すなわち、目的地)サーバの時間を賃貸価格にとって来て、それを使用するべきです。
Shepler, et al. Standards Track [Page 92] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[92ページ]RFC3530NFSバージョン4 プロトコル2003年4月
for subsequent locking requests. However the server must respect a grace period at least as long as the lease_time on the source server, in order to ensure that clients have ample time to reclaim their locks before potentially conflicting non-reclaimed locks are granted. The means by which the new server obtains the value of lease_time on the old server is left to the server implementations. It is not specified by the NFS version 4 protocol.
その後のロック要求のために。 しかしながら、サーバはソースサーバのリース_時間としての少なくとも同じくらい長い据置期間を尊敬しなければなりません、クライアントには潜在的に闘争している非開墾された錠を与える前に彼らの錠を開墾する十分な時間があるのを確実にするために。 新しいサーバが古いサーバのリース_時間の値を得る手段はサーバ実装に残されます。 それはNFSバージョン4プロトコルによって指定されません。
9. Client-Side Caching
9. クライアントサイドキャッシュ
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プロトコルはサーバによってクライアントによって局所的に作られているのが通常された多くの決定を許す委譲メカニズムを紹介します。 このメカニズムは共有が珍しいか、共有が書き込み禁止であるよくある例の効率的なサポートを提供します。
9.1. Performance Challenges for Client-Side Caching
9.1. クライアントサイドキャッシュのためのパフォーマンス挑戦
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プロトコルの旧バージョンは彼らのファイルデータキャッシュ合法化要求を繰り返して言います。 この振舞いは重大な性能欠点を持つことができます。 よくある例はファイルが独身のクライアントによってアクセスされるだけであるものです。 したがって、共有は珍しいです。
Shepler, et al. Standards Track [Page 93] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[93ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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").
どの特定のフォームのキャッシュがカバーされているかで後のセクションでサーバのための適切な要件について議論します。 (「開いている委譲」というセクションを見ます。)
9.2. Delegation and Callbacks
9.2. 委譲とコールバック
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
委譲はサーバからクライアントまで通過されます、委譲のオブジェクトと委譲のタイプを指定して。 異なったタイプの委譲がありますが、各タイプは委譲による操作を実行するとき、委譲を表すのに使用されるべきstateidを含んでいます。 このstateidは錠に関連づけられたものと同様であり、予約を共有しますが、委譲のためのstateidがclientidに関連しているという点において異なって、あるかもしれません。
Shepler, et al. Standards Track [Page 94] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[94ページ]RFC3530NFSバージョン4 プロトコル2003年4月
used on behalf of all the open_owners 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.
与えられたクライアントのためのすべてのオープンな_所有者を代表して、使用されています。 委譲はそれの中で全体でどんな特定のプロセスやスレッドではなくも、コントロールのクライアントに作られています。
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.
コールバックRPCsがすべての環境(例えばファイアウォールのため)で働かないかもしれないので、正しいプロトコル操作はそれらによりません。 CB_NULL手順によるコールバックの機能性の予備のテストは、コールバックをサポートすることができるかどうか決定します。 CB_NULL手順はコールバック経路の連続をチェックします。 サーバは、コールバックの有用性の初期評価を与えられたクライアントに作って、コールバックがサポートされることを決定するまで責任を代表として派遣するのを避けます。 委譲を与えるのがいつも闘争アクセスの欠如に依存しているので、クライアントは委譲を与えて、OPENsが与えられる委譲なしでどんな処理されるように彼らをいつも準備しなければならないと仮定してはいけません。
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.
リコールのときに、委譲を保持しているクライアントは、変更された状態(変更されたデータなどの)をサーバに洗い流して、委譲を返さなければなりません。 リコールが完全になるまで、闘争要求は応答を受けないでしょう。 クライアントが委譲かサーバ回をリコールの外に返して、タイムアウトの結果、委譲を取り消すとき、リコールは完全であると考えられます。 リコールの解決に続いて、サーバで情報は2番目のクライアントの要求を承諾するか、または否定するのに必要になります。
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.
クライアントが委譲リコールを受けるとき、それにはサーバに洗い流される必要があるかなりの州があるかもしれません。したがって、多数のRPCsにサーバにかかわるかもしれないので、サーバは、十分な時間、委譲が返されるのを許容するべきです。サーバが、クライアントがリコールの結果、まめに状態をサーバに洗い流していることを決定できるなら、サーバはリコールのために普通の日限を広げるかもしれません。 しかしながら、リコール完成のための日限は限りないはずがありません。
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.
この例は調停する責任がいつ与えられたファイルの上で開くかクライアントへ代表として派遣するという(「開いている委譲」というセクションを見てください)ことです。 サーバは、開くものがクライアントで有効であることを知らないでしょう。 サーバがアクセスであるなら決定できないで、状態を否定するこの知識がなければ、ファイルはどんな特定の戸外もファイルのための委譲を返すまで許容します。
Shepler, et al. Standards Track [Page 95] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[95ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
クライアント失敗かネットワークパーティションがリコールコールバックに応じないことをもたらすことができます。 この場合、サーバは順番にまだクライアントのどんな変更された状態も役に立たなくする委譲を取り消すでしょう。
9.2.1. Delegation Recovery
9.2.1. 委譲回復
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).
このタイプのクライアント回復を考慮するために、サーバは典型的なリース満了の期間に委譲回復のために期間を延ばすかもしれません。 これは、これらの委譲と衝突する他のクライアントからの要求が、待つ必要であるのを含意します。 正常なリコールプロセスがクライアントが変えられた状態をサーバに洗い流す重要な時間を必要とするかもしれないので、他のクライアントは闘争委譲で起こる遅れのために用意ができていなければなりません。 クライアントが委譲を取り戻すことができるように安定貯蔵をリブートして、相談するように、このより長い間隔は窓を増強するでしょう。 開いている委譲において、そのような委譲は、クレーム_DELEGATE_PREVのクレームタイプとのオープンを使用することで取り戻されます。 (それぞれ「データキャッシュと取消し」でのセクション、開いている委譲の議論のための「操作18: 戸外」、およびオープンの詳細を見ます。)
A server MAY support a claim type of CLAIM_DELEGATE_PREV, but if it does, it MUST NOT remove delegations upon SETCLIENTID_CONFIRM, and instead MUST, for a period of time no less than that of the value of the lease_time attribute, maintain the client's delegations to allow time for the client to issue CLAIM_DELEGATE_PREV requests. The server that supports CLAIM_DELEGATE_PREV MUST support the DELEGPURGE operation.
5月がクレーム_DELEGATE_PREVをタイプしてくださいが、そうするなら、委譲を取り除いてはいけないというクレームをサポートするサーバはSETCLIENTID_CONFIRMに、代わりにそうしなければなりません、しばらく。クライアントがクレーム_DELEGATE_PREV要求を出す時間を許容するためにリース_時間属性の価値のものほどクライアントの委譲を維持しないでください。 クレーム_DELEGATE_PREV MUSTサポートがDELEGPURGE操作であるとサポートするサーバ。
Shepler, et al. Standards Track [Page 96] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[96ページ]RFC3530NFSバージョン4 プロトコル2003年4月
When the server reboots or restarts, delegations are reclaimed (using the OPEN operation with CLAIM_PREVIOUS) 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:
サーバがリブートするか、または再開するとき、委譲は、錠を記録して、予約を共有するために同様に取り戻されます(クレーム_PREVIOUSとのオープン操作を使用します)。 しかしながら、わずかな意味違いがあります。 正常な場合では、どんな委譲も与えないで、サーバが、委譲が与えられるべきでないと決めるなら、それは要求された動作(例えば、オープン)を実行します。 サーバは委譲を与えますが、特別な名称は、クライアントがサーバで与えますが、思い出したとして委譲を扱うように、適用されています。開墾、これのために、クライアントには、サーバへのすべての変更された状態に書いて、次に委譲を返す義務があります。 委譲が取り戻す取り扱いのこのプロセスは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を受けるとき、通常、クライアントは委譲の取消しを見つけます。 また、委譲を取り戻すのを試みて、その同じ誤りを受けるとき、それはクライアントリブートの後に委譲取消しを見つけるかもしれません。 aに関するケースが取り消したコネが開いている委譲を書くというメモ、データが委譲が別々に他のクライアントによって取り消されるクライアントによって変更されたかもしれないので、問題があります。 開いている委譲を書いてください。セクションを見てください、「取消し回復、」 そのような問題の議論のために。 また、委譲が取り消されるとき、取り消された委譲の情報がサーバによって安定貯蔵まで書かれることに注意してください(「クラッシュリカバリ」というセクションで説明されるように)。 委譲を取り消した後にもかかわらず、取り消された委譲を保持しているクライアントが取消しに関して通知される前を除いて、サーバがリブートされる場合に対処するためにこれをします。
Shepler, et al. Standards Track [Page 97] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[97ページ]RFC3530NFSバージョン4 プロトコル2003年4月
9.3. Data Caching
9.3. データキャッシュ
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.
アプリケーションが1セットのファイルへのアクセスを共有するとき、それらは、別のアプリケーションで闘争アクセスの可能性を考慮に入れるために実装される必要があります。 問題のアプリケーションが同じクライアントの上に異なったクライアントの上で作成するか、またはあることにかかわらずこれは本当です。
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プロトコルのデータキャッシュに実装しなければなりません。
9.3.1. Data Caching and OPENs
9.3.1. データ、キャッシュして、開きます。
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.
READかWRITE操作でその同じデータを得るか、または変更するのが有効でないだろうというときに、アプリケーションが依存する共有仮定を無効にするのを避けるために、NFSバージョン4クライアントは、キャッシュされたデータをアプリケーションに提供するべきではありませんし、またアプリケーションを代表してそれを変更するべきではありません。
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.
その上、開いている委譲(「開いている委譲」というセクションを見る)2がないとき、付則は適用されます。 これらの規則が実際には多くのNFSバージョン2とバージョン3クライアントによって従われることに注意してください。
o First, cached data present on a client must be revalidated after
doing an OPEN. Revalidating means that the client fetches the
change attribute from the server, compares it with the cached
change attribute, and if different, declares the cached data (as
well as the cached attributes) as invalid. 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 まず最初に、オープンをした後に、クライアントの現在のキャッシュされたデータを再有効にしなければなりません。 Revalidatingは、クライアントがサーバから変化属性をとって来て、キャッシュされた変化属性、異なるならそれを比較することを意味して、キャッシュされたデータ(キャッシュされた属性と同様に)が無効であると宣言します。 これは、OPENedファイルのためのデータがまだ正しくクライアントのキャッシュに反映されているのを保証するためのものです。 クライアントのオープン操作が少なくともいつDENY=WRITEを含んでいるか、そして、BOTHをこの合法化にしなければなりません、その結果、終わって、期間はどの他のクライアントでWRITEアクセサリーでファイルを開く機会を持っていたかもしれないか。 クライアントは、キャッシュ再合法化のこの度合いを仮定するユーザの利益のためにNFSバージョン3プロトコルの習慣に沿うように、よりしばしば(すなわち、DENY=NONEを指定するOPENsで)再合法化するのを選ぶかもしれません。
Since the change attribute is updated for data and metadata
modifications, some client implementors may be tempted to use the
time_modify attribute and not change to validate cached data, so
that metadata changes do not spuriously invalidate clean data.
The implementor is cautioned in this approach. The change
attribute is guaranteed to change for each update to the file,
データとメタデータ変更のために変化属性をアップデートするので、何人かのクライアント作成者が_属性を変更してください。そうすれば、有効にするどんな変化もデータをキャッシュしなかったのでメタデータ変化が偽って清潔なデータを無効にしない時を費やすように誘惑されるかもしれません。 作成者はこのアプローチで警告されます。 変化属性は、各アップデート単位でファイルに変化するように保証されます。
Shepler, et al. Standards Track [Page 98] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[98ページ]RFC3530NFSバージョン4 プロトコル2003年4月
whereas time_modify is guaranteed to change only at the
granularity of the time_delta attribute. Use by the client's data
cache validation logic of time_modify and not change runs the risk
of the client incorrectly marking stale data as valid.
_が変更する時間は単に時間_デルタ属性の粒状で変化するように保証されますが。 変化ではなく、クライアントの_が変更する時間のデータキャッシュ合法化論理による使用が有効であるとして不当に聞き古したデータをマークしているクライアントの危険を冒します。
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 2番目に、aがOPENedをファイルする閉鎖が書く前に変更されたデータをサーバに洗い流さなければなりません。 これは最初の規則を補足しています。 データがCLOSEに洗い流されないなら、クライアントOPENsの後にファイルとして行われた再合法化は目的を遂げることができません。 閉鎖の前にデータを洗い流すことへのもう片方の局面は安定貯蔵にデータを心がけなければならないということです、サーバで、CLOSE操作がクライアントによって要求されている前に。 サーバリブートか再開に関するケースとCLOSEdファイルでは、ファイルに書かれているためにデータを再送するのが可能でないかもしれません。 したがって、この要件。
9.3.2. Data Caching and File Locking
9.3.2. データキャッシュとファイルのロック
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 filesystem. However, they may not work with the NFS version 4 protocol unless clients refrain from data caching.
無節操なファイルアクセスを除くのにシェアの予約の代わりにファイルのロックを使用するのを選ぶそれらのアプリケーションのために、クライアントサイドデータキャッシュに適用される類似の規制があります。 ファイルのロックが同等な方法で操作が実行した実際のREADとWRITEに合っている方法で使用される場合にだけ、これらの規則は効果的です。 これは純粋なコンベンションに基づいているファイルのロックと対照的にあります。 例えば、ファイルを2つの1メガバイトの領域に分割して、バイトゼロと1にファイルロックで2つの領域へのアクセスを保護することによって2メガバイトのファイルを操作するのは可能です。 Aがロックする、最初の領域でファイルのゼロがREADをするために右を表すバイトとWRITE操作を書き続けてください。 Aがロックする、2番目の領域でファイルのひとりがREADをするために右を表すバイトとWRITE操作を書き続けてください。 ファイルを操作するすべてのアプリケーションがこのコンベンションに従う限り、それらはローカルのファイルシステムに取り組むでしょう。 しかしながら、クライアントがデータキャッシュを控えないなら、彼らは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 cached 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 まず最初に、クライアントが特定の領域にファイルロックを入手すると、その領域(何かキャッシュされたデータが存在しているなら)に対応するデータキャッシュを再有効にしなければなりません。 変化属性が、キャッシュされたデータを得たのでファイルをアップデートしたかもしれないのを示すなら、クライアントは、新たにロックされた領域のためのキャッシュされたデータを洗い流さなければならないか、または無効にしなければなりません。 クライアントは、それがファイルのために持っている非変更されたキャッシュされたデータのすべてを無効にするのを選ぶかもしれませんが、正しい操作のための唯一の要件は新たにロックされた領域でデータのすべてを無効にすることです。
Shepler, et al. Standards Track [Page 99] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[99ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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 2番目に、以前、その領域のための領域に錠を書いている、すべて変更されたデータを発表するのをサーバに洗い流さなければなりません。また、変更されたデータを安定貯蔵まで書かなければなりません。
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.
サーバと無効にするのにキャッシュされたデータについてデータを洗い流すと範囲がロックしたか、またはアンロックした実際のバイトが反映しなければならないことに注意してください。 これらをする上、または、境界が問題を引き起こすクライアントキャッシュブロックを反映するか、または慎重にしていることまで一周させます。 例えば、開いている錠領域の中に半分のその唯一のブロックがあるとき、変更されたブロックを書くと、アンロックされた領域の外の領域への無効の変更は引き起こされるかもしれません。 これは順番に別のクライアントによってロックされた領域の一部であるかもしれません。 缶が同時部分を実行するのによるこの状況を避けるクライアントは1つのまるブロックでないその部分(初期的、または、最終的な)を重ね合わせる操作を書きます。 同様に、再合法化手順が、クライアントが持っているデータが有効でないかもしれないことを示すなら、整数の完全な緩衝ブロックでないロックされた地域を無効にするのは、クライアントがサーバから1か2つの部分的なブロックを読むのを必要とするでしょう。
The data that is written to the server as a prerequisite 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に関するロックされた範囲でカバーされているより多くのデータをサーバに洗い流すことによって標準的でない道(例えば、グローバルな腕木信号機として記録的な錠を使用する)における記録的なロックを使用するアプリケーションを収容するのを選ぶかもしれません。 これはアンロックが行われているもの以外のファイルの中に変更されたデータを含むかもしれません。 そのような場合、クライアントはREADsとWRITEsがアプリケーションが支える記録的な錠の領域だけの中で行われているアプリケーションを妨げてはいけません。 例えば、アプリケーションは、ファイルの1バイトをロックして、その単一のバイトを書きかけます。 すべての変更されたデータをサーバに洗い流すことによってLOCKUを扱うのを選んだクライアントは確実に関係ないアンロックに対応してその単一のバイトを書くことができました。 しかしながら、ロックされないで、別のクライアントによってロックされるかもしれない領域を含んでいるのでその単一の書かれたバイトが位置した全体のブロックを書くのは有効でないでしょう。 クライアント実装は、変更されたデータでファイルをすべての変更が適切な記録的な錠でカバーされた領域に行われるそれらと記録的な錠でカバーされなかった変更があるそれらに分割することによって、この問題を避けることができます。 前のクラスのファイルがロックされないで、またクライアントでこのようにして変更されなかった領域を含んではいけないので、いずれもしていた状態で書きます。
Shepler, et al. Standards Track [Page 100] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[100ページ]RFC3530NFSバージョン4 プロトコル2003年4月
9.3.3. Data Caching and Mandatory File Locking
9.3.3. データのキャッシュしていて義務的なファイルのロック
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 when the client gets back NFS4ERR_LOCKED from a READ or WRITE on a file it has an appropriate share reservation for. 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.
クライアントサイドデータキャッシュは、それが有効であるときに、義務的なファイルのロックを尊敬する必要があります。 クライアントであるときに、義務的の与えられたファイルのためのファイルのロックが示されるのを存在はそれが適切なシェアの予約を持っているファイルの上のREADかWRITEからNFS4ERR_LOCKEDを取り戻します。 ファイルに、義務的なロックが有効であるときに、クライアントは読まれるか、または書かれているデータのために適切なファイルロックがないかどうかチェックしなければなりません。 錠が読まれるか、または書かれている範囲に存在しているなら、クライアントの有効にされたキャッシュを使用することでクライアントは要望に応じるかもしれません。 適切なファイルロックが読みの範囲に持たれていないか、または書いてください、読みか書いてください。クライアントのキャッシュで要望に応じてはいけません、そして、処理のためのサーバに要求を送らなければなりません。 aがロックされた領域を部分的に重ね合わせると要求に読み込むか、または書くいつ、各領域(ロックされる)が適切に扱われている状態で、要求は複数の断片に細分されるべきであるか。
9.3.4. Data Caching and File Identity
9.3.4. データキャッシュとファイルのアイデンティティ
When clients cache data, the file data needs to be organized according to the filesystem 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 filesystem objects. The client then has the choice to organize and maintain the data cache on this basis.
クライアントがデータをキャッシュするとき、ファイルデータは、データが属するファイルシステム対象物に従って組織化される必要があります。 NFSバージョン3クライアントに関しては、典型的な習慣は、それをキャッシュする目的のために異なったfilehandlesが異なったファイルシステム対象物を表すと仮定することになっていました。 そして、クライアントには、このベースでデータキャッシュを組織化して、維持する選択があります。
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 filesystem 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プロトコルには、現在、filehandleがオブジェクトのパス名に基づいて組み立てられるかもしれないので「1オブジェクトあたり1filehandle」のモデルからの重要な逸脱を持つ可能性があります。 したがって、クライアントは2filehandlesが同じファイルシステム対象物を指定するかどうか決定する確かな方法を必要とします。 単にクライアントが、すべての異なったfilehandlesが異なったオブジェクトを指示して、このベースでのデータキャッシュをしかけると仮定するなら、矛盾をキャッシュするのは同じサーバに写像されて、オブジェクトに面がある異なったクライアントサイドオブジェクトの間に起こるでしょうに。
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.
filehandlesを差別化するメソッドを提供することによって、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:
データキャッシュの目的のために、以下のステップで、NFSバージョン4クライアントは、2異なったfilehandlesが同じサーバサイドオブジェクトを指示するかどうかと決心できます:
Shepler, et al. Standards Track [Page 101] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[101ページ]RFC3530NFSバージョン4 プロトコル2003年4月
o If GETATTR directed to two filehandles returns different values of
the fsid attribute, then the filehandles represent distinct
objects.
o 2filehandlesに向けられたGETATTRがfsid属性の異価を返すなら、filehandlesは異なったオブジェクトを表します。
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.
o 問題の2filehandlesのfsidに合っているfsidがあるどんなファイルのためのGETATTRもハンドルがTRUEの値で結果と考えるユニークな_を返すなら、2個のオブジェクトが異なっています。
o If GETATTR directed to the two filehandles does not return the
fileid attribute for both of the handles, then 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 2filehandlesに向けられたGETATTRがハンドルの両方のためにfileid属性を返さないなら、2個のオブジェクトが同じであるかどうかは決定できません。 したがって、その知識(例えば、クライアントサイドデータキャッシュ)による操作が確かにできません。
o If GETATTR directed to the two filehandles returns different
values for the fileid attribute, then they are distinct objects.
o 2filehandlesに向けられたGETATTRがfileid属性のために異価を返すなら、それらは異なったオブジェクトです。
o Otherwise they are the same object.
o さもなければ、それらは同じオブジェクトです。
9.4. Open Delegation
9.4. 開いている委譲
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:
ファイルがOPENedである、サーバがいつでさらなる取り扱いを代表として派遣するかもしれないか、そのファイルのために初めのクライアントに公開していて、閉じます。 委譲を考慮した事情が変化を被りやすいので、そのようなどんな委譲もリコール可能です。 特に、サーバは別のクライアントからの闘争オープンを受けるかもしれなくて、サーバはもう片方のクライアントからのオープンが承諾されるかもしれないかどうか決める前に、委譲を思い出さなければなりません。 委譲を作るのはサーバまで達しています、そして、クライアントが、どんな特定のオープンもそうすると仮定するべきではありませんか、または開いている委譲をもたらさないでしょう。 ↓これはオープンが代表として派遣されるべきであるかどうか決める際にサーバが使用するかもしれない典型的なセットの状態です:
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 戸外が要求する今後の闘争の確率はファイルの履歴に基づいて低いはずです。
Shepler, et al. Standards Track [Page 102] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[102ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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).
o 必要な取り扱いを代表として派遣されたクライアントが適用する(以下を見ます)処方された取り扱いと非互換にするオープン/CLOSEのどんなサーバ特有の意味論の存在。
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つのタイプの開いている委譲があります、そして、読んでください、そして、書いてください。 開いている委譲が読まれたAで、クライアントはそれ自身のところで読書するためのファイルを開くという他のものへの読書アクセスを拒絶しない要求を扱うことができます。 開いている委譲が読まれた倍数は、同時に、傑出していて、闘争しないかもしれません。 Aはクライアントがそれ自身のところで委譲で扱うことができる戸外を書いて、すべてが開きます。 一時に与えられたファイルのために存在するだけであるかもしれなく、人が、開いている委譲を書くそれは開いている委譲が読み込まれるいずれにも矛盾しています。
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: size, time_modify, change.
クライアントに開いている委譲が読まれたaがあるとき、ファイルのコンテンツか属性へのどんな変更も行わないかもしれませんが、他のどんなクライアントもそうしないかもしれないことが保証されます。 クライアントがaに開いている委譲を書かせるとき、他のどんなクライアントもファイルのデータにアクセスしないので、それはファイルデータを変更するかもしれません。 aを保持すると親密にファイルデータに関連づけられるファイル属性に影響するだけであるかもしれないと委譲に書かれるクライアント: サイズ、_が変更する時間は変化します。
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.
クライアントに開いている委譲があるとき、それは、OPENsかCLOSEsをサーバに送りませんが、内部的に適切な状態をアップデートします。 局所的にそれを扱うことができません。開いている委譲が読まれたaのために開き、サーバに送らなければなりません(書いてください。さもないと、それが、アクセスを読むように否定するので、開きます)。
When an open delegation is made, the response to the OPEN contains an open delegation structure which specifies the following:
開いている委譲が作られているとき、オープンへの応答は以下を指定する開いている委譲構造を含んでいます:
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
o 指定が許容を読み込んで、書くnfsace4
o a stateid to represent the delegation for READ and WRITE
o READとWRITEのために委譲を表すstateid
The delegation stateid is separate and distinct from the stateid for the OPEN proper. The standard stateid, unlike the delegation stateid, is associated with a particular lock_owner and will continue to be valid after the delegation is recalled and the file remains open.
オープン自体において、委譲stateidはstateidと別々であって、異なっています。 標準のstateidは委譲stateidと異なって特定の錠_所有者に関連していて、委譲が思い出されていて、ファイルが開いたままで残った後にずっと有効でしょう。
Shepler, et al. Standards Track [Page 103] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[103ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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:
頻繁なACCESS呼び出しを避けるのに委譲で渡された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.
o nfsace4が、戸外が完了していないかもしれないのを示すなら、決定的な答えを得るためにACCESS要求をサーバに送らなければなりません。
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を含んでいます。 伝統的なユーザ「根」をユーザ「だれも」に写像などでないことなどの一般的ないくつかの習慣で委譲応答でファイルの実際の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.
他の様々なフォームのキャッシュに伴う委譲の使用はユーザの要求のすべてが局所的に満足するかもしれないのでサーバ証明が全く今までに与えられたユーザのために実行されない可能性を作成します。 クライアントが認証のためにサーバによっているところでは、クライアントは認証が各ユーザのためにACCESS操作の使用で起こるのを確信しているべきです。 ACCESS操作は別の方法で必要でなくても、これがそうであるべきです。 以前言及されるように、サーバはあらゆる開いている委譲ですべてのアクセスを拒絶するnfsace4を返すことによって、頻繁な認証を実施するかもしれません。
9.4.1. Open Delegation and Data Caching
9.4.1. 開いている委譲とデータキャッシュ
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
オープン委譲は、始まりに関連づけられて、ファイルを閉じるメッセージオーバーヘッドの多くが排除されるのを許容します。 開いている委譲が有効であるときに、戸外は、合法化メッセージがサーバに送られるのを必要としません。「読書の開いている委譲」の継続的な辛抱は書いてください。そうすれば、その結果、いいえが書くのでオープンが全く起こっていないという保証を前提とします。 そして、開かれたファイルを閉じるときには同様に、書いてください、書く、開いている委譲が有効である、開いている委譲が洗い流される必要はないまで、書かれたデータはサーバに洗い流される必要はありません。
Shepler, et al. Standards Track [Page 104] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[104ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
思い出される。 開いている委譲の継続的な辛抱は行われた戸外がなくていいえがその結果、読むか、または別のクライアントが書く保証を提供します。
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.
開いている委譲の目的のために、オープンなしで行われたREADsとWRITEsは対応するタイプのオープンの機能的な同等物として扱われます。 これはすべてのゼロ・ビットかすべての1ビットから成る特別なstateidsを使用するREADsとWRITEsを示します。 したがって、READsか別のクライアントが特別なstateidを完了しているWRITEsがaが開いている委譲を書くリコールにサーバを押し込むでしょう。 クライアントがリコールを強制する別のものが特別なstateidを完了しているWRITEは開いている委譲を読みました。
With delegations, a client is able to avoid writing data to the server when the CLOSE of a file is serviced. The file close system call 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 filesystem 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が調整されるとき、サーバにデータを書くのを避けることができます。 ファイルの厳密なシステムコールはクライアントがアプリケーションで生成された変更されたファイルデータのための安定貯蔵の不足について通知される普通のポイントです。 閉鎖では、データのための利用可能なファイルシステムスペースが超えられているなら(すなわち、サーバリターンの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 filesystem space and any applicable quotas. The server can recall delegations as a result of managing the available filesystem 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 filesystem 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 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
認証に関して、CLOSEが起こった後に変更されたデータをサーバに洗い流すのは問題が多いかもしれません。 例えば、アプリケーションのユーザはクライアントからログオフしたかもしれません、そして、満期になっていない認証資格証明書は存在していないかもしれません。 この場合、クライアントは、満期になっていない状態でそのローカルを確実にするために特別に注意を払う必要があるかもしれません。
Shepler, et al. Standards Track [Page 105] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[105ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
事実上、資格証明書は利用可能になるでしょう。 これは、必要であるとそれらの有用性を保証する資格証明書とデータを洗い流す彼らの満了のよく前か個人的なコピーの資格証明書を作るのによる満了時間を追跡することによって、達成されるかもしれません。
9.4.2. Open Delegation and File Locks
9.4.2. 開いている委譲とファイルロック
When a client holds a write open delegation, lock operations may be 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.
クライアントがaを保持するときには開いている委譲を書いてください、そして、ロック操作は局所的に実行されてもよいです。 これは義務的なファイルのロックに必要であるものを含んでいます。 委譲が、錠が闘争でないことができるのを含意するので、これができます。 同様に、通常、錠のリリースに関連しているデータを錠を入手して、洗い流すのに関連している再合法化のすべてが完了している必要はありません。
When a client holds a read open delegation, lock operations are not performed locally. All lock operations, including those requesting non-exclusive locks, are sent to the server for resolution.
クライアントが、開いている委譲がaに読み込まれるままにする場合、ロック操作は局所的に実行されません。 非排他的な錠を要求するものを含むすべてのロック操作を解決のためのサーバに送ります。
9.4.3. Handling of CB_GETATTR
9.4.3. CB_GETATTRの取り扱い
The server needs to employ special handling for a GETATTR where the target is a file that has a write open delegation in effect. The reason for this is that the client holding the write delegation may have modified the data and the server needs to reflect this change to the second client that submitted the GETATTR. Therefore, the client holding the write delegation needs to be interrogated. The server will use the CB_GETATTR operation. The only attributes that the server can reliably query via CB_GETATTR are size and change.
サーバは、目標が事実上、aが開いている委譲を書くファイルであるGETATTRに特別な取り扱いを使う必要があります。 委譲を書いてください。この理由がそれである、クライアント把持、データを変更したかもしれなくて、サーバは、GETATTRを提出した2番目のクライアントへのこの変化を反映する必要があります。 したがって、クライアント把持、査問されるべき委譲の必要性を書いてください。 サーバはCB_GETATTR操作を使用するでしょう。 サーバがCB_GETATTRを通して確かに質問できる唯一の属性が、サイズであり、変化します。
Since CB_GETATTR is being used to satisfy another client's GETATTR request, the server only needs to know if the client holding the delegation has a modified version of the file. If the client's copy of the delegated file is not modified (data or size), the server can satisfy the second client's GETATTR request from the attributes stored locally at the server. If the file is modified, the server only needs to know about this modified state. If the server determines that the file is currently modified, it will respond to the second client's GETATTR as if the file had been modified locally at the server.
CB_GETATTRが別のクライアントのGETATTR要求を満たすのに使用されているので、サーバは、委譲を保持しているクライアントがファイルの変更されたバージョンを持っているかどうかを知る必要があるだけです。 クライアントの代表として派遣されたファイルのコピーが変更されていないなら(データかサイズ)、サーバはサーバで局所的に保存された属性からの2番目のクライアントのGETATTR要求を満たすことができます。ファイルが変更されている場合にだけ、サーバは、この変更された状態に関して知る必要があります。 サーバが、ファイルが現在変更されることを決定すると、まるでファイルがサーバで局所的に変更されたかのようにそれは2番目のクライアントのGETATTRに応じるでしょう。
Since the form of the change attribute is determined by the server and is opaque to the client, the client and server need to agree on a method of communicating the modified state of the file. For the size attribute, the client will report its current view of the file size.
変化属性のフォームがサーバで決定して、クライアントにとって、不透明であるので、クライアントとサーバは、ファイルの変更された事情を伝えるメソッドに同意する必要があります。 サイズ属性のために、クライアントはファイルサイズの現在の視点を報告するでしょう。
For the change attribute, the handling is more involved.
変化属性において、取り扱いはさらにかかわります。
Shepler, et al. Standards Track [Page 106] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[106ページ]RFC3530NFSバージョン4 プロトコル2003年4月
For the client, the following steps will be taken when receiving a write delegation:
クライアントにとって、aを受けると委譲が書かれると、以下の方法を取るでしょう:
o The value of the change attribute will be obtained from the server
and cached. Let this value be represented by c.
o 変化属性の値は、サーバから得られて、キャッシュされるでしょう。 cでこの値を表させてください。
o The client will create a value greater than c that will be used
for communicating modified data is held at the client. Let this
value be represented by d.
o クライアントは変更されたデータを伝えるのに使用されるcがクライアントに保持されるよりすばらしい状態で値を作成するでしょう。 dでこの値を表させてください。
o When the client is queried via CB_GETATTR for the change
attribute, it checks to see if it holds modified data. If the
file is modified, the value d is returned for the change attribute
value. If this file is not currently modified, the client returns
the value c for the change attribute.
o クライアントが変化属性のためのCB_GETATTRを通して質問されるとき、それは、それが変更されたデータを保持するかどうか確認するためにチェックします。 ファイルが変更しているなら、変化属性値のために値dを返します。 このファイルが現在変更されないなら、クライアントは変化属性のために値cを返します。
For simplicity of implementation, the client MAY for each CB_GETATTR return the same value d. This is true even if, between successive CB_GETATTR operations, the client again modifies in the file's data or metadata in its cache. The client can return the same value because the only requirement is that the client be able to indicate to the server that the client holds modified data. Therefore, the value of d may always be c + 1.
実装の簡単さのために、各CB_GETATTRが同じ値dを返すので、クライアントはそうするかもしれません。 クライアントが再び中で連続したCB_GETATTR操作の間でキャッシュにおけるファイルのデータかメタデータを変更しても、これは本当です。 唯一の要件がクライアントが、クライアントが変更されたデータを保持するのをサーバに示すことができるということであるので、クライアントは同じ値を返すことができます。 したがって、いつもdの値はc+1であるかもしれません。
While the change attribute is opaque to the client in the sense that it has no idea what units of time, if any, the server is counting change with, it is not opaque in that the client has to treat it as an unsigned integer, and the server has to be able to see the results of the client's changes to that integer. Therefore, the server MUST encode the change attribute in network order when sending it to the client. The client MUST decode it from network order to its native order when receiving it and the client MUST encode it network order when sending it to the server. For this reason, change is defined as an unsigned integer rather than an opaque array of octets.
サーバがもしあればどんなユニットの回重要であるかというどんな考えもそれで交換しない意味におけるクライアントにとって、変化属性は不透明ですが、クライアントが符号のない整数としてそれを扱わなければならないので、それは不透明ではありません、そして、サーバはその整数へのクライアントの変化の結果を見ることができなければなりません。 したがって、それをクライアントに送るとき、サーバはネットワークオーダーにおける変化属性をコード化しなければなりません。 クライアントはネットワークオーダーから固有のそれとクライアントを受けるとそれがコード化されなければならないオーダーまでそれを解読しなければなりません。それをサーバに送るときにはオーダーをネットワークでつないでください。この理由で、変化は八重奏の不透明な勢ぞろいよりむしろ符号のない整数と定義されます。
For the server, the following steps will be taken when providing a write delegation:
提供aであるときに、サーバにおいて、以下の方法を取るでしょう。委譲を書いてください:
o Upon providing a write delegation, the server will cache a copy of
the change attribute in the data structure it uses to record the
delegation. Let this value be represented by sc.
o 変化のコピーをキャッシュするaが、委譲、サーバに書く提供のときに、中でそれが委譲を記録するのに使用するデータ構造を結果と考えてください。 Scでこの値を表させてください。
o When a second client sends a GETATTR operation on the same file to
the server, the server obtains the change attribute from the first
client. Let this value be cc.
o 2番目のクライアントが同じファイルにおけるGETATTR操作をサーバに送るとき、サーバは最初のクライアントから変化属性を得ます。 この値がccであることをさせてください。
Shepler, et al. Standards Track [Page 107] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[107ページ]RFC3530NFSバージョン4 プロトコル2003年4月
o If the value cc is equal to sc, the file is not modified and the
server returns the current values for change, time_metadata, and
time_modify (for example) to the second client.
o 値のccがScと等しいなら、ファイルは、変更されていなくて時間の変化のための現行価値、_メタデータ、および時間_が(例えば、)2番目のクライアントに変更するサーバリターンです。
o If the value cc is NOT equal to sc, the file is currently modified
at the first client and most likely will be modified at the server
at a future time. The server then uses its current time to
construct attribute values for time_metadata and time_modify. A
new value of sc, which we will call nsc, is computed by the
server, such that nsc >= sc + 1. The server then returns the
constructed time_metadata, time_modify, and nsc values to the
requester. The server replaces sc in the delegation record with
nsc. To prevent the possibility of time_modify, time_metadata,
and change from appearing to go backward (which would happen if
the client holding the delegation fails to write its modified data
to the server before the delegation is revoked or returned), the
server SHOULD update the file's metadata record with the
constructed attribute values. For reasons of reasonable
performance, committing the constructed attribute values to stable
storage is OPTIONAL.
o 値のccがScと等しくないなら、ファイルは、現在、最初のクライアントで変更されて、将来の時間にたぶんサーバで変更されるでしょう。 そして、サーバは_メタデータと時間_が変更する時間に属性値を構成する現在の時間を使用します。 + 私たちがnscと呼ぶつもりであるScの新しい値はサーバによって計算されて、そのようなそのnsc>=Scは1です。 そして、サーバは組み立てられた時間_メタデータ、_が変更する時間、およびnsc値をリクエスタに返します。 サーバは委譲記録のScをnscに取り替えます。 _が変更する時間の可能性、時間_メタデータ、および変化が後方(委譲を取り消すか、または返す前に委譲を保持しているクライアントが変更されたデータをサーバに書かないなら、起こる)に行くように見えるのを防ぐために、サーバSHOULDは組み立てられた属性値でファイルのメタデータ記録をアップデートします。 妥当な性能の理由で、組み立てられた属性値を安定貯蔵に遂行するのは、OPTIONALです。
As discussed earlier in this section, the client MAY return the
same cc value on subsequent CB_GETATTR calls, even if the file was
modified in the client's cache yet again between successive
CB_GETATTR calls. Therefore, the server must assume that the file
has been modified yet again, and MUST take care to ensure that the
new nsc it constructs and returns is greater than the previous nsc
it returned. An example implementation's delegation record would
satisfy this mandate by including a boolean field (let us call it
"modified") that is set to false when the delegation is granted,
and an sc value set at the time of grant to the change attribute
value. The modified field would be set to true the first time cc
!= sc, and would stay true until the delegation is returned or
revoked. The processing for constructing nsc, time_modify, and
time_metadata would use this pseudo code:
以前に検討したことであるがこのセクションで、ファイルが再び連続したCB_GETATTR呼び出しの間でクライアントのキャッシュでまだ変更されていたとしても、同じccがその後のCB_GETATTRで評価するクライアント5月のリターンは呼びます。 したがって、サーバは、それが組み立てて、返す新しいnscが確実にそれが返した前のnscよりすばらしくなるようにするためにファイルが再びまだ変更されていて、注意されなければならないと仮定しなければなりません。 委譲を与えるとき、例の実装の委譲記録は設定される論理演算子分野(それが「変更されている」と言う)を含んでいることによって、この命令を虚偽で満たすでしょう、そして、Sc値は変化属性値への交付金時点で、セットしました。 変更された分野は初めてのccを本当に設定することです!Scと等しく、委譲を返すか、または取り消すまで本当のままでしょう。 nscを組み立てるための処理、_が変更する時間、および時間_メタデータはこの中間コードを使用するでしょう:
if (!modified) {
do CB_GETATTR for change and size;
(変更、)、変化とサイズのためにCB_GETATTRをしてください。
if (cc != sc)
modified = TRUE;
} else {
do CB_GETATTR for size;
}
(cc!=Sc)が=TRUEを変更したなら。 ほかサイズのためにCB_GETATTRをしてください。 }
if (modified) {
sc = sc + 1;
time_modify = time_metadata = current_time;
(変更される)、Sc+1; _をSc=調節するのは=時間_メタデータ=電流_時間を変更します。
Shepler, et al. Standards Track [Page 108] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[108ページ]RFC3530NFSバージョン4 プロトコル2003年4月
update sc, time_modify, time_metadata into file's metadata;
}
Sc、_が変更する時間、時間_メタデータをファイルのメタデータにアップデートしてください。 }
return to client (that sent GETATTR) the attributes
it requested, but make sure size comes from what
CB_GETATTR returned. Do not update the file's metadata
with the client's modified size.
クライアント(それはGETATTRを送った)にそれが要求した属性を返しなさい、ただし、サイズがGETATTRが返したすべてのCB_から来るのを確実にしてください。 クライアントの変更されたサイズでファイルのメタデータをアップデートしないでください。
o In the case that the file attribute size is different than the
server's current value, the server treats this as a modification
regardless of the value of the change attribute retrieved via
CB_GETATTR and responds to the second client as in the last step.
o ファイル属性サイズがサーバの現行価値と異なっていて、サーバは、CB_GETATTRを通して検索された変化属性の値にかかわらず変更としてこれを扱って、最後のステップのように2番目のクライアントに反応します。
This methodology resolves issues of clock differences between client and server and other scenarios where the use of CB_GETATTR break down.
この方法論はクライアントとサーバの時計差とCB_GETATTRの使用が故障する他のシナリオの問題を解決します。
It should be noted that the server is under no obligation to use CB_GETATTR and therefore the server MAY simply recall the delegation to avoid its use.
サーバがCB_GETATTRを使用するどんな義務の下にもないことに注意されるべきであり、したがって、サーバは、使用を避けるために単に委譲を思い出すかもしれません。
9.4.4. Recall of Open Delegation
9.4.4. 開いている委譲のリコール
The following events necessitate recall of an open delegation:
以下のイベントは開いている委譲のリコールを必要とします:
o Potentially conflicting OPEN request (or READ/WRITE done with
"special" stateid)
o 潜在的に闘争しているオープン要求(または、「特別な」stateidで行われたREAD/WRITE)
o SETATTR issued by another client
o 別のクライアントによって発行されたSETATTR
o REMOVE request for the file
o 削除、ファイルのための要求
o RENAME request for the file as either source or target of the
RENAME
o RENAMEのソースか目標のどちらかとしてのファイルに関する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 filesystem. If that filesystem 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が開いている委譲のリコールをもたらすかどうかがサーバファイルシステムの意味論によります。 ファイルが開いているとき、そのファイルシステムがそのようなRENAMEsを否定するなら、問題のファイルが事実上、開くことであるかどうか決定するためにリコールを実行しなければなりません。
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.
状況に加えて、そうするのがリソース規制で賢明になるなら、上では、サーバが、いつでも開いている委譲を思い出すのを選ぶかもしれません。 クライアントはリコールの可能性のためにいつも用意ができているべきです。
Shepler, et al. Standards Track [Page 109] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[109ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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.
o 委譲に関連しているファイルがもう開かれていなくて、また前のCLOSE操作を全くサーバに送らないなら、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 ファイルがクライアントに他の開いている参照を持っているなら、オープン操作をサーバに送らなければなりません。委譲stateidが、より長い間有効にならないので、クライアントはその後の使用のためのサーバで適切なstateidsを提供するでしょう。 オープン要求がクレーム_DELEGATE_CURのクレームタイプで行われるこれら。 これは、クライアントがオープンを実行する適切な権利を確立できるように、委譲stateidのプレゼンテーションを許容するでしょう。 (詳細に関して「操作18: 戸外」というセクションを見てください。)
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 ファイルロックを与えるなら、対応するLOCK操作は、実行される必要があります。 これが、申し込む、開いている委譲ケースだけを書いてください。
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 aに関しては、開いている委譲を書いてください、リコール時点でファイルがファイルのための書いている、すべて変更されたデータのための戸外をサーバに洗い流さなければならないということでないなら。委譲が存在しなかったなら、クライアントは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 aに関しては、ファイルが、サーバに洗い流される必要があるので、ファイルがまだ開いていたらリコール、どんな変更されたデータ時点でも、開いている委譲を書いてください。
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 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. To precisely maintain the associated invariant, it is required to flush any modified data in any region for which a write lock was released while the write delegation was in effect. 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.
ケース、開いている委譲を書いてください、そして、ファイルロックはいくつかの追加要件を課します。 書いてください。どのaが錠を書くかがリリースされたのでどんな領域でも関連不変式であり、それがどんな変更されたデータも洗い流すのに必要であると正確に主張する、委譲は有効でした。 書いてください。しかしながら、他のクライアントにロックされないもう一方を全く委譲が含意する戸外に書いてください、より簡単な実装がいずれか錠を書くなら洗い流すために、ファイル(すぐ上で説明されるように)のためのすべての変更されたデータが発表されたということである、開いている委譲は有効でした。
Shepler, et al. Standards Track [Page 110] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[110ページ]RFC3530NFSバージョン4 プロトコル2003年4月
An implementation need not wait until delegation recall (or deciding to voluntarily return a delegation) to perform any of the above actions, if implementation considerations (e.g., resource availability constraints) make that desirable. Generally, however, the fact that the actual open state of the file may continue to change makes it not worthwhile to send information about opens and closes to the server, except as part of delegation return. Only in the case of closing the open that resulted in obtaining the delegation would clients be likely to do this early, since, in that case, the close once done will not be undone. Regardless of the client's choices on scheduling these actions, all must be performed before the delegation is returned, including (when applicable) the close that corresponds to the open that resulted in the delegation. These actions can be performed either in previous requests or in previous operations in the same COMPOUND request.
実装は、上の動作のどれかを実行するのを委譲リコール(自発的に委譲を返すと決めて)まで待つ必要はありません、実装問題(例えば、リソース有用性規制)でそれが望ましくなるなら。 しかしながら、一般に、実際で変えるファイルの開いている事情が、続けるかもしれない情報を送るために価値があるようにならないという事実は、サーバに開いて、閉じます、委譲リターンの一部を除いて。 一度行われた閉鎖がその場合元に戻されないので、委譲を得るのに結果として生じた戸外を閉じる場合だけでは、クライアントは早くこれをしそうでしょう。 これらの動作の計画をするときのクライアントの選択にかかわらず、委譲を返す前にすべてを実行しなければなりません、委譲をもたらした戸外に対応する閉鎖を含んでいて(適切であるときに)。 前の要求か同じCOMPOUND要求における前の操作でこれらの動作を実行できます。
9.4.5. Clients that Fail to Honor Delegation Recalls
9.4.5. クライアントはHonor Delegation RecallsへのそのFailです。
A client may fail to respond to a recall for various reasons, such as a failure of the callback path from server to the client. The client may be unaware of a failure in the callback path. This lack of awareness could result in the client finding out long after the failure that its delegation has been revoked, and another client has modified the data for which the client had a delegation. This is especially a problem for the client that held a write delegation.
クライアントは様々な理由のためのリコールに応じないかもしれません、サーバからクライアントまでのコールバック経路の失敗のように。 クライアントはコールバック経路で失敗に気づかないかもしれません。 認識のこの不足は失敗のずっと後の委譲が取り消されて、別のクライアントがクライアントが委譲を持っていたデータを変更したというクライアント調査結果をもたらすかもしれません。 これによるaを保持したクライアントのための特に問題が委譲を書くということです。
The server also has a dilemma in that the client that fails to respond to the recall might also be sending other NFS requests, including those that renew the lease before the lease expires. Without returning an error for those lease renewing operations, the server leads the client to believe that the delegation it has is in force.
サーバには、また、また、リコールに応じないクライアントが他のNFS要求を送るかもしれないので、ジレンマがあります、リースが期限が切れる前にリースを更新するものを含んでいて。 それらのリース更新操作のための誤りを返さないで、サーバは、クライアントが、それが持っている委譲が有効であると信じているように導きます。
This difficulty is solved by the following rules:
この困難は以下の規則で解決されています:
o When the callback path is down, the server MUST NOT revoke the
delegation if one of the following occurs:
o コールバック経路が下がっているとき、以下の1つが起こるなら、サーバは委譲を取り消してはいけません:
- The client has issued a RENEW operation and the server has
returned an NFS4ERR_CB_PATH_DOWN error. The server MUST renew
the lease for any record locks and share reservations the
client has that the server has known about (as opposed to those
locks and share reservations the client has established but not
yet sent to the server, due to the delegation). The server
SHOULD give the client a reasonable time to return its
delegations to the server before revoking the client's
delegations.
- クライアントはRENEW操作を発行しました、そして、サーバは_PATH_DOWN誤りをNFS4ERR_CBに返しました。 サーバはクライアントが持っているどんな記録的な錠とシェアの予約のためのサーバが知っていたリースも更新しなければなりません(設立しますが、それらの錠とシェアの予約と対照的にクライアントはまだサーバに発信していません、委譲のため)。 サーバSHOULDはクライアントの委譲を取り消す前に委譲をサーバに返す妥当な時間をクライアントに与えます。
Shepler, et al. Standards Track [Page 111] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[111ページ]RFC3530NFSバージョン4 プロトコル2003年4月
- The client has not issued a RENEW operation for some period of
time after the server attempted to recall the delegation. This
period of time MUST NOT be less than the value of the
lease_time attribute.
- サーバが、委譲を思い出すのを試みた後にクライアントはいつかの期間の間、RENEW操作を発行していません。 この期間はリース_時間属性の値以下であるはずがありません。
o When the client holds a delegation, it can not rely on operations,
except for RENEW, that take a stateid, to renew delegation leases
across callback path failures. The client that wants to keep
delegations in force across callback path failures must use RENEW
to do so.
o クライアントが委譲を保持するとき、それはRENEW以外のコールバック経路失敗の向こう側に委譲リースを更新するためにstateidを取る操作に依存できません。 コールバック経路失敗の向こう側に大挙して委譲を保ちたがっているクライアントは、そうするのにRENEWを使用しなければなりません。
9.4.6. Delegation Revocation
9.4.6. 委譲取消し
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.
いいえが開くなら、ファイルのためにポイントに存在してください。委譲は取り消されます、次に、取消しの通知が不要であるということです。 しかしながら、ファイルのためのクライアントの現在の変更されたデータがあれば、アプリケーションのユーザは通知されるべきです。 残念ながら、選考中の応募者がクライアントに存在していないかもしれないので、ユーザに通知するのは可能でないかもしれません。 開いている委譲を書いてください。セクションを見てください、「取消し回復、」 追加詳細のために。
9.5. Data Caching and Revocation
9.5. データキャッシュと取消し
When locks and delegations are revoked, the assumptions upon which successful caching depend are no longer guaranteed. For any locks or share reservations that have been revoked, the corresponding owner 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
多くの場合、ロック所有者への通知はオープン・ファイルへの次の、そして、その後のREADs/WRITEsの上、または、閉鎖の上で単に誤りを返すのから成るでしょう。 クライアントにとって、利用可能なメソッドがそのような通知を不可能にする、確かな誤り
Shepler, et al. Standards Track [Page 112] RFC 3530 NFS version 4 Protocol April 2003
Shepler、他 規格Track[112ページ]RFC3530NFSバージョン4 プロトコル2003年4月
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ポップアップは適切であるかもしれません。
9.5.1. Revocation Recovery for Write Open Delegation
9.5.1. 取消し回復、開いている委譲を書いてください。
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.
ファイルが開いていない間、aのための取消し回復はクライアントキャッシュにおける、変更されたデータの増刊を開いている委譲姿勢に書きます。 この状況、そうしないどんなクライアントでも、各閉鎖のサーバへの豊富な変更されたデータは、ユーザが取消しの結果、失敗の適切な通知を受け取るのを確実にしなければなりません。 そのような状況が問題を修正するために人間の行為を必要とするかもしれないので、適切なユーザか管理者に通知する通知体系が必要であるかもしれません。 伐採とコンソールメッセージは典型的な例です。
一覧
スポンサーリンク
