[要約] RFC 7931は、NFSv4.0の移行に関する仕様の更新を提供しています。このRFCの目的は、NFSv4.0の移行プロセスを改善し、互換性の問題を解決することです。
Internet Engineering Task Force (IETF) D. Noveck, Ed.
Request for Comments: 7931 HPE
Updates: 7530 P. Shivam
Category: Standards Track C. Lever
ISSN: 2070-1721 B. Baker
ORACLE
July 2016
NFSv4.0 Migration: Specification Update
NFSv4.0の移行：仕様の更新
Abstract
概要
The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0. This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC 7530.
NFSv4の移行機能を使用すると、単一のファイルシステムの責任を、クライアントを中断することなく、あるサーバーから別のサーバーに転送できます。最近の実装経験では、NFSv4.0のこの機能の既存の仕様に問題があることが示されています。このドキュメントでは、問題のある領域を特定し、RFC 7530のNFSv4.0仕様を更新する改訂された仕様テキストを提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7931.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7931で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Data Type Definitions . . . . . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Client Identity Definition . . . . . . . . . . . . . . . . . 7
5.1. Differences from Replaced Sections . . . . . . . . . . . 7
5.2. Client Identity Data Items . . . . . . . . . . . . . . . 8
5.2.1. Client Identity Structure . . . . . . . . . . . . . . 9
5.2.2. Client Identity Shorthand . . . . . . . . . . . . . . 11
5.3. Server Release of Client ID . . . . . . . . . . . . . . . 13
5.4. Client ID String Approaches . . . . . . . . . . . . . . . 14
5.5. Non-uniform Client ID String Approach . . . . . . . . . . 16
5.6. Uniform Client ID String Approach . . . . . . . . . . . . 16
5.7. Mixing Client ID String Approaches . . . . . . . . . . . 18
5.8. Trunking Determination when Using Uniform Client ID
Strings . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.9. Client ID String Construction Details . . . . . . . . . . 26
6. Locking and Multi-Server Namespace . . . . . . . . . . . . . 28
6.1. Lock State and File System Transitions . . . . . . . . . 28
6.1.1. Migration and State . . . . . . . . . . . . . . . . . 29
6.1.1.1. Migration and Client IDs . . . . . . . . . . . . 31
6.1.1.2. Migration and State Owner Information . . . . . . 32
6.1.2. Replication and State . . . . . . . . . . . . . . . . 36
6.1.3. Notification of Migrated Lease . . . . . . . . . . . 36
6.1.4. Migration and the lease_time Attribute . . . . . . . 39
7. Server Implementation Considerations . . . . . . . . . . . . 39
7.1. Relation of Locking State Transfer to Other Aspects of
File System Motion . . . . . . . . . . . . . . . . . . . 39
7.2. Preventing Locking State Modification during Transfer . . 41
8. Additional Changes . . . . . . . . . . . . . . . . . . . . . 44
8.1. Summary of Additional Changes from Previous Documents . . 45
8.2. NFS4ERR_CLID_INUSE Definition . . . . . . . . . . . . . . 45
8.3. NFS4ERR_DELAY Return from RELEASE_LOCKOWNER . . . . . . . 45
8.4. Operation 35: SETCLIENTID -- Negotiate Client ID . . . . 46
8.5. Security Considerations for Inter-server Information
Transfer . . . . . . . . . . . . . . . . . . . . . . . . 51
8.6. Security Considerations Revision . . . . . . . . . . . . 51
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1. Normative References . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . 52
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
This Standards Track document corrects the existing definitive specification of the NFSv4.0 protocol described in [RFC7530]. Given this fact, one should take the current document into account when learning about NFSv4.0, particularly if one is concerned with issues that relate to:
このStandards Trackドキュメントは、[RFC7530]で説明されているNFSv4.0プロトコルの既存の決定的な仕様を修正します。この事実を踏まえると、特に以下に関連する問題に関心がある場合は、NFSv4.0について学習するときに現在のドキュメントを考慮する必要があります。
o File system migration, particularly when it involves transparent state migration.
o ファイルシステムの移行、特に透過的な状態移行が含まれる場合。
o The construction and interpretation of the nfs_client_id4 structure and particularly the requirements on the id string within it, referred to below as a "client ID string".
o nfs_client_id4構造の構築と解釈、特にその中のid文字列の要件。以下では「クライアントID文字列」と呼びます。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following definitions are included to provide an appropriate context for the reader. This section is derived from Section 1.5 of [RFC7530] but has been adapted to the needs of this document.
以下の定義は、読者に適切なコンテキストを提供するために含まれています。このセクションは、[RFC7530]のセクション1.5から派生していますが、このドキュメントのニーズに合わせて調整されています。
Boot Instance Id: A boot instance id is an identifier, such as a boot time, allowing two different instances of the same client to be reliably distinguished. A boot instance id is opaque to the server and is often used as the verifier field in the nfs_client_id4 structure, which identifies the client to the server.
ブートインスタンスID：ブートインスタンスIDは、ブート時間などの識別子であり、同じクライアントの2つの異なるインスタンスを確実に区別できるようにします。ブートインスタンスIDはサーバーに対して不透明であり、サーバーに対してクライアントを識別するnfs_client_id4構造体の検証フィールドとしてよく使用されます。
Client: A client is an entity that accesses the NFS server's resources. The client may be an application that contains the logic to access the NFS server directly. The client may also be the traditional operating system client that provides remote file system services for a set of applications.
クライアント：クライアントは、NFSサーバーのリソースにアクセスするエンティティです。クライアントは、NFSサーバーに直接アクセスするためのロジックを含むアプリケーションである場合があります。クライアントは、一連のアプリケーションにリモートファイルシステムサービスを提供する従来のオペレーティングシステムクライアントでもかまいません。
With reference to byte-range locking, the client is also 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つ以上のアプリケーションのために一連のロックを維持するエンティティでもあります。このクライアントは、管理するロックのクラッシュまたは障害回復を担当します。
Note that multiple clients may share the same transport and connection, and multiple clients may exist on the same network node.
複数のクライアントが同じトランスポートと接続を共有し、複数のクライアントが同じネットワークノードに存在する場合があることに注意してください。
Client ID: A client ID is a 64-bit quantity (in the form of a clientid4) used as a unique, shorthand reference to a particular client instance, identified by a client-supplied verifier (in the form of a boot instance id) and client ID string. The server is responsible for supplying the client ID.
クライアントID：クライアントIDは、64ビットの数量（clientid4の形式）であり、特定のクライアントインスタンスへの一意の省略形の参照として使用され、クライアントが提供するベリファイア（ブートインスタンスIDの形式）によって識別されます。およびクライアントID文字列。サーバーは、クライアントIDを提供します。
File System: A file system is the collection of objects on a server that share the same fsid attribute (see Section 5.8.1.9 of [RFC7530]).
ファイルシステム：ファイルシステムは、同じfsid属性を共有するサーバー上のオブジェクトのコレクションです（[RFC7530]のセクション5.8.1.9を参照）。
Grace Period: A grace period is an interval of time during which the server will only grant locking requests to reclaim existing locks but not those that create new locks. This gives clients an opportunity to re-establish locking state in response to a potentially disruptive event. The grace period may be general to help deal with server reboot, or it may be specific to a file system to deal with file system migration when transparent state migration is not provided.
猶予期間：猶予期間は、サーバーが既存のロックを再利用するためのロック要求のみを許可し、新しいロックを作成する要求は許可しない期間です。これにより、クライアントは、混乱を招く可能性のあるイベントに対応して、ロック状態を再確立する機会を得られます。猶予期間は、サーバーの再起動を処理するのに役立つ一般的なものである場合と、透過的な状態移行が提供されていない場合にファイルシステムの移行を処理することがファイルシステムに固有のものである場合があります。
Lease: A lease is an interval of time defined by the server for which the client is irrevocably granted a lock. At the end of a lease period, the lock may be revoked if the lease has not been extended. The lock must be revoked if a conflicting lock has been granted after the lease interval.
リース：リースは、クライアントがロックを取り返しのつかない形で許可されるサーバーによって定義される時間間隔です。リース期間の終了時に、リースが延長されていない場合、ロックが取り消されることがあります。リース期間後に競合するロックが付与されている場合は、ロックを取り消す必要があります。
All leases granted by a server have the same fixed duration. Note that the fixed interval duration 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 record (byte-range) locks as well as share reservations unless specifically stated otherwise.
ロック：「ロック」という用語は、特に明記されていない限り、レコード（バイト範囲）ロックおよび共有予約を指すために使用されます。
Lock-Owner: Each byte-range lock is associated with a specific lock-owner and an open-owner. The lock-owner consists of a client ID and an opaque owner string. The client presents this to the server to establish the ownership of the byte-range lock as needed.
ロック所有者：各バイト範囲ロックは、特定のロック所有者とオープン所有者に関連付けられています。ロック所有者は、クライアントIDと不透明な所有者文字列で構成されます。クライアントはこれをサーバーに提示して、必要に応じてバイト範囲ロックの所有権を確立します。
Open-Owner: Each open file is associated with a specific open-owner, which consists of a client ID and an opaque owner string. The client presents this to the server to establish the ownership of the open as needed.
オープンオーナー：開いている各ファイルは、クライアントIDと不透明なオーナー文字列で構成される特定のオープンオーナーに関連付けられています。クライアントはこれをサーバーに提示して、必要に応じてオープンの所有権を確立します。
Server: A server is an entity responsible for coordinating client access to a set of file systems.
サーバー：サーバーは、一連のファイルシステムへのクライアントアクセスの調整を担当するエンティティです。
Stateid: A stateid is a 128-bit quantity returned by a server that uniquely identifies the open and locking states provided by the server for a specific open-owner or lock-owner/open-owner pair for a specific file and type of lock.
Stateid：Stateidは、サーバーによって返される128ビットの数量であり、特定のファイルとロックのタイプについて、特定のオープン所有者またはロック所有者/オープン所有者のペアに対してサーバーによって提供されるオープン状態とロック状態を一意に識別します。
Trunking: A situation in which multiple physical addresses are connected to the same logical server.
トランキング：複数の物理アドレスが同じ論理サーバーに接続されている状況。
Verifier: A verifier is a quantity, in the form of a verifier4, that allows one party to an interaction to be aware of a reinitialization or other significant change to the state of the other party. In [RFC7530], this term most often designates the verifier field of an nfs_client_id4, in which a boot instance id is placed to allow the server to determine when there has been a client reboot, making it necessary to eliminate locking state associated with the previous instance of the same client.
ベリファイア：ベリファイアは、インタラクションの一方のパーティが他方のパーティの状態の再初期化またはその他の重要な変化を認識できるようにするベリファイア4の形式の数量です。 [RFC7530]では、この用語は最も頻繁にnfs_client_id4のベリファイアフィールドを示します。クライアントが再起動したときをサーバーが判別できるように、ブートインスタンスIDが配置され、以前の状態に関連するロック状態を排除する必要があります。同じクライアントのインスタンス。
This section contains a table that shows where data types referred to in this document are defined.
このセクションには、このドキュメントで参照されているデータ型が定義されている場所を示す表が含まれています。
+-----------------+--------------------------------+
| Item | Section |
+-----------------+--------------------------------+
| cb_client4 | Section 2.2.11 in [RFC7530] |
| clientaddr4 | Section 2.2.10 in [RFC7530] |
| clientid4 | Section 2.1 in [RFC7530] |
| lock_owner4 | Section 2.2.14 in [RFC7530] |
| nfs_client_id4 | Section 5.2.1 (this document) |
| open_owner4 | Section 2.2.13 in [RFC7530] |
| verifier4 | Section 2.1 in [RFC7530] |
+-----------------+--------------------------------+
Implementation experience with transparent state migration has exposed a number of problems with the then existing specifications of this feature in [RFC7530] and predecessors. The symptoms were:
透過的な状態移行の実装経験により、[RFC7530]とその前身でこの機能の当時存在していた仕様に関する多くの問題が明らかになりました。症状は次のとおりです。
o After migration of a file system, a reboot of the associated client was not appropriately dealt with, in that the state associated with the rebooting client was not promptly freed.
o ファイルシステムの移行後、関連するクライアントの再起動は適切に処理されませんでした。再起動するクライアントに関連する状態がすぐに解放されなかったためです。
o Situations can arise whereby a given server has multiple leases with the same nfs_client_id4 (consisting of id and verifier fields), when the protocol clearly assumes there can be only one.
o 特定のサーバーが同じnfs_client_id4（idフィールドとverifierフィールドで構成される）を持つ複数のリースを持っているという状況が発生する可能性がありますが、プロトコルは1つしか存在できないと明確に想定しています。
o Excessive client implementation complexity since clients have to deal with situations in which a single client can wind up with its locking state with a given server divided among multiple leases each with its own clientid4.
o 単一のクライアントが、それぞれが独自のclientid4を持つ複数のリースに分割された特定のサーバーでロック状態に陥る可能性がある状況に対処する必要があるため、クライアント実装が過度に複雑になります。
An analysis of these symptoms leads to the conclusion that existing specifications have erred. They assume that locking state, including both state ids and clientid4s, should be transferred as part of transparent state migration. The troubling symptoms arise from the failure to describe how migrating state is to be integrated with existing client definition structures on the destination server.
これらの症状を分析すると、既存の仕様に誤りがあるという結論につながります。彼らは、状態IDとclientid4sの両方を含むロック状態を透過的な状態移行の一部として転送する必要があると想定しています。厄介な症状は、移行状態を移行先サーバーの既存のクライアント定義構造と統合する方法を説明できないことから発生します。
The need for the server to appropriately merge stateids associated with a common client boot instance encounters a difficult problem. The issue is that the common client practice with regard to the presentation of unique strings specifying client identity makes it essentially impossible for the client to determine whether or not two stateids, originally generated on different servers, are referable to the same client. This practice is allowed and endorsed by the existing NFSv4.0 specification [RFC7530].
一般的なクライアントブートインスタンスに関連付けられた状態IDをサーバーが適切にマージする必要があるため、困難な問題が発生します。問題は、クライアントIDを指定する一意の文字列の表示に関する一般的なクライアントの慣習により、元々異なるサーバーで生成された2つの状態IDが同じクライアントで参照可能かどうかをクライアントが判断することが本質的に不可能になることです。この慣行は、既存のNFSv4.0仕様[RFC7530]によって許可および承認されています。
However, upon the prototyping of clients implementing an alternative approach, it has been found that there exist servers that do not work well with these new clients. It appears that current circumstances, in which a particular client implementation pattern had been adopted universally, have resulted in some servers not being able to interoperate against alternate client implementation patterns. As a result, we have a situation that requires careful attention to untangling compatibility issues.
ただし、代替アプローチを実装するクライアントのプロトタイピングを行うと、これらの新しいクライアントではうまく機能しないサーバーが存在することがわかりました。特定のクライアント実装パターンが普遍的に採用されていた現在の状況では、一部のサーバーが代替クライアント実装パターンに対して相互運用できなくなったようです。その結果、互換性の問題を解決するために細心の注意を払う必要がある状況があります。
This document updates the existing NFSv4.0 specification [RFC7530] as follows:
このドキュメントは、既存のNFSv4.0仕様[RFC7530]を次のように更新します。
o It makes clear that NFSv4.0 supports multiple approaches to the construction of client ID strings, including those formerly endorsed by existing NFSV4.0 specifications and those currently being widely deployed.
o NFSv4.0は、以前に既存のNFSV4.0仕様で承認されていたものや現在広く展開されているものを含め、クライアントID文字列の構築に対する複数のアプローチをサポートしていることは明らかです。
o It explains how clients can effectively use client ID strings that are presented to multiple servers.
o 複数のサーバーに提示されるクライアントID文字列をクライアントが効果的に使用する方法について説明します。
o It addresses the potential compatibility issues that might arise for clients adopting a previously non-favored client ID string construction approach including the existence of servers that have problems with the new approach.
o これは、以前は好まれていなかったクライアントID文字列構築アプローチを採用しているクライアントで発生する可能性がある、新しいアプローチに問題のあるサーバーの存在を含む、潜在的な互換性の問題に対処します。
o It gives some guidance regarding the factors that might govern clients' choice of a client ID string construction approach and recommends that clients construct client ID strings in a manner that supports lease merger if they intend to support transparent state migration.
o クライアントのクライアントID文字列構成アプローチの選択を左右する可能性のある要因に関するいくつかのガイダンスを提供し、透過的な状態移行をサポートする場合は、クライアントがリースのマージをサポートする方法でクライアントID文字列を構成することを推奨します。
o It specifies how state is to be transparently migrated, including defining how state that arrives at a new server as part of migration is to be merged into existing leases for clients connected to the target server.
o 移行の一部として新しいサーバーに到着する状態をターゲットサーバーに接続されているクライアントの既存のリースにマージする方法の定義を含め、状態を透過的に移行する方法を指定します。
o It makes further clarifications and corrections to address cases where the specification text does not take proper account of the issues raised by state migration or where it has been found that the existing text is insufficiently clear. This includes a revised definition of the SETCLIENTID operation in Section 8.4, which replaces Section 16.33 in [RFC7530].
o 仕様のテキストが州の移行によって引き起こされた問題を適切に考慮していない場合、または既存のテキストが十分に明確でないことが判明した場合に対処するために、さらに明確化および修正を行います。これには、[RFC7530]のセクション16.33に代わるセクション8.4のSETCLIENTIDオペレーションの改訂された定義が含まれます。
For a more complete explanation of the choices made in addressing these issues, see [INFO-MIGR].
これらの問題に対処するために行われた選択のより完全な説明については、[INFO-MIGR]を参照してください。
This section is a replacement for Sections 9.1.1 and 9.1.2 in [RFC7530]. The replaced sections are named "Client ID" and "Server Release of Client ID", respectively.
このセクションは、[RFC7530]のセクション9.1.1および9.1.2の置き換えです。置き換えられたセクションの名前は、それぞれ「クライアントID」と「サーバーリリースのクライアントID」です。
It supersedes the replaced sections.
置き換えられたセクションに取って代わります。
Because of the need for greater attention to and careful description of this area, this section is much larger than the sections it replaces. The principal changes/additions made by this section are:
この領域をより注意深く説明する必要があるため、このセクションは、それが置き換えるセクションよりもはるかに大きくなっています。このセクションで行われた主な変更/追加は次のとおりです。
o It corrects inconsistencies regarding the possible role or non-role of the client IP address in construction of client ID strings.
o クライアントID文字列の構築におけるクライアントIPアドレスの可能な役割または非役割に関する不整合を修正します。
o It clearly addresses the need to maintain a non-volatile record across reboots of client ID strings or any changeable values that are used in their construction.
o これは、クライアントID文字列の再起動またはその構築で使用される変更可能な値全体で不揮発性レコードを維持する必要性に明確に対処しています。
o It provides a more complete description of circumstances leading to clientid4 invalidity and the appropriate recovery actions.
o clientid4の無効化と適切な回復アクションに至る状況のより完全な説明を提供します。
o It presents, as valid alternatives, two approaches to client ID string construction (named "uniform" and "non-uniform") and gives some implementation guidance to help implementers choose one or the other of these.
o これは、有効な代替手段として、クライアントID文字列構築への2つのアプローチ（「ユニフォーム」と「非ユニフォーム」という名前）を示し、実装者がこれらのいずれかを選択するのに役立ついくつかの実装ガイダンスを提供します。
o It adds a discussion of issues involved for clients in interacting with servers whose behavior is not consistent with use of uniform client ID strings.
o これは、クライアントの動作が統一されたクライアントID文字列の使用と一致しないサーバーとの対話に関連する問題の説明を追加します。
o It adds a description of how server behavior might be used by the client to determine when multiple server IP addresses correspond to the same server.
o 複数のサーバーIPアドレスが同じサーバーに対応するときを決定するために、クライアントがサーバー動作をどのように使用するかについての説明を追加します。
The NFSv4 protocol contains a number of protocol entities to identify clients and client-based entities for locking-related purposes:
NFSv4プロトコルには、ロック関連の目的でクライアントとクライアントベースのエンティティを識別するための多数のプロトコルエンティティが含まれています。
o The nfs_client_id4 structure, which uniquely identifies a specific client boot instance. That identification is presented to the server by doing a SETCLIENTID operation. The SETCLIENTID operation is described in Section 8.4, which modifies a description in Section 16.33 of [RFC7530].
o nfs_client_id4構造。特定のクライアントブートインスタンスを一意に識別します。その識別は、SETCLIENTID操作を実行することによってサーバーに提示されます。 SETCLIENTID操作については、[RFC7530]のセクション16.33の説明を変更するセクション8.4で説明されています。
o The clientid4, which is returned by the server upon completion of a successful SETCLIENTID operation. This id is used by the client to identify itself when doing subsequent locking-related operations. A clientid4 is associated with a particular lease whereby a client instance holds state on a server instance and may become invalid due to client reboot, server reboot, or other circumstances.
o SETCLIENTID操作が正常に完了するとサーバーから返されるclientid4。このIDは、後続のロック関連の操作を実行するときに、クライアントが自身を識別するために使用します。 clientid4は特定のリースに関連付けられています。これにより、クライアントインスタンスはサーバーインスタンスの状態を保持し、クライアントの再起動、サーバーの再起動、またはその他の状況により無効になる場合があります。
o Opaque arrays, which are used together with the clientid4 to designate within-client entities (e.g., processes) as the owners of opens (open-owners) and owners of byte-range locks (lock-owners).
o 不透明な配列。これはclientid4と一緒に使用され、クライアント内エンティティ（プロセスなど）をオープンの所有者（オープン所有者）およびバイト範囲ロックの所有者（ロック所有者）として指定します。
The basis of the client identification infrastructure is encapsulated in the following data structure, which also appears in Section 9.1.1 of [RFC7530]:
クライアント識別インフラストラクチャの基礎は、[RFC7530]のセクション9.1.1にも記載されている次のデータ構造にカプセル化されています。
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
The nfs_client_id4 structure uniquely defines a particular client boot instance as follows:
nfs_client_id4構造体は、次のように特定のクライアントブートインスタンスを一意に定義します。
o The id field is a variable-length string that uniquely identifies a specific client. Although it is described here as a string and is often referred to as a "client string", it should be understood that the protocol defines this as opaque data. In particular, those receiving such an id should not assume that it will be in the UTF-8 encoding. Servers MUST NOT reject an nfs_client_id4 simply because the id string does not follow the rules of UTF-8 encoding.
o idフィールドは、特定のクライアントを一意に識別する可変長文字列です。ここでは文字列として記述され、しばしば「クライアント文字列」と呼ばれますが、プロトコルがこれを不透明なデータとして定義していることを理解する必要があります。特に、そのようなIDを受け取る人は、UTF-8エンコーディングであると想定すべきではありません。 id文字列がUTF-8エンコーディングのルールに従っていないという理由だけで、サーバーはnfs_client_id4を拒否してはなりません（MUST NOT）。
The encoding and decoding processes for this field (e.g., use of network byte order) need to result in the same internal representation whatever the endianness of the originating and receiving machines.
このフィールドのエンコードおよびデコードプロセス（ネットワークバイトオーダーの使用など）は、発信元マシンと受信先マシンのエンディアンが何であれ、同じ内部表現になる必要があります。
o The verifier field contains a client boot instance identifier that is used by the server to detect client reboots. Only if the boot instance is different from that which the server has previously recorded in connection with the client (as identified by the id field) does the server cancel the client's leased state. This cancellation occurs once it receives confirmation of the new nfs_clientd4 via SETCLIENTID_CONFIRM. The SETCLIENTID_CONFIRM operation is described in Section 16.34 of [RFC7530].
o ベリファイアフィールドには、サーバーがクライアントの再起動を検出するために使用するクライアントブートインスタンス識別子が含まれています。ブートインスタンスが、サーバーが（idフィールドで識別される）クライアントに関連して以前に記録したものと異なる場合のみ、サーバーはクライアントのリース状態をキャンセルします。このキャンセルは、SETCLIENTID_CONFIRMを介して新しいnfs_clientd4の確認を受け取ると発生します。 SETCLIENTID_CONFIRMオペレーションについては、[RFC7530]のセクション16.34で説明されています。
In order to prevent the possibility of malicious destruction of the locking state associated with a client, the server MUST NOT cancel a client's leased state if the principal that established the state for a given id string is not the same as the principal issuing the SETCLIENTID.
クライアントに関連付けられたロック状態の悪意のある破壊の可能性を防ぐために、特定のid文字列の状態を確立したプリンシパルがSETCLIENTIDを発行するプリンシパルと同じでない場合、サーバーはクライアントのリース状態をキャンセルしてはなりません。
There are several considerations for how the client generates the id string:
クライアントがID文字列を生成する方法には、いくつかの考慮事項があります。
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つのクライアントがリース状態を突然予期せずにキャンセルすることまでさまざまです。
o The string should be selected so that subsequent incarnations (e.g., reboots) of the same client cause the client to present the same string. The implementer 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 NFSv4 server.
o 同じクライアントの後続のインカネーション（再起動など）によってクライアントに同じ文字列が表示されるように、文字列を選択する必要があります。ローカルディスクがなく、すべてのファイルアクセスがNFSv4サーバーからである環境での実装の使用が妨げられるため、実装者は文字列をローカルファイルに記録する必要があるアプローチに対して警告されます。
o The string MAY be different for each server network address that the client accesses rather than common to all server network addresses.
o 文字列は、すべてのサーバーネットワークアドレスに共通ではなく、クライアントがアクセスするサーバーネットワークアドレスごとに異なる場合があります。
The considerations that might influence a client to use different strings for different network server addresses are explained in Section 5.4.
異なるネットワークサーバーアドレスに異なる文字列を使用するようクライアントに影響を与える可能性のある考慮事項については、セクション5.4で説明します。
o The algorithm for generating the string should not assume that the clients' network addresses will remain the same for any set period of time. Even while the client is still running in its current incarnation, changes might occur between client incarnations.
o 文字列を生成するアルゴリズムは、クライアントのネットワークアドレスが設定された期間同じままであることを想定してはなりません。クライアントが現在のインカネーションで実行中であっても、クライアントインカネーション間で変更が発生する可能性があります。
Changes to the client ID string due to network address changes would result in successive SETCLIENTID operations for the same client appearing as from different clients, interfering with the use of the nfs_client_id4 verifier field to cancel state associated with previous boot instances of the same client.
ネットワークアドレスの変更によるクライアントID文字列の変更により、同じクライアントの一連のSETCLIENTID操作が異なるクライアントから表示され、同じクライアントの以前のブートインスタンスに関連付けられた状態をキャンセルするためのnfs_client_id4検証フィールドの使用が妨げられます。
The difficulty is more severe if the client address is the only client-based information in the client ID string. In such a case, there is a real risk that after the client gives up the network address, another client, using the same algorithm, would generate a conflicting id string. This would be likely to cause an inappropriate loss of locking state. See Section 5.9 for detailed guidance regarding client ID string construction.
クライアントアドレスがクライアントID文字列内の唯一のクライアントベースの情報である場合、問題はさらに深刻になります。このような場合、クライアントがネットワークアドレスを放棄した後、同じアルゴリズムを使用する別のクライアントが競合するID文字列を生成するという実際のリスクがあります。これにより、ロック状態が不適切に失われる可能性があります。クライアントID文字列の構成に関する詳細なガイダンスについては、セクション5.9を参照してください。
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 client ID) is assigned by the server and should be chosen so that it will not conflict with a client ID previously assigned by the same server and, to the degree practicable, by other servers as well. This applies across server restarts or reboots.
SETCLIENTIDおよびSETCLIENTID_CONFIRMシーケンスが正常に完了すると、クライアントは、長くてコンパクトでないnfs_client_id4構造体の代わりに、clientid4タイプの短縮クライアント識別子を使用します。この省略形のクライアント識別子（クライアントID）はサーバーによって割り当てられ、同じサーバーによって以前に割り当てられたクライアントIDと競合しないように、また他のサーバーによっても実行可能な程度に競合しないように選択する必要があります。これは、サーバーの再起動または再起動全体に適用されます。
Establishment of the client ID 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 locks, share reservations, and delegation states not requested using the CLAIM_DELEGATE_PREV claim type associated with a client having the same identity. For a discussion of delegation state recovery, see Section 10.2.1 of [RFC7530].
クライアントの新しいインカネーションによるクライアントIDの確立は、新しいクライアントのインカネーションがリースを待機するのを強制するのではなく、クライアントの以前のインカネーションがサーバー上で持っていた可能性があるリース状態を即座に破壊する効果もあります。期限切れ。リース状態を解除すると、サーバーは、同じIDを持つクライアントに関連付けられたCLAIM_DELEGATE_PREVクレームタイプを使用して要求されていないすべてのロック、共有予約、および委任状態を削除します。委任状態の回復については、[RFC7530]のセクション10.2.1を参照してください。
Note that the SETCLIENTID and SETCLIENTID_CONFIRM operations have a secondary purpose of establishing the information the server needs to make callbacks to the client for the purpose of supporting delegations. The client is able to change this information via SETCLIENTID and SETCLIENTID_CONFIRM within the same incarnation of the client without causing removal of the client's leased state.
SETCLIENTIDおよびSETCLIENTID_CONFIRM操作には、委任をサポートする目的でサーバーがクライアントにコールバックを行うために必要な情報を確立するという副次的な目的があることに注意してください。クライアントは、クライアントのリース状態を削除することなく、クライアントの同じインカネーション内でSETCLIENTIDおよびSETCLIENTID_CONFIRMを介してこの情報を変更できます。
Distinct servers MAY assign clientid4s independently, and they will generally do so. Therefore, a client has to be prepared to deal with multiple instances of the same clientid4 value received on distinct IP addresses, denoting separate entities. When trunking of server IP addresses is not a consideration, a client should keep track of <IP-address, clientid4> pairs, so that each pair is distinct. For a discussion of how to address the issue in the face of possible trunking of server IP addresses, see Section 5.4.
個別のサーバーはclientid4を独立して割り当てることができます（MAY）。通常、それらは割り当てられます。したがって、クライアントは、別個のエンティティーを示す、別個のIPアドレスで受信された同じclientid4値の複数のインスタンスを処理する準備をする必要があります。サーバーIPアドレスのトランキングが考慮されない場合、クライアントは<IP-address、clientid4>ペアを追跡して、各ペアが区別されるようにする必要があります。サーバーIPアドレスのトランキングの可能性に直面して問題に対処する方法の説明については、セクション5.4を参照してください。
Owners of opens and owners of byte-range locks are separate entities and remain separate even if the same opaque arrays are used to designate owners of each. The protocol distinguishes between open-owners (represented by open_owner4 structures) and lock-owners (represented by lock_owner4 structures).
オープンの所有者とバイト範囲ロックの所有者は別々のエンティティであり、同じ不透明な配列を使用してそれぞれの所有者を指定しても、別々のままです。プロトコルは、open-owners（open_owner4構造体で表される）とlock-owners（lock_owner4構造体で表される）を区別します。
Both sorts of owners consist of a clientid4 and an opaque owner string. For each client, there is a set of distinct owner values used with that client which constitutes the set of known owners of that type, for the given client.
どちらの種類の所有者も、clientid4と不透明な所有者文字列で構成されています。各クライアントには、特定のクライアントについて、そのタイプの既知の所有者のセットを構成する、そのクライアントで使用される別個の所有者値のセットがあります。
Each open is associated with a specific open-owner while each byte-range lock is associated with a lock-owner and an open-owner, the latter being the open-owner associated with the open file under which the LOCK operation was done.
各オープンは特定のオープンオーナーに関連付けられていますが、各バイト範囲ロックは、ロックオーナーとオープンオーナーに関連付けられています。後者は、LOCK操作が実行されたオープンファイルに関連付けられたオープンオーナーです。
When a clientid4 is presented to a server and that clientid4 is not valid, the server will reject the request with an error that depends on the reason for clientid4 invalidity. The error NFS4ERR_ADMIN_REVOKED is returned when the invalidation is the result of administrative action. When the clientid4 is unrecognizable, the error NFS4ERR_STALE_CLIENTID or NFS4ERR_EXPIRED may be returned. An unrecognizable clientid4 can occur for a number of reasons:
clientid4がサーバーに提示され、そのclientid4が有効でない場合、サーバーはclientid4が無効である理由に応じたエラーで要求を拒否します。無効化が管理アクションの結果である場合、エラーNFS4ERR_ADMIN_REVOKEDが返されます。 clientid4が認識できない場合、エラーNFS4ERR_STALE_CLIENTIDまたはNFS4ERR_EXPIREDが返されることがあります。認識できないclientid4は、いくつかの理由で発生する可能性があります。
o A server reboot causing loss of the server's knowledge of the client. (Always returns NFS4ERR_STALE_CLIENTID.)
o サーバーを再起動すると、サーバーがクライアントを認識できなくなります。 （常にNFS4ERR_STALE_CLIENTIDを返します。）
o Client error sending an incorrect clientid4 or a valid clientid4 to the wrong server. (May return either error.)
o 不適切なclientid4または有効なclientid4を間違ったサーバーに送信するクライアントエラー。 （どちらかのエラーを返す場合があります。）
o Loss of lease state due to lease expiration. (Always returns NFS4ERR_EXPIRED.)
o リース期限切れによるリース状態の喪失。 （常にNFS4ERR_EXPIREDを返します。）
o Client or server error causing the server to believe that the client has rebooted (i.e., receiving a SETCLIENTID with an nfs_client_id4 that has a matching id string and a non-matching boot instance id as the verifier). (May return either error.)
o クライアントが再起動したとサーバーに信じ込ませるクライアントまたはサーバーのエラー（つまり、一致するID文字列と一致しないブートインスタンスIDをベリファイアとして持つnfs_client_id4を含むSETCLIENTIDを受信）。 （どちらかのエラーを返す場合があります。）
o Migration of all state under the associated lease causes its non-existence to be recognized on the source server. (Always returns NFS4ERR_STALE_CLIENTID.)
o 関連するリースの下ですべての状態を移行すると、ソースサーバー上でその存在が認識されなくなります。 （常にNFS4ERR_STALE_CLIENTIDを返します。）
o Merger of state under the associated lease with another lease under a different client ID causes the clientid4 serving as the source of the merge to cease being recognized on its server. (Always returns NFS4ERR_STALE_CLIENTID.)
o 関連付けられたリース下の状態を別のクライアントIDの下の別のリースとマージすると、マージのソースとして機能するclientid4がサーバー上で認識されなくなります。 （常にNFS4ERR_STALE_CLIENTIDを返します。）
In the event of a server reboot, loss of lease state due to lease expiration, or administrative revocation of a clientid4, the client must obtain a new clientid4 by use of the SETCLIENTID operation and then proceed to any other necessary recovery for the server reboot case (see Section 9.6.2 in [RFC7530]). In cases of server or client error resulting in a clientid4 becoming unusable, use of SETCLIENTID to establish a new lease is desirable as well.
サーバーの再起動、リースの期限切れによるリース状態の損失、またはclientid4の管理上の取り消しが発生した場合、クライアントはSETCLIENTID操作を使用して新しいclientid4を取得し、サーバーの再起動の場合に必要なその他の回復に進む必要があります。 （[RFC7530]のセクション9.6.2を参照）。サーバーまたはクライアントのエラーが原因でclientid4が使用できなくなる場合は、SETCLIENTIDを使用して新しいリースを確立することも望ましいです。
In cases in which loss of server knowledge of a clientid4 is the result of migration, different recovery procedures are required. See Section 6.1.1 for details. Note that in cases in which there is any uncertainty about which sort of handling is applicable, the distinguishing characteristic is that in reboot-like cases, the clientid4 and all associated stateids cease to exist while in migration-related cases, the clientid4 ceases to exist while the stateids are still valid.
移行の結果としてclientid4のサーバー情報が失われた場合は、さまざまなリカバリ手順が必要です。詳細については、セクション6.1.1を参照してください。適用できる処理の種類について不確実性がある場合の際立った特徴は、再起動のような場合、clientid4と関連するすべてのstateidが存在しなくなり、移行関連の場合、clientid4が存在しなくなることです。状態IDはまだ有効です。
The client must also employ the SETCLIENTID operation when it receives an NFS4ERR_STALE_STATEID error using a stateid derived from its current clientid4, since this indicates a situation, such as a server reboot that has invalidated the existing clientid4 and associated stateids (see Section 9.1.5 in [RFC7530] for details).
また、クライアントは、現在のclientid4から派生したstateidを使用してNFS4ERR_STALE_STATEIDエラーを受信したときにSETCLIENTID操作を使用する必要があります。これは、既存のclientid4および関連するstateidを無効にしたサーバーの再起動などの状況を示すためです（セクション9.1.5を参照）。 [RFC7530]詳細については）。
See the detailed descriptions of SETCLIENTID (in Section 8.4) and SETCLIENTID_CONFIRM (in Section 16.34 of [RFC7530]) for a complete specification of these operations.
これらの操作の完全な仕様については、SETCLIENTID（8.4項）およびSETCLIENTID_CONFIRM（[RFC7530]の16.34項）の詳細な説明を参照してください。
If the server determines that the client holds no associated state for its clientid4, the server may choose to release that clientid4. 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 client ID 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 client ID unless there had been no activity from that client for many minutes.
クライアントがそのclientid4に関連付けられた状態を保持していないとサーバーが判断した場合、サーバーはそのclientid4を解放することを選択できます。サーバーは、非アクティブなクライアントに対してこの選択を行って、断続的にアクティブなクライアントによってリソースが消費されないようにすることができます。このリリース後にクライアントがサーバーに接続する場合、サーバーはクライアントが適切なエラーを受信することを確認して、SETCLIENTID / SETCLIENTID_CONFIRMシーケンスを使用して新しいIDを確立するようにする必要があります。サーバーがクライアントIDを解放することをためらう必要があることは明らかです。このようなイベントから回復するためのクライアントでの作業は、サーバーに障害が発生して再起動した場合と同じ負担になるためです。通常、サーバーは、そのクライアントから何分間もアクティビティがない場合を除いて、クライアントIDを解放しません。
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リクエストのid文字列が適切に構成されていて、クライアントがSETCLIENTIDを連続して使用するたびに同じプリンシパルを使用する場合、アクティブなサービス拒否攻撃を禁止すると、NFS4ERR_CLID_INUSEが返されないことに注意してください。
However, client bugs, server bugs, or perhaps a deliberate change of the principal owner of the id string (such as may occur in the case in which a client 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.
ただし、クライアントのバグ、サーバーのバグ、またはおそらくID文字列のプリンシパル所有者の意図的な変更（クライアントがセキュリティフレーバーを変更した場合に発生する可能性があり、新しいフレーバーでは、前のバージョンへのマッピングがありません）所有者）まれに、NFS4ERR_CLID_INUSEが発生します。
In situations in which there is an apparent change of principal, when the server gets a SETCLIENTID specifying a client ID string for which the server has a clientid4 that currently has no state, or for which it has state, but where the lease has expired, the server MUST allow the SETCLIENTID rather than returning NFS4ERR_CLID_INUSE. The server MUST then confirm the new client ID if followed by the appropriate SETCLIENTID_CONFIRM.
プリンシパルの明らかな変更がある状況で、サーバーが、現在状態がないか、状態はあるがリースが期限切れであるclientid4を持つサーバーのクライアントID文字列を指定するSETCLIENTIDを取得すると、サーバーは、NFS4ERR_CLID_INUSEを返すのではなく、SETCLIENTIDを許可する必要があります。適切なSETCLIENTID_CONFIRMが後に続く場合、サーバーは新しいクライアントIDを確認する必要があります。
One particular aspect of the construction of the nfs_client_id4 string has proved recurrently troublesome. The client has a choice of:
nfs_client_id4文字列の構成の1つの特定の側面は、繰り返し厄介であることが判明しています。クライアントには次の選択肢があります。
o Presenting the same id string to multiple server addresses. This is referred to as the "uniform client ID string approach" and is discussed in Section 5.6.
o 同じID文字列を複数のサーバーアドレスに提示する。これは「統一クライアントID文字列アプローチ」と呼ばれ、セクション5.6で説明します。
o Presenting different id strings to multiple server addresses. This is referred to as the "non-uniform client ID string approach" and is discussed in Section 5.5.
o 複数のサーバーアドレスに異なるID文字列を提示する。これは「非均一クライアントID文字列アプローチ」と呼ばれ、セクション5.5で説明されています。
Note that implementation considerations, including compatibility with existing servers, may make it desirable for a client to use both approaches, based on configuration information, such as mount options. This issue will be discussed in Section 5.7.
既存のサーバーとの互換性を含む実装上の考慮事項により、マウントオプションなどの構成情報に基づいて、クライアントが両方のアプローチを使用することが望ましい場合があることに注意してください。この問題については、セクション5.7で説明します。
Construction of the client ID string has arisen as a difficult issue because of the way in which the NFS protocols have evolved. It is useful to consider two points in that evolution.
クライアントID文字列の構築は、NFSプロトコルが進化した方法のために困難な問題として発生しました。その進化の2つのポイントを考慮することは有用です。
o NFSv3 as a stateless protocol had no need to identify the state shared by a particular client-server pair (see [RFC1813]). Thus, there was no need to consider the question of whether a set of requests come from the same client or whether two server IP addresses are connected to the same server. As the environment was one in which the user supplied the target server IP address as part of incorporating the remote file system in the client's file namespace, there was no occasion to take note of server trunking. Within a stateless protocol, the situation was symmetrical. The client has no server identity information, and the server has no client identity information.
o ステートレスプロトコルとしてのNFSv3は、特定のクライアント/サーバーペアが共有する状態を識別する必要がありませんでした（[RFC1813]を参照）。したがって、要求のセットが同じクライアントからのものか、2つのサーバーのIPアドレスが同じサーバーに接続されているかという問題を考慮する必要はありませんでした。クライアントのファイル名前空間にリモートファイルシステムを組み込む一環としてユーザーがターゲットサーバーのIPアドレスを指定した環境であったため、サーバーのトランキングに注意する機会がありませんでした。ステートレスプロトコル内では、状況は対称的でした。クライアントにはサーバー識別情報がなく、サーバーにはクライアント識別情報がありません。
o NFSv4.1 is a stateful protocol with full support for client and server identity determination (see [RFC5661]). This enables the server to be aware when two requests come from the same client (they are on sessions sharing a clientid4) and the client to be aware when two server IP addresses are connected to the same server. Section 2.10.5.1 of [RFC5661] explains how the client is able to assure itself that the connections are to the same logical server.
o NFSv4.1は、クライアントとサーバーのID決定を完全にサポートするステートフルプロトコルです（[RFC5661]を参照）。これにより、2つの要求が同じクライアント（clientid4を共有するセッション上にある）から送信されたことをサーバーが認識し、2つのサーバーIPアドレスが同じサーバーに接続されていることをクライアントが認識できます。 [RFC5661]のセクション2.10.5.1は、クライアントが同じ論理サーバーへの接続であることをクライアントがどのように保証できるかを説明しています。
NFSv4.0 is unfortunately halfway between these two. It introduced new requirements such as the need to identify specific clients and client instances without addressing server identity issues. The two client ID string approaches have arisen in attempts to deal with the changing requirements of the protocol as implementation has proceeded, and features that were not very substantial in early implementations of NFSv4.0 became more substantial as implementation proceeded.
残念ながら、NFSv4.0はこれら2つの中間にあります。サーバーIDの問題に対処せずに特定のクライアントとクライアントインスタンスを識別する必要性など、新しい要件が導入されました。 2つのクライアントID文字列アプローチは、実装が進むにつれてプロトコルの変化する要件に対処する試みで発生し、NFSv4.0の初期の実装ではそれほど重要ではなかった機能は、実装が進むにつれてより重要になりました。
o In the absence of any implementation of features related to fs_locations (replication, referral, and migration), the situation is very similar to that of NFSv3 (see Section 8.1 and the subsections within Section 8.4 of [RFC7530] for discussion of these features). In this case, locking state has been added, but there is no need for concern about the provision of accurate client and server identity determination. This is the situation that gave rise to the non-uniform client ID string approach.
o fs_locations（レプリケーション、参照、移行）に関連する機能の実装がない場合、状況はNFSv3の状況と非常に似ています（これらの機能の説明については、セクション8.1および[RFC7530]のセクション8.4内のサブセクションを参照してください）。この場合、ロック状態が追加されていますが、正確なクライアントとサーバーのID決定の提供について心配する必要はありません。これが、不均一なクライアントID文字列アプローチを生じさせた状況です。
o In the presence of replication and referrals, the client may have occasion to take advantage of knowledge of server trunking information. Even more important, transparent state migration, by transferring state among servers, causes difficulties for the non-uniform client ID string approach, in that the two different client ID strings sent to different IP addresses may wind up being processed by the same logical server, adding confusion.
o 複製と参照が存在する場合、クライアントはサーバーのトランキング情報の知識を利用する機会があります。さらに重要なのは、サーバー間で状態を転送することによる透過的な状態移行により、異なるIPアドレスに送信された2つの異なるクライアントID文字列が同じ論理サーバーによって処理される可能性があるという点で、不均一なクライアントID文字列アプローチが困難になることです。混乱を追加します。
o A further consideration is that client implementations typically provide NFSv4.1 by augmenting their existing NFSv4.0 implementation, not by providing two separate implementations. Thus, the more NFSv4.0 and NFSv4.1 can work alike, the less complex the clients are. This is a key reason why those implementing NFSv4.0 clients might prefer using the uniform client string model, even if they have chosen not to provide fs_locations-related features in their NFSv4.0 client.
o さらに考慮すべきことは、クライアント実装は通常、2つの別個の実装を提供するのではなく、既存のNFSv4.0実装を拡張することによってNFSv4.1を提供することです。したがって、NFSv4.0とNFSv4.1が同じように機能できるほど、クライアントの複雑度は低くなります。これは、NFSv4.0クライアントでfs_locations関連の機能を提供しないことを選択した場合でも、NFSv4.0クライアントを実装するユーザーが統一クライアント文字列モデルの使用を好む主な理由です。
Both approaches have to deal with the asymmetry in client and server identity information between client and server. Each seeks to make the client's and the server's views match. In the process, each encounters some combination of inelegant protocol features and/or implementation difficulties. The choice of which to use is up to the client implementer, and the sections below try to give some useful guidance.
どちらのアプローチでも、クライアントとサーバー間のクライアントとサーバーのID情報の非対称性に対処する必要があります。それぞれがクライアントとサーバーのビューを一致させようとします。その過程で、それぞれが、洗練されていないプロトコル機能の組み合わせや実装の問題に直面します。どちらを使用するかの選択はクライアントの実装者次第であり、以下のセクションではいくつかの有用なガイダンスを提供することを試みます。
The non-uniform client ID string approach is an attempt to handle these matters in NFSv4.0 client implementations in as NFSv3-like a way as possible.
不均一なクライアントID文字列アプローチは、NFSv4.0クライアント実装でこれらの問題をできるだけNFSv3のような方法で処理しようとする試みです。
For a client using the non-uniform approach, all internal recording of clientid4 values is to include, whether explicitly or implicitly, the server IP address so that one always has an <IP-address, clientid4> pair. Two such pairs from different servers are always distinct even when the clientid4 values are the same, as they may occasionally be. In this approach, such equality is always treated as simple happenstance.
不均一なアプローチを使用するクライアントの場合、clientid4値のすべての内部記録には、明示的または暗黙的にサーバーIPアドレスが含まれるため、常に<IP-address、clientid4>ペアが存在します。異なるサーバーからのこのような2つのペアは、clientid4の値が同じであっても常に異なる場合があります。このアプローチでは、そのような平等は常に単純な偶然として扱われます。
Making the client ID string different on different server IP addresses results in a situation in which a server has no way of tying together information from the same client, when the client accesses multiple server IP addresses. As a result, it will treat a single client as multiple clients with separate leases for each server network address. Since there is no way in the protocol for the client to determine if two network addresses are connected to the same server, the resulting lack of knowledge is symmetrical and can result in simpler client implementations in which there is a single clientid4/lease per server network address.
異なるサーバーIPアドレスでクライアントID文字列を異ならせると、クライアントが複数のサーバーIPアドレスにアクセスするときに、サーバーが同じクライアントからの情報を結び付ける方法がなくなります。その結果、1つのクライアントを、サーバーのネットワークアドレスごとに個別のリースを持つ複数のクライアントとして扱います。 2つのネットワークアドレスが同じサーバーに接続されているかどうかをクライアントが判別するプロトコルがないため、結果として生じる知識の欠如は対称的であり、サーバーネットワークごとに1つのclientid4 / leaseがあるより単純なクライアント実装をもたらす可能性があります。住所。
Support for migration, particularly with transparent state migration, is more complex in the case of non-uniform client ID strings. For example, migration of a lease can result in multiple leases for the same client accessing the same server addresses, vitiating many of the advantages of this approach. Therefore, client implementations that support migration with transparent state migration are likely to experience difficulties using the non-uniform client ID string approach and should not do so, except where it is necessary for compatibility with existing server implementations (for details of arranging use of multiple client ID string approaches, see Section 5.7).
特に透過的な状態移行での移行のサポートは、非均一なクライアントID文字列の場合はより複雑になります。たとえば、リースを移行すると、同じクライアントが同じサーバーアドレスにアクセスする複数のリースが発生する可能性があり、このアプローチの多くの利点が損なわれます。したがって、透過的な状態移行による移行をサポートするクライアント実装は、既存のサーバー実装との互換性のために必要な場合を除いて、不均一なクライアントID文字列アプローチを使用して問題が発生する可能性があり、そうするべきではありません（複数の使用の配置の詳細について）クライアントID文字列が近づきます。セクション5.7を参照してください。
When the client ID string is kept uniform, the server has the basis to have a single clientid4/lease for each distinct client. The problem that has to be addressed is the lack of explicit server identity information, which was made available in NFSv4.1.
クライアントID文字列が一定に保たれている場合、サーバーは、クライアントごとに1つのclientid4 / leaseを持つことを基盤とします。対処しなければならない問題は、NFSv4.1で利用可能になった明示的なサーバー識別情報の欠如です。
When the same client ID string is given to multiple IP addresses, the client can determine whether two IP addresses correspond to a single server, based on the server's behavior. This is the inverse of the strategy adopted for the non-uniform approach in which different server IP addresses are told about different clients, simply to prevent a server from manifesting behavior that is inconsistent with there being a single server for each IP address, in line with the traditions of NFS. So, to compare:
同じクライアントID文字列が複数のIPアドレスに与えられると、クライアントは、サーバーの動作に基づいて、2つのIPアドレスが単一のサーバーに対応するかどうかを判断できます。これは、異なるサーバーIPアドレスが異なるクライアントについて通知される非均一アプローチに採用された戦略の逆であり、サーバーが各IPアドレスに対して単一のサーバーが存在することと矛盾する動作をインラインで発生させないようにするためです。 NFSの伝統と。だから、比較するには：
o In the non-uniform approach, servers are told about different clients because, if the server were to use accurate client identity information, two IP addresses on the same server would behave as if they were talking to the same client, which might prove disconcerting to a client not expecting such behavior.
o 不均一なアプローチでは、サーバーは異なるクライアントについて通知されます。これは、サーバーが正確なクライアントID情報を使用すると、同じサーバー上の2つのIPアドレスが同じクライアントと通信しているように動作し、これにより、そのような動作を期待していないクライアント。
o In the uniform approach, the servers are told about there being a single client, which is, after all, the truth. Then, when the server uses this information, two IP addresses on the same server will behave as if they are talking to the same client, and this difference in behavior allows the client to infer the server IP address trunking configuration, even though NFSv4.0 does not explicitly provide this information.
o 統一されたアプローチでは、サーバーは単一のクライアントが存在することを通知されますが、これは結局のところ真実です。次に、サーバーがこの情報を使用すると、同じサーバー上の2つのIPアドレスは同じクライアントと通信しているように動作し、この動作の違いにより、NFSv4.0であってもクライアントはサーバーのIPアドレストランキング構成を推測できます。この情報は明示的に提供されません。
The approach given in the section below shows one example of how this might be done.
以下のセクションで示すアプローチは、これを行う方法の一例を示しています。
The uniform client ID string approach makes it necessary to exercise more care in the definition of the boot instance id sent as the verifier field in an nfs_client_id4:
統一されたクライアントID文字列アプローチでは、nfs_client_id4のベリファイアフィールドとして送信されるブートインスタンスIDの定義にさらに注意を払う必要があります。
o In [RFC7530], the client is told to change the verifier field value when reboot occurs, but there is no explicit statement as to the converse, so that any requirement to keep the verifier field constant unless rebooting is only present by implication.
o [RFC7530]では、クライアントは再起動が発生したときに検証フィールドの値を変更するように指示されますが、逆に関して明示的なステートメントはないため、再起動しない限り検証フィールドを一定に保つ必要があるということは、暗黙的に存在するだけです。
o Many existing clients change the boot instance id every time they destroy and recreate the data structure that tracks an <IP-address, clientid4> pair. This might happen if the last mount of a particular server is removed, and then a fresh mount is created. Also, note that this might result in each <IP-address, clientid4> pair having its own boot instance id that is independent of the others.
o 多くの既存のクライアントは、<IP-address、clientid4>ペアを追跡するデータ構造を破棄および再作成するたびに、ブートインスタンスIDを変更します。これは、特定のサーバーの最後のマウントが削除され、新しいマウントが作成された場合に発生する可能性があります。また、これにより、各<IP-address、clientid4>ペアが、他の独立した独自のブートインスタンスIDを持つことになる場合があることに注意してください。
o Within the uniform client ID string approach, an nfs_client_id4 designates a globally known client instance, so that the verifier field should change if and only if a new client instance is created, typically as a result of a reboot.
o 統一されたクライアントID文字列アプローチでは、nfs_client_id4はグローバルに既知のクライアントインスタンスを指定するため、新しいクライアントインスタンスが作成された場合にのみ、通常は再起動の結果として検証フィールドが変更されます。
Clients using the uniform client ID string approach are therefore well advised to use a verifier established only once for each reboot, typically at reboot time.
したがって、統一されたクライアントID文字列アプローチを使用するクライアントは、通常は再起動時に、再起動ごとに1回だけ確立された検証を使用することをお勧めします。
The following are advantages for the implementation of using the uniform client ID string approach:
統一されたクライアントID文字列アプローチを使用する実装の利点は次のとおりです。
o Clients can take advantage of server trunking (and clustering with single-server-equivalent semantics) to increase bandwidth or reliability.
o クライアントは、サーバーのトランキング（および単一サーバーと同等のセマンティクスによるクラスタリング）を利用して、帯域幅または信頼性を向上させることができます。
o There are advantages in state management so that, for example, one never has a delegation under one clientid4 revoked because of a reference to the same file from the same client under a different clientid4.
o 状態管理には利点があります。たとえば、異なるclientid4の同じクライアントから同じファイルへの参照が原因で、1つのclientid4の委任が取り消されることはありません。
o The uniform client ID string approach allows the server to do any necessary automatic lease merger in connection with transparent state migration, without requiring any client involvement. This consideration is of sufficient weight to cause us to recommend use of the uniform client ID string approach for clients supporting transparent state migration.
o 統一されたクライアントID文字列アプローチにより、サーバーは、クライアントの関与を必要とせずに、透過的な状態移行に関連して必要な自動リースマージを実行できます。この考慮事項は、透過的な状態移行をサポートするクライアントに統一クライアントID文字列アプローチの使用を推奨するのに十分な重みです。
The following implementation considerations might cause issues for client implementations.
次の実装に関する考慮事項は、クライアントの実装で問題を引き起こす可能性があります。
o This approach is considerably different from the non-uniform approach, which most client implementations have been following. Until substantial implementation experience is obtained with this approach, reluctance to embrace something so new is to be expected.
o このアプローチは、ほとんどのクライアント実装が従っている非均一アプローチとはかなり異なります。このアプローチで実質的な実装の経験が得られるまで、何か新しいものを採用することには消極的です。
o Mapping between server network addresses and leases is more complicated in that it is no longer a one-to-one mapping.
o サーバーネットワークアドレスとリース間のマッピングは、1対1のマッピングではなくなったため、より複雑です。
Another set of relevant considerations relate to privacy concerns, which users of the client might have in that use of the uniform client ID string approach would enable multiple servers acting in concert to determine when multiple requests received at different times derive from the same NFSv4.0 client. For example, this might enable determination that multiple distinct user identities in fact are likely to correspond to requests made by the same person, even when those requests are directed to different servers.
関連する考慮事項の別のセットはプライバシーの懸念に関連します。統一されたクライアントID文字列アプローチを使用すると、複数のサーバーが協調して動作し、異なる時間に受信された複数の要求が同じNFSv4.0から派生するタイミングを判断できるようになります。クライアント。たとえば、これにより、実際には複数の異なるユーザーIDが、同じサーバーからの要求である場合でも、同じ人が行った要求に対応する可能性が高いと判断できます。
How to balance these considerations depends on implementation goals.
これらの考慮事項のバランスを取る方法は、実装目標によって異なります。
As noted above, a client that needs to use the uniform client ID string approach (e.g., to support migration) may also need to support existing servers with implementations that do not work properly in this case.
上記のように、統一されたクライアントID文字列アプローチを使用する必要があるクライアント（たとえば、移行をサポートするため）は、この場合、適切に機能しない実装で既存のサーバーをサポートする必要がある場合もあります。
Some examples of such server issues include:
このようなサーバーの問題のいくつかの例は次のとおりです。
o Some existing NFSv4.0 server implementations of IP address failover depend on clients' use of a non-uniform client ID string approach. In particular, when a server supports both its own IP address and one failed over from a partner server, it may have separate sets of state applicable to the two IP addresses, owned by different servers but residing on a single one.
o IPアドレスフェイルオーバーの既存のNFSv4.0サーバー実装の一部は、クライアントによる不均一なクライアントID文字列アプローチの使用に依存しています。特に、サーバーが独自のIPアドレスとパートナーサーバーからのフェイルオーバーの両方をサポートしている場合、2つのIPアドレスに適用可能な別々の状態セットがあり、異なるサーバーによって所有されているが、単一のIPアドレスに存在する場合があります。
In this situation, some servers have relied on clients' use of the non-uniform client ID string approach, as suggested but not mandated by [RFC7530], to keep these sets of state separate, and they will have problems handling clients using the uniform client ID string approach, in that such clients will see changes in trunking relationships whenever server failover and giveback occur.
この状況では、一部のサーバーは、[RFC7530]によって提案されているが義務付けられていない、非均一クライアントID文字列アプローチのクライアントの使用に依存して、これらの状態のセットを個別に保ち、均一のクライアントを使用してクライアントを処理する際に問題が発生します。クライアントID文字列アプローチ。このようなクライアントは、サーバーのフェイルオーバーとギブバックが発生するたびにトランキング関係の変化を認識します。
o Some existing servers incorrectly return NFS4ERR_CLID_INUSE simply because there already exists a clientid4 for the same client, established using a different IP address. This causes difficulty for a multihomed client using the uniform client ID string approach.
o 既存のサーバーの中には、同じクライアントのclientid4が既に存在し、別のIPアドレスを使用して確立されているという理由だけで、誤ってNFS4ERR_CLID_INUSEを返すものがあります。これにより、統一されたクライアントID文字列アプローチを使用するマルチホームクライアントに問題が発生します。
Although this behavior is not correct, such servers still exist, and this specification should give clients guidance about dealing with the situation, as well as making the correct behavior clear.
この動作は正しくありませんが、そのようなサーバーはまだ存在しており、この仕様はクライアントに状況への対処と正しい動作を明らかにするためのガイダンスを提供する必要があります。
In order to support use of these sorts of servers, the client can use different client ID string approaches for different mounts, in order to assure that:
これらの種類のサーバーの使用をサポートするために、クライアントは、次のことを保証するために、マウントごとに異なるクライアントID文字列アプローチを使用できます。
o The uniform client ID string approach is used when accessing servers that may return NFS4ERR_MOVED and when the client wishes to enable transparent state migration.
o 統一されたクライアントID文字列アプローチは、NFS4ERR_MOVEDを返す可能性のあるサーバーにアクセスするとき、およびクライアントが透過的な状態移行を有効にしたいときに使用されます。
o The non-uniform client ID string approach is used when accessing servers whose implementations make them incompatible with the uniform client ID string approach.
o 非均一クライアントID文字列アプローチは、その実装によってサーバーが均一クライアントID文字列アプローチと互換性がないサーバーにアクセスするときに使用されます。
Since the client cannot easily determine which of the above are true, implementations are likely to rely on user-specified mount options to select the appropriate approach to use, in cases in which a client supports simultaneous use of multiple approaches. Choice of a default to use in such cases is up to the client implementation.
クライアントが上記のどれに当てはまるかを簡単に判断できないため、クライアントが複数のアプローチの同時使用をサポートしている場合、実装はユーザー指定のマウントオプションに依存して、適切なアプローチを選択する可能性があります。このような場合に使用するデフォルトの選択は、クライアントの実装次第です。
In the case in which the same server has multiple mounts, and both approaches are specified for the same server, the client could have multiple clientid4s corresponding to the same server, one for each approach, and would then have to keep these separate.
同じサーバーに複数のマウントがあり、両方のアプローチが同じサーバーに指定されている場合、クライアントは、同じサーバーに対応する複数のclientid4を各アプローチに1つずつ持つことができ、これらを別々に保つ必要があります。
This section provides an example of how trunking determination could be done by a client following the uniform client ID string approach (whether this is used for all mounts or not). Clients need not follow this procedure, but implementers should make sure that the issues dealt with by this procedure are all properly addressed.
このセクションでは、統一されたクライアントID文字列アプローチに従ってクライアントがトランキングを決定する方法の例を示します（これがすべてのマウントに使用されるかどうかに関係なく）。クライアントはこの手順に従う必要はありませんが、実装者はこの手順で処理される問題がすべて適切に対処されていることを確認する必要があります。
It is best to clarify here the various possible purposes of trunking determination and the corresponding requirements as to server behavior. The following points should be noted:
ここでは、トランキング決定のさまざまな考えられる目的と、サーバーの動作に関する対応する要件を明確にすることをお勧めします。次の点に注意してください。
o The primary purpose of the trunking determination algorithm is to make sure that, if the server treats client requests on two IP addresses as part of the same client, the client will not be surprised and encounter disconcerting server behavior, as mentioned in Section 5.6. Such behavior could occur if the client were unaware that all of its client requests for the two IP addresses were being handled as part of a single client talking to a single server.
o トランキング決定アルゴリズムの主な目的は、サーバーが2つのIPアドレスのクライアント要求を同じクライアントの一部として処理する場合に、クライアントが驚くことなく、セクション5.6で説明されているようにサーバーの動作を混乱させないことを確認することです。このような動作は、2つのIPアドレスに対するクライアント要求がすべて、単一のサーバーと通信する単一のクライアントの一部として処理されていることをクライアントが認識していない場合に発生する可能性があります。
o A second purpose is to be able to use knowledge of trunking relationships for better performance, etc.
o 2番目の目的は、パフォーマンスの向上などのためにトランキング関係の知識を使用できるようにすることです。
o If a server were to give out distinct clientid4s in response to receiving the same nfs_client_id4 on different network addresses, and acted as if these were separate clients, the primary purpose of trunking determination would be met, as long as the server did not treat them as part of the same client. In this case, the server would be acting, with regard to that client, as if it were two distinct servers. This would interfere with the secondary purpose of trunking determination, but there is nothing the client can do about that.
o 異なるネットワークアドレスで同じnfs_client_id4を受信したことに応答してサーバーが別個のclientid4を配布し、これらが別個のクライアントであるかのように振る舞う場合、サーバーがそれらを次のように処理しない限り、トランキングの決定の主な目的は満たされます。同じクライアントの一部。この場合、サーバーはそのクライアントに関して、まるで2つの別個のサーバーであるかのように動作します。これは、トランキングの決定という2番目の目的を妨害しますが、クライアントがそれについてできることは何もありません。
o Suppose a server were to give such a client two different clientid4s but act as if they were one. That is the only way that the server could behave in a way that would defeat the primary purpose of the trunking determination algorithm.
o サーバーがそのようなクライアントに2つの異なるclientid4を与えるが、それらが1つであるかのように動作するとします。これが、トランキング決定アルゴリズムの主な目的を損なうような方法でサーバーが動作できる唯一の方法です。
Servers MUST NOT behave that way.
サーバーはそのように動作してはいけません。
For a client using the uniform approach, clientid4 values are treated as important information in determining server trunking patterns.
統一されたアプローチを使用するクライアントの場合、clientid4値は、サーバーのトランキングパターンを決定する上で重要な情報として扱われます。
For two different IP addresses to return the same clientid4 value is a necessary, though not a sufficient condition for them to be considered as connected to the same server. As a result, when two different IP addresses return the same clientid4, the client needs to determine, using the procedure given below or otherwise, whether the IP addresses are connected to the same server. For such clients, all internal recording of clientid4 values needs to include, whether explicitly or implicitly, identification of the server from which the clientid4 was received so that one always has a (server, clientid4) pair. Two such pairs from different servers are always considered distinct even when the clientid4 values are the same, as they may occasionally be.
2つの異なるIPアドレスが同じclientid4値を返すには、それらが同じサーバーに接続されていると見なされるための十分な条件ではありませんが必要です。その結果、2つの異なるIPアドレスが同じclientid4を返す場合、クライアントは、以下に示す手順などを使用して、IPアドレスが同じサーバーに接続されているかどうかを判断する必要があります。そのようなクライアントの場合、clientid4値のすべての内部記録には、明示的であれ暗黙的であれ、clientid4の受信元サーバーのIDを含める必要があるため、常に（server、clientid4）ペアを持っています。異なるサーバーからのこのような2つのペアは、clientid4値が同じであっても、たまに異なる場合があるため、常に異なると見なされます。
In order to make this approach work, the client must have certain information accessible for each nfs_client_id4 used by the uniform approach (only one in general). The client needs to maintain a list of all server IP addresses, together with the associated clientid4 values, SETCLIENTID principals, and authentication flavors. As a part of the associated data structures, there should be the ability to mark a server IP structure as having the same server as another and to mark an IP address as currently unresolved. One way to do this is to allow each such entry to point to another with the pointer value being one of:
このアプローチを機能させるには、クライアントは、統一されたアプローチで使用される各nfs_client_id4に対してアクセス可能な特定の情報を持っている必要があります（一般に1つのみ）。クライアントは、関連するclientid4値、SETCLIENTIDプリンシパル、および認証フレーバーとともに、すべてのサーバーIPアドレスのリストを維持する必要があります。関連するデータ構造の一部として、サーバーのIP構造を別のサーバーと同じものとしてマークし、IPアドレスを現在未解決としてマークする機能が必要です。これを行う1つの方法は、そのような各エントリが、ポインタ値が次のいずれかである別のエントリをポイントできるようにすることです。
o A pointer to another entry for an IP address associated with the same server, where that IP address is the first one referenced to access that server.
o 同じサーバーに関連付けられたIPアドレスの別のエントリへのポインター。このIPアドレスは、そのサーバーにアクセスするために参照される最初のアドレスです。
o A pointer to the current entry if there is no earlier IP address associated with the same server, i.e., where the current IP address is the first one referenced to access that server. The text below refers to such an IP address as the lead IP address for a given server.
o 同じサーバーに関連付けられている以前のIPアドレスがない場合、つまり現在のIPアドレスがそのサーバーにアクセスするために参照される最初のIPアドレスである場合の、現在のエントリへのポインター。以下のテキストは、そのようなIPアドレスを特定のサーバーのリードIPアドレスと呼びます。
o The value NULL if the address's server identity is currently unresolved.
o アドレスのサーバーIDが現在解決されていない場合は、値NULL。
In order to keep the above information current, in the interests of the most effective trunking determination, RENEWs should be periodically done on each server. However, even if this is not done, the primary purpose of the trunking determination algorithm, to prevent confusion due to trunking hidden from the client, will be achieved.
上記の情報を最新に保つために、最も効果的なトランキングの決定のために、各サーバーで定期的にRENEWを実行する必要があります。ただし、これを行わなくても、トランキング決定アルゴリズムの主な目的は、クライアントから隠されたトランキングによる混乱を防ぐことです。
Given this apparatus, when a SETCLIENTID is done and a clientid4 returned, the data structure can be searched for a matching clientid4 and if such is found, further processing can be done to determine whether the clientid4 match is accidental, or the result of trunking.
この装置の場合、SETCLIENTIDが実行されてclientid4が返されると、一致するclientid4があるかデータ構造を検索できます。それが見つかった場合は、さらに処理を行って、clientid4の一致が偶発的かどうか、またはトランキングの結果を判別できます。
In this algorithm, when SETCLIENTID is done initially, it will use the common nfs_client_id4 and specify the current target IP address as callback.cb_location within the callback parameters. We call the clientid4 and SETCLIENTID verifier returned by this operation XC and XV, respectively.
このアルゴリズムでは、SETCLIENTIDが最初に実行されるときに、共通のnfs_client_id4を使用して、現在のターゲットIPアドレスをコールバックパラメータ内のcallback.cb_locationとして指定します。この操作で返されるclientid4およびSETCLIENTIDベリファイアをそれぞれXCおよびXVと呼びます。
This choice of callback parameters is provisional and reflects the client's preferences in the event that the IP address is not trunked with other IP addresses. The algorithm is constructed so that only the appropriate callback parameters, reflecting observed trunking patterns, are actually confirmed.
このコールバックパラメータの選択は暫定的なものであり、IPアドレスが他のIPアドレスでトランクされない場合のクライアントの設定を反映します。アルゴリズムは、観察されたトランキングパターンを反映する適切なコールバックパラメータのみが実際に確認されるように構築されています。
Note that when the client has done previous SETCLIENTIDs to any IP addresses, with more than one principal or authentication flavor, one has the possibility of receiving NFS4ERR_CLID_INUSE, since it is not yet known which of the connections with existing IP addresses might be trunked with the current one. In the event that the SETCLIENTID fails with NFS4ERR_CLID_INUSE, one must try all other combinations of principals and authentication flavors currently in use, and eventually one will be correct and not return NFS4ERR_CLID_INUSE.
クライアントが任意のIPアドレスに対して以前のSETCLIENTIDを実行し、プリンシパルまたは認証フレーバーが複数ある場合は、NFS4ERR_CLID_INUSEを受信する可能性があることに注意してください。既存のIPアドレスとの接続のどれが現在のもの。 SETCLIENTIDがNFS4ERR_CLID_INUSEで失敗した場合、現在使用中のプリンシパルと認証フレーバーの他のすべての組み合わせを試す必要があり、最終的には1つが正しいため、NFS4ERR_CLID_INUSEは返されません。
Note that at this point, no SETCLIENTID_CONFIRM has yet been done. This is because the SETCLIENTID just done has either established a new clientid4 on a previously unknown server or changed the callback parameters on a clientid4 associated with some already known server. Given it is undesirable to confirm something that should not happen, what is to be done next depends on information about existing clientid4s.
この時点では、SETCLIENTID_CONFIRMはまだ行われていないことに注意してください。これは、実行されたばかりのSETCLIENTIDが、以前は不明だったサーバーに新しいclientid4を確立したか、既知のサーバーに関連付けられたclientid4のコールバックパラメータを変更したためです。発生してはならないことを確認することは望ましくないため、次に行うことは、既存のclientid4に関する情報によって異なります。
o If no matching clientid4 is found, the IP address X and clientid4 XC are added to the list and considered as having no existing known IP addresses trunked with it. The IP address is marked as a lead IP address for a new server. A SETCLIENTID_CONFIRM is done using XC and XV.
o 一致するclientid4が見つからない場合、IPアドレスXとclientid4 XCがリストに追加され、既存の既知のIPアドレスがトランクされていないものと見なされます。 IPアドレスは、新しいサーバーのリードIPアドレスとしてマークされます。 SETCLIENTID_CONFIRMは、XCおよびXVを使用して実行されます。
o If a matching clientid4 is found that is marked unresolved, processing on the new IP address is suspended. In order to simplify processing, there can only be one unresolved IP address for any given clientid4.
o 未解決とマークされている一致するclientid4が見つかった場合、新しいIPアドレスでの処理は中断されます。処理を簡略化するために、特定のclientid4には未解決のIPアドレスを1つだけ含めることができます。
o If one or more matching clientid4s are found, none of which are marked unresolved, the new IP address X is entered and marked unresolved. A SETCLIENTID_CONFIRM is done to X using XC and XV.
o 1つ以上の一致するclientid4が見つかり、どれも未解決としてマークされていない場合、新しいIPアドレスXが入力され、未解決としてマークされます。 XCおよびXVを使用して、SETCLIENTID_CONFIRMがXに対して実行されます。
When, as a result of encountering the last of the three cases shown above, an unresolved IP address exists, further processing is required. After applying the steps below to each of the lead IP addresses with a matching clientid4, the address will have been resolved: It may have been determined to be part of an already known server as a new IP address to be added to an existing set of IP addresses for that server. Otherwise, it will be recognized as a new server. At the point at which this determination is made, the unresolved indication is cleared and any suspended SETCLIENTID processing is restarted.
上記の3つのケースのうち最後のケースに遭遇した結果、未解決のIPアドレスが存在する場合は、さらに処理が必要です。一致するclientid4を持つリードIPアドレスのそれぞれに以下の手順を適用した後、アドレスは解決されます：既存のセットに追加される新しいIPアドレスとして、既知のサーバーの一部であると判断された可能性がありますそのサーバーのIPアドレス。それ以外の場合は、新しいサーバーとして認識されます。この決定が行われた時点で、未解決の指示がクリアされ、中断されていたSETCLIENTID処理が再開されます。
For each lead IP address IPn with a clientid4 matching XC, the following steps are done. Because the Remote Procedure Call (RPC) to do a SETCLIENTID could take considerable time, it is desirable for the client to perform these operations in parallel. Note that because the clientid4 is a 64-bit value, the number of such IP addresses that would need to be tested is expected to be quite small, even when the client is interacting with many NFSv4.0 servers. Thus, while parallel processing is desirable, it is not necessary.
XCに一致するclientid4を持つリードIPアドレスIPnごとに、次の手順が実行されます。 SETCLIENTIDを実行するリモートプロシージャコール（RPC）にはかなりの時間がかかる可能性があるため、クライアントがこれらの操作を並行して実行することが望ましいです。 clientid4は64ビット値であるため、クライアントが多くのNFSv4.0サーバーと対話している場合でも、テストが必要なIPアドレスの数は非常に少ないと予想されます。従って、並列処理が望ましいが、それは必要ではない。
o If the principal for IPn does not match that for X, the IP address is skipped, since it is impossible for IPn and X to be trunked in these circumstances. If the principal does match but the authentication flavor does not, the authentication flavor already used should be used for address X as well. This will avoid any possibility that NFS4ERR_CLID_INUSE will be returned for the SETCLIENTID and SETCLIENTID_CONFIRM to be done below, as long as the server(s) at IP addresses IPn and X is correctly implemented.
o IPnのプリンシパルがXのプリンシパルと一致しない場合、これらの状況ではIPnとXをトランキングできないため、IPアドレスはスキップされます。プリンシパルは一致するが認証フレーバーが一致しない場合、すでに使用されている認証フレーバーをアドレスXにも使用する必要があります。これにより、IPアドレスIPnおよびXのサーバーが正しく実装されている限り、以下のSETCLIENTIDおよびSETCLIENTID_CONFIRMに対してNFS4ERR_CLID_INUSEが返される可能性が回避されます。
o A SETCLIENTID is done to update the callback parameters to reflect the possibility that X will be marked as associated with the server whose lead IP address is IPn. The specific callback parameters chosen, in terms of cb_client4 and callback_ident, are up to the client and should reflect its preferences as to callback handling for the common clientid4, in the event that X and IPn are trunked together. When a SETCLIENTID is done on IP address IPn, a setclientid_confirm value (in the form of a verifier4) is returned, which will be referred to as SCn.
o SETCLIENTIDは、コールバックパラメーターを更新して、XがリードIPアドレスがIPnであるサーバーに関連付けられているとマークされる可能性を反映するために実行されます。 cb_client4とcallback_identに関して選択された特定のコールバックパラメーターはクライアント次第であり、XとIPnが一緒にトランキングされる場合、共通のclientid4のコールバック処理に関するその設定を反映する必要があります。 IPアドレスIPnでSETCLIENTIDが実行されると、setclientid_confirm値（verifier4の形式）が返されます。これはSCnと呼ばれます。
Note that the NFSv4.0 specification requires the server to make sure that such verifiers are very unlikely to be regenerated. Given that it is already highly unlikely that the clientid4 XC is duplicated by distinct servers, the probability that SCn is duplicated as well has to be considered vanishingly small. Note also that the callback update procedure can be repeated multiple times to reduce the probability of further spurious matches.
NFSv4.0仕様では、サーバーがそのようなベリファイアが再生成される可能性が非常に低いことを確認する必要があることに注意してください。 clientid4 XCが別個のサーバーによって複製される可能性はすでに非常に低いため、SCnも複製される可能性は非常に小さいと見なす必要があります。また、コールバック更新手順を複数回繰り返して、さらに偽の一致が発生する可能性を減らすこともできます。
o The setclientid_confirm value SCn is saved for later use in confirming the SETCLIENTID done to IPn.
o setclientid_confirm値SCnは、IPnに対して行われたSETCLIENTIDを確認するために後で使用するために保存されます。
Once the SCn values are gathered up by the procedure above, they are each tested by being used as the verifier for a SETCLIENTID_CONFIRM operation directed to the original IP address X, whose trunking relationships are to be determined. These RPC operations may be done in parallel.
上記の手順でSCn値が収集されると、トランキング関係が決定される元のIPアドレスXへのSETCLIENTID_CONFIRM操作のベリファイアとして使用され、それぞれがテストされます。これらのRPC操作は並行して実行できます。
There are a number of things that should be noted at this point.
この時点で注意すべき点がいくつかあります。
o The SETCLIENTID operations done on the various IPn addresses in the procedure above will never be confirmed by SETCLIENTID_CONFIRM operations directed to the various IPn addresses. If these callback updates are to be confirmed, they will be confirmed by SETCLIENTID_CONFIRM operations directed at the original IP address X, which can only happen if SCn was generated by an IPn that was trunked with X, allowing the SETCLIENTID to be successfully confirmed and allowing us to infer the existence of that trunking relationship.
o 上記の手順でさまざまなIPnアドレスに対して行われたSETCLIENTID操作は、さまざまなIPnアドレスに対するSETCLIENTID_CONFIRM操作によって確認されることはありません。これらのコールバックの更新が確認される場合、元のIPアドレスXに向けられたSETCLIENTID_CONFIRM操作によって確認されます。これは、XでトランクされたIPnによってSCnが生成された場合にのみ発生し、SETCLIENTIDを正常に確認して許可しますそのトランキング関係の存在を推測します。
o The number of successful SETCLIENTID_CONFIRM operations done should never be more than one. If both SCn and SCm are accepted by X, then it indicates that both IPn and IPm are trunked with X, but that is only possible if IPn and IPm are trunked together. Since these two addresses were earlier recognized as not trunked together, this should be impossible, if the servers in question are implemented correctly.
o 実行された成功したSETCLIENTID_CONFIRM操作の数は、1を超えてはなりません。 SCnとSCmの両方がXによって受け入れられる場合、IPnとIPmの両方がXでトランクされることを示しますが、これはIPnとIPmが一緒にトランクされる場合にのみ可能です。これらの2つのアドレスは以前は一緒にトランキングされていないと認識されていたため、問題のサーバーが正しく実装されている場合、これは不可能です。
Further processing depends on the success or failure of the various SETCLIENTD_CONFIRM operations done in the step above.
以降の処理は、上記のステップで実行されたさまざまなSETCLIENTD_CONFIRM操作の成功または失敗によって異なります。
o If the setclientid_confirm value generated by a particular IPn is accepted on X, then X and IPn are recognized as connected to the same server, and the entry for X is marked as associated with IPn.
o 特定のIPnによって生成されたsetclientid_confirm値がXで受け入れられると、XとIPnは同じサーバーに接続されていると認識され、XのエントリはIPnに関連付けられているものとしてマークされます。
o If none of the confirm operations are accepted, then X is recognized as a distinct server. Its callback parameters will remain as the ones established by the original SETCLIENTID.
o どの確認操作も受け入れられない場合、Xは別個のサーバーとして認識されます。そのコールバックパラメータは、元のSETCLIENTIDによって確立されたもののままです。
In either of the cases, the entry is considered resolved and processing can be restarted for IP addresses whose clientid4 matched XC but whose resolution had been deferred.
どちらの場合も、エントリは解決されたと見なされ、clientid4がXCに一致したが解決が延期されたIPアドレスの処理を再開できます。
The procedure described above must be performed so as to exclude the possibility that multiple SETCLIENTIDs done to different server IP addresses and returning the same clientid4 might "race" in such a fashion that there is no explicit determination of whether they correspond to the same server. The following possibilities for serialization are all valid, and implementers may choose among them based on a tradeoff between performance and complexity. They are listed in order of increasing parallelism:
上記の手順は、異なるサーバーのIPアドレスに対して行われ、同じclientid4を返す複数のSETCLIENTIDが、同じサーバーに対応するかどうかを明示的に判断できない方法で「競合」する可能性を排除するために実行する必要があります。次のシリアル化の可能性はすべて有効であり、実装者はパフォーマンスと複雑さの間のトレードオフに基づいてそれらの中から選択できます。それらは、並列処理の増加順にリストされています。
o An NFSv4.0 client might serialize all instances of SETCLIENTID/ SETCLIENTID_CONFIRM processing, either directly or by serializing mount operations involving use of NFSv4.0. While doing so will prevent the races mentioned above, this degree of serialization can cause performance issues when there is a high volume of mount operations.
o NFSv4.0クライアントは、直接またはNFSv4.0の使用を含むマウント操作をシリアル化することにより、SETCLIENTID / SETCLIENTID_CONFIRM処理のすべてのインスタンスをシリアル化する場合があります。そうすることで上記の競合を防ぐことができますが、この程度のシリアライゼーションは、大量のマウント操作がある場合にパフォーマンスの問題を引き起こす可能性があります。
o One might instead serialize the period of processing that begins when the clientid4 received from the server is processed and ends when all trunking determination for that server is completed. This prevents the races mentioned above, without adding to delay except when trunking determination is common.
o 代わりに、サーバーから受信したclientid4が処理されたときに始まり、そのサーバーのすべてのトランキングの決定が完了したときに終了する処理の期間をシリアル化できます。これは、トランキングの決定が一般的である場合を除いて、遅延を追加することなく、上記の競合を防ぎます。
o One might avoid much of the serialization implied above, by allowing trunking determination for distinct clientid4 values to happen in parallel, with serialization of trunking determination happening independently for each distinct clientid4 value.
o 個別のclientid4値ごとに独立して発生するトランキング決定のシリアル化を使用して、個別のclientid4値に対するトランキング決定を並行して実行できるようにすることで、上記の暗黙のシリアル化の多くを回避できます。
The procedure above has made no explicit mention of the possibility that server reboot can occur at any time. To address this possibility, the client should make sure the following steps are taken:
上記の手順では、サーバーの再起動がいつでも発生する可能性について明示的に言及していません。この可能性に対処するには、クライアントは次の手順を実行する必要があります。
o When a SETCLIENTID_CONFIRM is rejected by a given IPn, the client should be aware of the possibility that the rejection is due to XC (rather than XV) being invalid. This situation can be addressed by doing a RENEW specifying XC directed to the IP address X. If that operation succeeds, then the rejection is to be acted on normally since either XV is invalid on IPn or XC has become invalid on IPn while it is valid on X, showing that IPn and X are not trunked. If, on the other hand, XC is not valid on X, then the trunking detection process should be restarted once a new client ID is established on X.
o SETCLIENTID_CONFIRMが特定のIPnによって拒否された場合、クライアントは、拒否がXV（XVではなく）が無効であることによる可能性を認識している必要があります。この状況は、IPアドレスXに向けられたXCを指定するRENEWを実行することで対処できます。その操作が成功した場合、XVがIPnで無効であるか、XCが有効であるにもかかわらずIPnで無効になっているため、拒否が正常に実行されます。 Xで、IPnとXがトランクされていないことを示します。一方、XCがXで有効でない場合は、Xで新しいクライアントIDが確立されたら、トランキング検出プロセスを再開する必要があります。
o In the event of a reboot detected on any server-lead IP, the set of IP addresses associated with the server should not change, and state should be re-established for the lease as a whole, using all available connected server IP addresses. It is prudent to verify connectivity by doing a RENEW using the new clientid4 on each such server address before using it, however.
o サーバーリードIPで再起動が検出された場合、サーバーに関連付けられたIPアドレスのセットは変更されず、接続されているすべてのサーバーIPアドレスを使用して、リース全体の状態が再確立されます。ただし、使用する前に、そのような各サーバーアドレスで新しいclientid4を使用してRENEWを実行し、接続を確認することをお勧めします。
Another situation not discussed explicitly above is the possibility that a SETCLIENTID done to one of the IPn addresses might take so long that it is necessary to time out the operation, to prevent unacceptably delaying the MOUNT operation. One simple possibility is to simply fail the MOUNT at this point. Because the average number of IP addresses that might have to be tested is quite small, this will not greatly increase the probability of MOUNT failure. Other possible approaches are:
上記で明示的に説明されていない別の状況は、IPnアドレスの1つに対して実行されたSETCLIENTIDに時間がかかりすぎて、MOUNT操作の許容できない遅延を防ぐために操作をタイムアウトする必要がある可能性です。単純な可能性の1つは、この時点で単にMOUNTを失敗させることです。テストする必要があるIPアドレスの平均数は非常に少ないため、これはMOUNT障害の確率を大幅に増加させることはありません。その他の可能なアプローチは次のとおりです。
o If the IPn has sufficient state in existence, the existing stateids and sequence values might be validated by being used on IP address X. In the event of success, X and IPn should be considered trunked together.
o IPnに十分な状態が存在する場合、IPアドレスXで使用することにより、既存の状態IDとシーケンス値を検証できます。成功した場合、XとIPnは一緒にトランクされていると見なされます。
What constitutes "sufficient" state in this context is an implementation decision that is affected by the implementer's willingness to fail the MOUNT in an uncertain case and the strength of the state verification procedure implemented.
この文脈で「十分な」状態を構成するのは、不確実なケースでMOUNTを失敗させる実装者の意欲と実装された状態検証手順の強さによって影響を受ける実装決定です。
o If IPn has no locking state in existence, X could be recorded as a lead IP address on a provisional basis, subject to trunking being tested again, once IPn starts becoming responsive. To avoid confusion between IPn and X, and the need to merge distinct state corpora for X and IPn at a later point, this retest of trunking should occur after RENEWs on IPn are responded to and before establishing any new state for either IPn as a separate server or for IPn considered as a server address trunked with X.
o IPnにロック状態がない場合、Xは暫定的にリードIPアドレスとして記録されます。IPnが応答し始めると、トランキングが再度テストされる可能性があります。 IPnとXの混同を避け、XとIPnの異なる状態コーパスを後でマージする必要があるため、このトランキングの再テストは、IPnのRENEWが応答された後、いずれかのIPnの新しい状態を別の状態として確立する前に行う必要があります。サーバーまたはIPnはXでトランクされたサーバーアドレスと見なされます。
o The client locking-related code could be made more tolerant of what would otherwise be considered anomalous results due to an unrecognized trunking relationship. The client could use the appearance of behavior explainable by a previously unknown trunking relationship as the cue to consider the addresses as trunked.
o クライアントのロッキング関連のコードは、認識されないトランキング関係が原因で異常な結果と見なされることに対して、より寛容になる可能性があります。クライアントは、アドレスがトランキングされていると見なすためのキューとして、以前は未知のトランキング関係によって説明可能な動作の外観を使用できます。
This choice has a lot of complexity associated with it, and it is likely that few implementations will use it. When the set of locking state on IPn is small (e.g., a single stateid) but not empty, most client implementations are likely to either fail the MOUNT or implement a more stringent verification procedure using the existing stateid on IPn as a basis to generate further state as raw material for the trunking verification process.
この選択にはそれに関連する多くの複雑性があり、ほとんどの実装ではこれを使用しません。 IPnのロック状態のセットが小さい（たとえば、単一のstateid）が空ではない場合、ほとんどのクライアント実装は、MOUNTに失敗するか、IPnの既存のstateidを使用してさらに厳密な検証手順を実装し、さらに生成する可能性があります。トランキング検証プロセスの原材料としての状態。
This section gives more detailed guidance on client ID string construction. The guidance in this section will cover cases in which either the uniform or the non-uniform approach to the client ID string is used.
このセクションでは、クライアントIDの文字列の構築に関するより詳細なガイダンスを示します。このセクションのガイダンスでは、クライアントID文字列に対して統一的または非統一的なアプローチが使用されるケースについて説明します。
Note that among the items suggested for inclusion, there are many that may conceivably change. In order for the client ID string to remain valid in such circumstances, the client SHOULD either:
含めるように提案された項目の中には、おそらく変更される可能性のある多くのものがあることに注意してください。このような状況でクライアントID文字列を有効に保つには、クライアントは次のいずれかを行う必要があります。
o Use a saved copy of such value rather than the changeable value itself, or
o 変更可能な値自体ではなく、そのような値の保存されたコピーを使用する、または
o Save the constructed client ID string rather than constructing it anew at SETCLIENTID time, based on unchangeable parameters and saved copies of changeable data items.
o 変更できないパラメーターと変更可能なデータ項目の保存されたコピーに基づいて、SETCLIENTID時に新しく作成するのではなく、作成したクライアントID文字列を保存します。
A file is not always a valid choice to store such information, given the existence of diskless clients. In such situations, whatever facilities exist for a client to store configuration information such as boot arguments should be used.
ディスクレスクライアントの存在を考えると、ファイルはそのような情報を格納するための常に有効な選択ではありません。このような状況では、クライアントがブート引数などの構成情報を格納するために存在する機能を使用する必要があります。
Given the considerations listed in Section 5.2.1, an id string would be one that includes as its basis:
セクション5.2.1にリストされている考慮事項を考慮すると、id文字列はその基礎として含まれるものになります。
o An identifier uniquely associated with the node on which the client is running.
o クライアントが実行されているノードに一意に関連付けられた識別子。
o For a user-level NFSv4.0 client, it should contain additional information to distinguish the client from a kernel-based client and from other user-level clients running on the same node, such as a universally unique identifier (UUID).
o ユーザーレベルのNFSv4.0クライアントの場合、カーネルベースのクライアントや、同じノード上で実行されている他のユーザーレベルのクライアントと区別するために、Universally Unique Identifier（UUID）などの追加情報を含める必要があります。
o Where the non-uniform approach is to be used, the IP address of the server.
o 不均一なアプローチが使用される場合、サーバーのIPアドレス。
o Additional information that tends to be unique, such as one or more of:
o 以下の1つ以上など、一意になる傾向がある追加情報。
* The timestamp of when the NFSv4 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 NFSv4).
* NFSv4ソフトウェアがクライアントに最初にインストールされたときのタイムスタンプ（ファイルにアクセスできるのはNFSv4のみであるため、ファイルに格納されている情報の使用に関する前述の注意の対象となります）。
* A true random number, generally established once and saved.
* 真の乱数。通常、一度確立されて保存されます。
With regard to the identifier associated with the node on which the client is running, the following possibilities are likely candidates.
クライアントが実行されているノードに関連付けられている識別子に関しては、次の可能性が考えられます。
o The client machine's serial number.
o クライアントマシンのシリアル番号。
o The client's IP address. Note that this SHOULD be treated as a changeable value.
o クライアントのIPアドレス。これは変更可能な値として扱われる必要があることに注意してください。
o A Media Access Control (MAC) address. Note that this also should be considered a changeable value because of the possibility of configuration changes.
o メディアアクセスコントロール（MAC）アドレス。構成が変更される可能性があるため、これも変更可能な値と見なす必要があることに注意してください。
Privacy concerns may be an issue if some of the items above (e.g., machine serial number and MAC address) are used. When it is necessary to use such items to ensure uniqueness, application of a one-way hash function is desirable. When the non-uniform approach is used, that hash function should be applied to all of the components chosen as a unit rather than to particular individual elements.
上記の項目（マシンのシリアル番号やMACアドレスなど）の一部が使用されている場合、プライバシーの問題が問題になる可能性があります。このようなアイテムを使用して一意性を確保する必要がある場合は、一方向ハッシュ関数の適用が望ましいです。非均一アプローチを使用する場合、そのハッシュ関数は、特定の個々の要素ではなく、ユニットとして選択されたすべてのコンポーネントに適用する必要があります。
This section contains a replacement for Section 9.14 of [RFC7530], "Migration, Replication, and State".
このセクションには、[RFC7530]のセクション9.14、「移行、レプリケーション、および状態」の代わりが含まれています。
The replacement is in Section 6.1 and supersedes the replaced section.
置き換えはセクション6.1にあり、置き換えられたセクションに優先します。
The changes made can be briefly summarized as follows:
行われた変更は、次のように簡単に要約できます。
o Adding text to address the case of stateid conflict on migration.
o 移行時の状態IDの競合のケースに対処するためのテキストを追加します。
o Specifying that when leases are moved, as a result of file system migration, they are to be merged with leases on the destination server that are connected to the same client.
o ファイルシステムの移行の結果として、リースが移動されたときに、同じクライアントに接続されている移行先サーバーのリースとマージされることを指定します。
o Adding text that deals with the case of a clientid4 being changed on state transfer as a result of conflict with an existing clientid4.
o 既存のclientid4との競合の結果として、状態の転送時にclientid4が変更されるケースを処理するテキストを追加します。
o Adding a section describing how information associated with open-owners and lock-owners is to be managed with regard to migration.
o 移行に関するオープンオーナーおよびロックオーナーに関連する情報の管理方法を説明するセクションを追加します。
o The description of handling of the NFS4ERR_LEASE_MOVED has been rewritten for greater clarity.
o NFS4ERR_LEASE_MOVEDの処理の説明は、より明確にするために書き直されました。
File systems may transition to a different server in several circumstances:
ファイルシステムは、いくつかの状況で別のサーバーに移行することがあります。
o Responsibility for handling a given file system is transferred to a new server via migration.
o 特定のファイルシステムを処理する責任は、移行によって新しいサーバーに移されます。
o A client may choose to use an alternate server (e.g., in response to server unresponsiveness) in the context of file system replication.
o クライアントは、ファイルシステムレプリケーションのコンテキストで、（たとえば、サーバーが応答しないことに応じて）代替サーバーを使用することを選択できます。
In such cases, the appropriate handling of state shared between the client and server (i.e., locks, leases, stateids, and client IDs) is as described below. The handling differs between migration and replication.
このような場合、クライアントとサーバー間で共有される状態（つまり、ロック、リース、stateid、およびクライアントID）の適切な処理は、以下のとおりです。移行とレプリケーションでは処理が異なります。
If a server replica or a server immigrating a file system 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 (i.e., in a big-endian format). When doing so, servers acting as replicas or immigrating file systems will be able to parse values like stateids, directory cookies, filehandles, etc., even if their native byte order is different from that of other servers cooperating in the replication and migration of the file system.
サーバーレプリカまたはファイルシステムを移行するサーバーが、別のサーバーから発信されたクライアントからの不透明な値を受け入れることに同意する、または期待する場合、サーバーがネットワーク内の「不透明な」値をエンコードすることは賢明な実装方法です。バイトオーダー（つまり、ビッグエンディアン形式）。これを行うと、レプリカとして機能するサーバーまたはファイルシステムを移行するサーバーは、ネイティブバイトオーダーがレプリケーションと移行に協力している他のサーバーと異なる場合でも、stateid、ディレクトリCookie、ファイルハンドルなどの値を解析できます。ファイルシステム。
In the case of migration, the servers involved in the migration of a file system should transfer all server state associated with the migrating file system from source to the destination server. If state is transferred, this MUST be done in a way that is transparent to the client. This state transfer will ease the client's transition when a file system migration occurs. If the servers are successful in transferring all state, the client will continue to use stateids assigned by the original server. Therefore, the new server must recognize these stateids as valid and treat them as representing the same locks as they did on the source server.
移行の場合、ファイルシステムの移行に関与するサーバーは、移行元のファイルシステムに関連付けられているすべてのサーバー状態を移行元サーバーから移行先サーバーに転送する必要があります。状態が転送される場合、これはクライアントに対して透過的な方法で実行する必要があります。この状態転送により、ファイルシステムの移行が発生したときのクライアントの移行が容易になります。サーバーがすべての状態の転送に成功した場合、クライアントは元のサーバーによって割り当てられた状態IDを引き続き使用します。したがって、新しいサーバーはこれらの状態IDを有効であると認識し、ソースサーバーで行ったのと同じロックを表すものとして扱う必要があります。
In this context, the phrase "the same locks" means that:
この文脈では、「同じロック」というフレーズは次のことを意味します。
o They are associated with the same file.
o それらは同じファイルに関連付けられています。
o They represent the same types of locks, whether opens, delegations, advisory byte-range locks, or mandatory byte-range locks.
o それらは、オープン、委任、通知バイト範囲ロック、または必須バイト範囲ロックのいずれであっても、同じタイプのロックを表します。
o They have the same lock particulars, including such things as access modes, deny modes, and byte ranges.
o アクセスモード、拒否モード、バイト範囲など、ロックの詳細は同じです。
o They are associated with the same owner string(s).
o それらは同じ所有者文字列に関連付けられています。
If transferring stateids from server to server would result in a conflict for an existing stateid for the destination server with the existing client, transparent state migration MUST NOT happen for that client. Servers participating in using transparent state migration should coordinate their stateid assignment policies to make this situation unlikely or impossible. The means by which this might be done, like all of the inter-server interactions for migration, are not specified by the NFS version 4.0 protocol (neither in [RFC7530] nor this update).
サーバーからサーバーにステートIDを転送すると、宛先サーバーの既存のステートIDが既存のクライアントと競合する場合、そのクライアントでは透過的な状態移行を行ってはなりません（MUST NOT）。透過的な状態移行の使用に参加しているサーバーは、stateid割り当てポリシーを調整して、この状況を起こりそうにないか不可能にする必要があります。移行のためのすべてのサーバー間相互作用のように、これが行われる可能性がある手段は、NFSバージョン4.0プロトコルでは指定されていません（[RFC7530]にもこの更新にも含まれていません）。
A client may determine the disposition of migrated state by using a stateid associated with the migrated state on the new server.
クライアントは、新しいサーバー上の移行された状態に関連付けられた状態IDを使用して、移行された状態の後処理を決定できます。
o If the stateid is not valid and an error NFS4ERR_BAD_STATEID is received, either transparent state migration has not occurred or the state was purged due to a mismatch in the verifier (i.e., the boot instance id).
o 状態IDが無効であり、エラーNFS4ERR_BAD_STATEIDを受け取った場合、透過的な状態移行が発生していないか、ベリファイア（つまり、ブートインスタンスID）の不一致により状態が削除されています。
o If the stateid is valid, transparent state migration has occurred.
o stateidが有効な場合、透過的な状態移行が発生しています。
Since responsibility for an entire file system is transferred with a migration event, there is no possibility that conflicts will arise on the destination server as a result of the transfer of locks.
ファイルシステム全体の責任は移行イベントで転送されるため、ロックの転送の結果として移行先サーバーで競合が発生する可能性はありません。
The servers may choose not to transfer the state information upon migration. However, this choice is discouraged, except where specific issues such as stateid conflicts make it necessary. When a server implements migration and it does not transfer state information, it MUST provide a file-system-specific grace period, to allow clients to reclaim locks associated with files in the migrated file system. If it did not do so, clients would have to re-obtain locks, with no assurance that a conflicting lock was not granted after the file system was migrated and before the lock was re-obtained.
サーバーは、移行時に状態情報を転送しないことを選択できます。ただし、stateidの競合などの特定の問題によって必要になる場合を除いて、この選択はお勧めできません。サーバーが移行を実装し、状態情報を転送しない場合、クライアントは移行されたファイルシステム内のファイルに関連付けられたロックを再利用できるように、ファイルシステム固有の猶予期間を提供する必要があります。そうしないと、クライアントはロックを再取得する必要があり、ファイルシステムの移行後、ロックが再取得される前に、競合するロックが許可されなかったという保証はありません。
In the case of migration without state transfer, when the client presents state information from the original server (e.g., in a RENEW operation or a READ operation of zero length), the client must be prepared to receive either NFS4ERR_STALE_CLIENTID or NFS4ERR_BAD_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.
状態転送なしの移行の場合、クライアントが元のサーバーから状態情報を提示するとき（たとえば、RENEW操作または長さが0のREAD操作）、クライアントは新しいサーバーからNFS4ERR_STALE_CLIENTIDまたはNFS4ERR_BAD_STATEIDのいずれかを受信する準備をする必要があります。 。その後、クライアントは、サーバーの障害に応じて通常のように状態情報を回復する必要があります。新しいサーバーは、サーバーが再起動した場合と同様に、状態情報を回復できるように注意する必要があります。
In those situations in which state has not been transferred, as shown by a return of NFS4ERR_BAD_STATEID, the client may attempt to reclaim locks in order to take advantage of cases in which the destination server has set up a file-system-specific grace period in support of the migration.
NFS4ERR_BAD_STATEIDが返されることで示されるように、状態が転送されていない状況では、宛先サーバーがファイルシステム固有の猶予期間を設定した場合を利用するために、クライアントがロックを再利用しようとする場合があります。移行のサポート。
The handling of clientid4 values is similar to that for stateids. However, there are some differences that derive from the fact that a clientid4 is an object that spans multiple file systems while a stateid is inherently limited to a single file system.
clientid4値の処理は、stateidの場合と同様です。ただし、stateidは本質的に単一のファイルシステムに限定されるのに対し、clientid4は複数のファイルシステムにまたがるオブジェクトであるという事実から派生するいくつかの違いがあります。
The clientid4 and nfs_client_id4 information (id string and boot instance id) will be transferred with the rest of the state information, and the destination server should use that information to determine appropriate clientid4 handling. Although the destination server may make state stored under an existing lease available under the clientid4 used on the source server, the client should not assume that this is always so. In particular,
clientid4とnfs_client_id4の情報（ID文字列とブートインスタンスID）は、残りの状態情報とともに転送され、宛先サーバーはその情報を使用して、適切なclientid4処理を決定する必要があります。移行先サーバーは、移行元サーバーで使用されるclientid4の下で利用可能な既存のリースの下に格納された状態を作成する可能性がありますが、クライアントはこれが常にそうであると想定しないでください。特に、
o If there is an existing lease with an nfs_client_id4 that matches a migrated lease (same id string and verifier), the server SHOULD merge the two, making the union of the sets of stateids available under the clientid4 for the existing lease. As part of the lease merger, the expiration time of the lease will reflect renewal done within either of the ancestor leases (and so will reflect the latest of the renewals).
o 移行されたリース（同じID文字列とベリファイア）と一致するnfs_client_id4の既存のリースがある場合、サーバーは2つをマージして、既存のリースのclientid4で利用可能な状態IDのセットの結合を作成する必要があります。リースの統合の一環として、リースの有効期限には、祖先リースのいずれかで行われた更新が反映されます（したがって、最新の更新が反映されます）。
o If there is an existing lease with an nfs_client_id4 that partially matches a migrated lease (same id string and a different (boot) verifier), the server MUST eliminate one of the two, possibly invalidating one of the ancestor clientid4s. Since boot instance ids are not ordered, the later lease renewal time will prevail.
o 移行されたリースと部分的に一致するnfs_client_id4を持つ既存のリース（同じID文字列と異なる（ブート）ベリファイア）がある場合、サーバーは2つのうちの1つを削除しなければならず、祖先のclientid4の1つを無効にする可能性があります。ブートインスタンスIDは順序付けられていないため、後のリース更新時間が優先されます。
o If the destination server already has the transferred clientid4 in use for another purpose, it is free to substitute a different clientid4 and associate that with the transferred nfs_client_id4.
o 転送先サーバーが転送されたclientid4をすでに別の目的で使用している場合、別のclientid4を自由に置き換えて、転送されたnfs_client_id4に関連付けることができます。
When leases are not merged, the transfer of state should result in creation of a confirmed client record with empty callback information but matching the {v, x, c} with v and x derived from the transferred client information and c chosen by the destination server. For a description of this notation, see Section 8.4.5
リースがマージされない場合、状態の転送により、空のコールバック情報を持つ確認済みクライアントレコードが作成されますが、{v、x、c}は、転送されたクライアント情報から導出されたvおよびxと、宛先サーバーによって選択されたcに一致します。 。この表記法の説明については、セクション8.4.5を参照してください。
In such cases, the client SHOULD re-establish new callback information with the new server as soon as possible, according to sequences described in sections "Operation 35: SETCLIENTID -- Negotiate Client ID" and "Operation 36: SETCLIENTID_CONFIRM -- Confirm Client ID". This ensures that server operations are not delayed due to an inability to recall delegations and prevents the unwanted revocation of existing delegations. The client can determine the new clientid4 (the value c) from the response to SETCLIENTID.
このような場合、クライアントは、セクション「操作35：SETCLIENTID-ネゴシエートクライアントID」および「操作36：SETCLIENTID_CONFIRM-確認クライアントID 」これにより、委任を再呼び出しできないためにサーバー操作が遅延することがなくなり、既存の委任の不要な取り消しが防止されます。クライアントは、SETCLIENTIDへの応答から新しいclientid4（値c）を判別できます。
The client can use its own information about leases with the destination server to see if lease merger should have happened. When there is any ambiguity, the client MAY use the above procedure to set the proper callback information and find out, as part of the process, the correct value of its clientid4 with respect to the server in question.
クライアントは、宛先サーバーとのリースに関する独自の情報を使用して、リースのマージが発生したかどうかを確認できます。あいまいな場合、クライアントは上記の手順を使用して適切なコールバック情報を設定し、プロセスの一部として、問題のサーバーに関するclientid4の正しい値を見つけることができます（MAY）。
In addition to stateids, the locks they represent, and client identity information, servers also need to transfer information related to the current status of open-owners and lock-owners.
ステートID、それらが表すロック、およびクライアントID情報に加えて、サーバーはオープンオーナーおよびロックオーナーの現在のステータスに関連する情報を転送する必要もあります。
This information includes:
この情報は次のとおりです。
o The sequence number of the last operation associated with the particular owner.
o 特定の所有者に関連付けられている最後の操作のシーケンス番号。
o Sufficient information regarding the results of the last operation to allow reissued operations to be correctly responded to.
o 再発行された操作に正しく応答できるようにするための、最後の操作の結果に関する十分な情報。
When individual open-owners and lock-owners have only been used in connection with a particular file system, the server SHOULD transfer this information together with the lock state. The owner ceases to exist on the source server and is reconstituted on the destination server. This will happen in the case of clients that have been written to isolate each owner to a specific file system, but it may happen for other clients as well.
個々のオープンオーナーとロックオーナーが特定のファイルシステムに関連してのみ使用されている場合、サーバーはこの情報をロック状態とともに転送する必要があります（SHOULD）。所有者はソースサーバー上に存在しなくなり、宛先サーバー上で再構成されます。これは、各所有者を特定のファイルシステムに分離するように作成されたクライアントの場合に発生しますが、他のクライアントでも発生する可能性があります。
Note that when servers take this approach for all owners whose state is limited to the particular file system being migrated, doing so will not cause difficulties for clients not adhering to an approach in which owners are isolated to particular file systems. As long as the client recognizes the loss of transferred state, the protocol allows the owner in question to disappear, and the client may have to deal with an owner confirmation request that would not have occurred in the absence of the migration.
状態が移行中の特定のファイルシステムに限定されているすべての所有者に対してサーバーがこのアプローチを取る場合、そうすることで、クライアントが所有者を特定のファイルシステムに分離するアプローチを守らないという問題は発生しません。クライアントが転送された状態の喪失を認識している限り、プロトコルは問題の所有者が消えることを許可し、クライアントは移行がなければ発生しなかったであろう所有者確認要求を処理しなければならない場合があります。
When migration occurs and the source server discovers an owner whose state includes the migrated file system but other file systems as well, it cannot transfer the associated owner state. Instead, the existing owner state stays in place, but propagation of owner state is done as specified below:
移行が発生し、移行元サーバーが、移行されたファイルシステムだけでなく他のファイルシステムも含む状態の所有者を検出すると、関連付けられた所有者の状態を転送できません。代わりに、既存の所有者の状態はそのまま残りますが、所有者の状態の伝達は以下のように行われます。
o When the current seqid for an owner represents an operation associated with the file system being migrated, owner status SHOULD be propagated to the destination file system.
o 所有者の現在のseqidが、移行中のファイルシステムに関連付けられた操作を表す場合、所有者のステータスは、宛先ファイルシステムに伝達される必要があります（SHOULD）。
o When the current seqid for an owner does not represent an operation associated with the file system being migrated, owner status MAY be propagated to the destination file system.
o 所有者の現在のseqidが移行中のファイルシステムに関連付けられている操作を表していない場合、所有者のステータスが宛先ファイルシステムに伝達される場合があります。
o When the owner in question has never been used for an operation involving the migrated file system, the owner information SHOULD NOT be propagated to the destination file system.
o 問題の所有者が、移行されたファイルシステムに関係する操作に使用されたことがない場合、所有者情報は移行先のファイルシステムに伝播されるべきではありません（SHOULD NOT）。
Note that a server may obey all of the conditions above without the overhead of keeping track of a set of file systems that any particular owner has been associated with. Consider a situation in which the source server has decided to keep lock-related state associated with a file system fixed, preparatory to propagating it to the destination file system. If a client is free to create new locks associated with existing owners on other file systems, the owner information may be propagated to the destination file system, even though, at the time the file system migration is recognized by the client to have occurred, the last operation associated with the owner may not be associated with the migrating file system.
サーバーは、特定の所有者が関連付けられている一連のファイルシステムを追跡するオーバーヘッドなしに、上記のすべての条件に従う場合があることに注意してください。移行元サーバーが、ファイルシステムに関連付けられたロック関連の状態を固定して、移行先のファイルシステムに伝達する準備をしている状況を考えます。クライアントが他のファイルシステムの既存の所有者に関連付けられた新しいロックを自由に作成できる場合、ファイルシステムの移行が発生したとクライアントが認識したときに、所有者情報が宛先ファイルシステムに伝播されることがあります。所有者に関連付けられている最後の操作が、移行中のファイルシステムに関連付けられていない可能性があります。
When a source server propagates owner-related state associated with owners that span multiple file systems, it will propagate the owner sequence value to the destination server, while retaining it on the source server, as long as there exists state associated with the owner. When owner information is propagated in this way, source and destination servers start with the same owner sequence value that is then updated independently, as the client makes owner-related requests to the servers. Note that each server will have some period in which the associated sequence value for an owner is identical to the one transferred as part of migration. At those times, when a server receives a request with a matching owner sequence value, it MUST NOT respond with the associated stored response if the associated file system is not, when the reissued request is received, part of the set of file systems handled by that server.
ソースサーバーが、複数のファイルシステムにまたがる所有者に関連付けられた所有者関連の状態を伝達する場合、所有者に関連付けられた状態が存在する限り、ソースシーケンス値を保持しながら、所有者シーケンス値を宛先サーバーに伝達します。この方法で所有者情報が伝達されると、クライアントがサーバーに所有者関連の要求を行うため、ソースサーバーと宛先サーバーは同じ所有者シーケンス値で開始され、その後、個別に更新されます。各サーバーには、所有者に関連付けられたシーケンス値が移行の一部として転送されたものと同一である期間があることに注意してください。それらの時に、サーバーが所有者シーケンス値が一致する要求を受信したときに、関連するファイルシステムが再発行された要求を受信したときに、以下によって処理される一連のファイルシステムの一部でない場合、関連する格納された応答で応答してはなりません（MUST NOT）。そのサーバー。
One sort of case may require more complex handling. When multiple file systems are migrated, in sequence, to a specific destination server, an owner may be migrated to a destination server, on which it was already present, leading to the issue of how the resident owner information and that being newly migrated are to be reconciled.
1つのケースでは、より複雑な処理が必要になる場合があります。複数のファイルシステムが順番に特定の移行先サーバーに移行されると、所有者は移行先サーバーに移行されることがあります。移行先サーバーは、既に存在していたため、常駐所有者情報と新しく移行される情報がどのように移行するかという問題につながります。和解する。
If file system migration encounters a situation where owner information needs to be merged, it MAY decline to transfer such state, even if it chooses to handle other cases in which locks for a given owner are spread among multiple file systems.
ファイルシステムの移行で、所有者情報をマージする必要がある状況が発生した場合、特定の所有者のロックが複数のファイルシステムに分散している他のケースを処理することを選択した場合でも、そのような状態の転送は拒否される場合があります。
As a way of understanding the situations that need to be addressed when owner information needs to be merged, consider the following scenario:
所有者情報をマージする必要があるときに対処する必要がある状況を理解する方法として、次のシナリオを検討してください。
o There is client C and two servers, X and Y. There are two clientid4s designating C, which are referred to as CX and CY.
o クライアントCと2つのサーバー、XとYがあります。Cを指定する2つのclientid4があり、CXとCYと呼ばれます。
o Initially, server X supports file systems F1, F2, F3, and F4. These will be migrated, one at a time, to server Y.
o 最初は、サーバーXはファイルシステムF1、F2、F3、およびF4をサポートしています。これらは一度に1つずつサーバーYに移行されます。
o While these migrations are proceeding, the client makes locking requests for file systems F1 through F4 on behalf of owner O (either a lock-owner or an open-owner), with each request going to X or Y depending on where the relevant file system is being supported at the time the request is made.
o これらの移行が進行している間、クライアントは所有者O（ロック所有者またはオープン所有者）に代わってファイルシステムF1からF4のロック要求を行い、各要求は関連するファイルシステムの場所に応じてXまたはYに行きますリクエストが行われた時点でサポートされています。
o Once the first migration event occurs, client C will maintain two instances for owner O, one for each server.
o 最初の移行イベントが発生すると、クライアントCは、サーバーごとに1つずつ、所有者Oに対して2つのインスタンスを維持します。
o It is always possible that C may make a request of server X relating to owner O, and before receiving a response, it finds the target file system has moved to Y and needs to reissue the request to server Y.
o Cが所有者Oに関連するサーバーXに要求を出す可能性は常にあり、応答を受信する前に、ターゲットファイルシステムがYに移動し、サーバーYに要求を再発行する必要があることがわかります。
o At the same time, C may make a request of server Y relating to owner O, and this too may encounter a lost-response situation.
o 同時に、Cは所有者Oに関連するサーバーYに要求を行う場合があり、これも応答の喪失状況に遭遇する可能性があります。
As a result of such merger situations, the server will need to provide support for dealing with retransmission of owner-sequenced requests that diverge from the typical model in which there is support for retransmission of replies only for a request whose sequence value exactly matches the last one sent. In some situations, there may be two requests, each of which had the last sequence when it was issued. As a result of migration and owner merger, one of those will no longer be the last by sequence.
このようなマージ状況の結果として、サーバーは、シーケンス値が最後に正確に一致する要求に対してのみ応答の再送信がサポートされている一般的なモデルから分岐した、所有者順の要求の再送信を処理するためのサポートを提供する必要があります1つ送信しました。状況によっては、2つの要求があり、それぞれが発行されたときに最後のシーケンスを持っていました。移行と所有者の合併の結果、これらのうちの1つは最後のシーケンスではなくなります。
When servers do support such merger of owner information on the destination server, the following rules are to be adhered to:
サーバーが宛先サーバー上の所有者情報のこのようなマージをサポートしている場合、以下のルールが遵守されます。
o When an owner sequence value is propagated to a destination server where it already exists, the resulting sequence value is to be the greater of the one present on the destination server and the one being propagated as part of migration.
o 所有者シーケンス値がすでに存在する宛先サーバーに伝達される場合、結果のシーケンス値は、宛先サーバーに存在する値と、マイグレーションの一部として伝達される値のどちらか大きい方になります。
o In the event that an owner sequence value on a server represents a request applying to a file system currently present on the server, it is not to be rendered invalid simply because that sequence value is changed as a result of owner information propagation as part of file system migration. Instead, it is retained until it can be deduced that the client in question has received the reply.
o サーバー上の所有者シーケンス値が、サーバー上に現在存在するファイルシステムに適用される要求を表す場合、そのシーケンス値は、ファイルの一部としての所有者情報の伝播の結果として変更されるため、無効になりません。システムの移行。代わりに、問題のクライアントが応答を受信したと推定できるまで保持されます。
As a result of the operation of these rules, there are three ways in which there can be more reply data than what is typically present, i.e., data for a single request per owner whose sequence is the last one received, where the next sequence to be used is one beyond that.
これらのルールの操作の結果として、通常存在するものよりも多くの応答データが存在する可能性がある3つの方法があります。つまり、シーケンスが最後に受信された所有者ごとの単一の要求のデータで、次のシーケンスは使用されることはそれ以上のものです。
o When the owner sequence value for a migrating file system is greater than the corresponding value on the destination server, the last request for the owner in effect at the destination server needs to be retained, even though it is no longer one less than the next sequence to be received.
o 移行するファイルシステムの所有者シーケンスの値が、移行先サーバーの対応する値より大きい場合、移行先サーバーで有効な所有者の最後の要求は、次のシーケンスよりも小さいものではなくても、保持する必要があります。受け取ります。
o When the owner sequence value for a migrating file system is less than the corresponding value on the destination server, the sequence number for last request for the owner in effect on the migrating file system needs to be retained, even though it is no longer than one less the next sequence to be received.
o 移行するファイルシステムの所有者のシーケンス値が、移行先サーバーの対応する値よりも小さい場合、移行するファイルシステムで有効な所有者の最後の要求のシーケンス番号は、1以下ではなくても保持する必要があります。受信する次のシーケンスを減らします。
o When the owner sequence value for a migrating file system is equal to the corresponding value on the destination server, one has two different "last" requests that both must be retained. The next sequence value to be used is one beyond the sequence value shared by these two requests.
o 移行するファイルシステムの所有者シーケンスの値が、移行先サーバーの対応する値と等しい場合、1つに2つの異なる「最後の」要求があり、両方を保持する必要があります。次に使用されるシーケンス値は、これら2つの要求で共有されるシーケンス値を超えたものです。
Here are some guidelines as to when servers can drop such additional reply data, which is created as part of owner information migration.
所有者情報の移行の一環として作成される、このような追加の応答データをサーバーがいつドロップできるかに関するいくつかのガイドラインを次に示します。
o The server SHOULD NOT drop this information simply because it receives a new sequence value for the owner in question, since that request may have been issued before the client was aware of the migration event.
o クライアントが移行イベントを認識する前にリクエストが発行された可能性があるため、サーバーは、問題の所有者の新しいシーケンス値を受信するため、この情報を削除しないでください。
o The server SHOULD drop this information if it receives a new sequence value for the owner in question, and the request relates to the same file system.
o 問題の所有者の新しいシーケンス値を受信し、リクエストが同じファイルシステムに関連している場合、サーバーはこの情報を削除する必要があります（SHOULD）。
o The server SHOULD drop the part of this information that relates to non-migrated file systems if it receives a new sequence value for the owner in question, and the request relates to a non-migrated file system.
o サーバーは、問題の所有者の新しいシーケンス値を受け取り、リクエストが移行されていないファイルシステムに関連している場合、移行されていないファイルシステムに関連するこの情報の一部を削除する必要があります。
o The server MAY drop this information when it receives a new sequence value for the owner in question for a considerable period of time (more than one or two lease periods) after the migration occurs.
o 移行が発生した後、サーバーは問題の所有者の新しいシーケンス値をかなりの期間（1つまたは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 client IDs 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 file systems, 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 its original lock had been revoked.
レプリケーションの場合のクライアントの切り替えはサーバーの制御下にないため、状態の処理は異なります。この場合、リース、ステートID、およびクライアントIDは、あるサーバーから別のサーバーへの移行にわたって有効ではありません。クライアントは、新しいサーバーでロックを再確立する必要があります。これは、サーバーの再起動後の再利用タイプの要求によるロックの再確立と比較できます。違いは、サーバーには、ロックを再利用する要求と新しいロックを取得する要求を区別したり、ロックを延期したりする機能がないことです。したがって、クライアントが（LOCKまたはOPEN要求によって）新しいサーバーでロックを再確立すると、競合するロックのために要求が拒否される場合があります。レプリケーションはファイルシステムの読み取り専用の使用を目的としているため、このようなロックの拒否は、実際には大きな困難をもたらすことはありません。新しいサーバーでロックを再確立する試みが拒否された場合、クライアントは、元のロックが取り消されたかのように状況を処理する必要があります。
A file system can be migrated to another server while a client that has state related to that file system is not actively submitting requests to it. In this case, the migration is reported to the client during lease renewal. Lease renewal can occur either explicitly via a RENEW operation or implicitly when the client performs a lease-renewing operation on another file system on that server.
ファイルシステムは、そのファイルシステムに関連する状態を持つクライアントがアクティブに要求を送信していない間に、別のサーバーに移行できます。この場合、リースの更新中に移行がクライアントに報告されます。リースの更新は、RENEW操作によって明示的に、またはクライアントがそのサーバー上の別のファイルシステムでリース更新操作を実行するときに暗黙的に発生します。
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. Similarly, when migration occurs but there has not been transparent state migration, the client needs to find out about the change soon enough to be able to reclaim the lock within the destination server's grace period. To accomplish this, all operations that implicitly renew leases for a client (such as OPEN, CLOSE, READ, WRITE, RENEW, LOCK, and others) will return the error NFS4ERR_LEASE_MOVED if responsibility for any of the leases to be renewed has been transferred to a new server. Note that when the transfer of responsibility leaves remaining state for that lease on the source server, the lease is renewed just as it would have been in the NFS4ERR_OK case, despite returning the error. The transfer of responsibility happens when the server receives a GETATTR(fs_locations) from the client for each file system for which a lease has been moved to a new server. Normally, it does this after receiving an NFS4ERR_MOVED for an access to the file system, but the server is not required to verify that this happens in order to terminate the return of NFS4ERR_LEASE_MOVED. By convention, the compounds containing GETATTR(fs_locations) SHOULD include an appended RENEW operation to permit the server to identify the client getting the information.
クライアントが新しいサーバーに再配置された可能性のあるリースの更新をスケジュールするためには、クライアントはそれらのリースの有効期限が切れる前にリースの再配置について調べる必要があります。同様に、移行が発生しても透過的な状態移行がなかった場合、クライアントは、移行先サーバーの猶予期間内にロックを再利用できるようになるまでに、変更についてすぐに知る必要があります。これを実現するために、クライアントのリースを暗黙的に更新するすべての操作（OPEN、CLOSE、READ、WRITE、RENEW、LOCKなど）は、更新されるリースのいずれかの責任がに転送された場合、エラーNFS4ERR_LEASE_MOVEDを返します。新しいサーバー。責任の移行により、ソースサーバー上のそのリースの状態が残ったままになると、エラーが返されても、NFS4ERR_OKの場合と同様にリースが更新されます。サーバーがリースを新しいサーバーに移動したファイルシステムごとにクライアントからGETATTR（fs_locations）を受信すると、責任の移転が発生します。通常、これは、ファイルシステムへのアクセスのNFS4ERR_MOVEDを受信した後に行われますが、サーバーは、NFS4ERR_LEASE_MOVEDの戻りを終了するためにこれが発生することを確認する必要はありません。慣例により、GETATTR（fs_locations）を含むコンパウンドには、サーバーが情報を取得するクライアントを識別できるようにするために、追加されたRENEW操作を含める必要があります（SHOULD）。
Note that the NFS4ERR_LEASE_MOVED error is required only when responsibility for at least one stateid has been affected. In the case of a null lease, where the only associated state is a clientid4, an NFS4ERR_LEASE_MOVED error SHOULD NOT be generated.
NFS4ERR_LEASE_MOVEDエラーは、少なくとも1つの状態IDの責任が影響を受けている場合にのみ必要であることに注意してください。関連する唯一の状態がclientid4であるnullリースの場合、NFS4ERR_LEASE_MOVEDエラーが生成されるべきではありません（SHOULD NOT）。
Upon receiving the NFS4ERR_LEASE_MOVED error, a client that supports file system migration MUST perform the necessary GETATTR operation for each of the file systems containing state that have been migrated, so it gives the server evidence that it is aware of the migration of the file system. Once the client has done this for all migrated file systems on which the client holds state, the server MUST resume normal handling of stateful requests from that client.
NFS4ERR_LEASE_MOVEDエラーを受信すると、ファイルシステムの移行をサポートするクライアントは、移行された状態を含む各ファイルシステムに対して必要なGETATTR操作を実行する必要があるため、サーバーはファイルシステムの移行を認識していることを証明できます。クライアントが、クライアントが状態を保持しているすべての移行済みファイルシステムに対してこれを実行すると、サーバーは、そのクライアントからのステートフル要求の通常の処理を再開する必要があります。
One way in which clients can do this efficiently in the presence of large numbers of file systems is described below. This approach divides the process into two phases: one devoted to finding the migrated file systems, and the second devoted to doing the necessary GETATTRs.
多数のファイルシステムがある場合にクライアントがこれを効率的に実行できる1つの方法を以下に説明します。このアプローチは、プロセスを2つのフェーズに分割します。1つは移行されたファイルシステムの検出に専念し、もう1つは必要なGETATTRの実行に専念します。
The client can find the migrated file systems by building and issuing one or more COMPOUND requests, each consisting of a set of PUTFH/ GETFH pairs, each pair using a filehandle in one of the file systems in question. All such COMPOUND requests can be done in parallel. The successful completion of such a request indicates that none of the file systems interrogated have been migrated while termination with NFS4ERR_MOVED indicates that the file system getting the error has migrated while those interrogated before it in the same COMPOUND have not. Those whose interrogation follows the error remain in an uncertain state and can be interrogated by restarting the requests from after the point at which NFS4ERR_MOVED was returned or by issuing a new set of COMPOUND requests for the file systems that remain in an uncertain state.
クライアントは、1つ以上のCOMPOUND要求を構築して発行することにより、移行されたファイルシステムを見つけることができます。各要求は、問題のファイルシステムの1つのファイルハンドルを使用して、PUTFH / GETFHペアのセットで構成されます。このようなCOMPOUNDリクエストはすべて並行して実行できます。このような要求が正常に完了したことは、調査されたファイルシステムが移行されていないことを示しますが、NFS4ERR_MOVEDで終了すると、エラーが発生したファイルシステムは移行されましたが、同じCOMPOUNDで以前に調査されたファイルシステムは移行されませんでした。エラーの後に問い合わせがある問い合わせは不確定な状態のままであり、NFS4ERR_MOVEDが返された時点以降に要求を再開するか、不確定な状態のままであるファイルシステムに対して新しいCOMPOUND要求のセットを発行することによって問い合わせできます。
Once the migrated file systems have been found, all that is needed is for the client to give evidence to the server that it is aware of the migrated status of file systems found by this process, by interrogating the fs_locations attribute for a filehandle within each of the migrated file systems. The client can do this by building and issuing one or more COMPOUND requests, each of which consists of a set of PUTFH operations, each followed by a GETATTR of the fs_locations attribute. A RENEW is necessary to enable the operations to be associated with the lease returning NFS4ERR_LEASE_MOVED. Once the client has done this for all migrated file systems on which the client holds state, the server will resume normal handling of stateful requests from that client.
移行されたファイルシステムが見つかったら、クライアントが各プロセス内のファイルハンドルのfs_locations属性を調べることにより、このプロセスで見つかったファイルシステムの移行ステータスを認識していることをクライアントがサーバーに証明するだけで済みます。移行されたファイルシステム。クライアントは、1つ以上のCOMPOUND要求を作成して発行することでこれを行うことができます。各要求は、一連のPUTFH操作で構成され、それぞれにfs_locations属性のGETATTRが続きます。操作をNFS4ERR_LEASE_MOVEDを返すリースに関連付けるには、RENEWが必要です。クライアントが状態を保持しているすべての移行済みファイルシステムに対してクライアントがこれを実行すると、サーバーはそのクライアントからのステートフル要求の通常の処理を再開します。
In order to support legacy clients that do not handle the NFS4ERR_LEASE_MOVED error correctly, the server SHOULD time out after a wait of at least two lease periods, at which time it will resume normal handling of stateful requests from all clients. If a client attempts to access the migrated files, the server MUST reply with NFS4ERR_MOVED. In this situation, it is likely that the client would find its lease expired, although a server may use "courtesy" locks (as described in Section 9.6.3.1 of [RFC7530]) to mitigate the issue.
NFS4ERR_LEASE_MOVEDエラーを正しく処理しないレガシークライアントをサポートするために、サーバーは少なくとも2つのリース期間の待機後にタイムアウトする必要があり、その時点ですべてのクライアントからのステートフル要求の通常の処理を再開します。クライアントが移行されたファイルにアクセスしようとする場合、サーバーはNFS4ERR_MOVEDで応答する必要があります。この状況では、サーバーは「礼儀」ロックを使用して（[RFC7530]のセクション9.6.3.1で説明されているように）、問題を軽減するために、クライアントがリースの期限切れを見つける可能性があります。
When the client receives an NFS4ERR_MOVED error, the client can follow the normal process to obtain the destination 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. The client can then recover state information as it does in the event of server failure.
クライアントがNFS4ERR_MOVEDエラーを受信すると、クライアントは通常のプロセスに従って（fs_locations属性を通じて）宛先サーバー情報を取得し、新しいサーバーでこれらのリースの更新を実行できます。サーバーが透過的に状態を転送していない場合、クライアントは、上記のように、新しいサーバーからNFS4ERR_STALE_CLIENTIDまたはNFS4ERR_STALE_STATEIDを受け取ります。その後、クライアントは、サーバーに障害が発生した場合と同様に、状態情報を回復できます。
Aside from recovering from a migration, there are other reasons a client may wish to retrieve fs_locations information from a server. When a server becomes unresponsive, for example, a client may use cached fs_locations data to discover an alternate server hosting the same file system data. A client may periodically request fs_locations data from a server in order to keep its cache of fs_locations data fresh.
マイグレーションからのリカバリーの他に、クライアントがサーバーからfs_locations情報を取得したい場合がある他の理由があります。たとえば、サーバーが応答しなくなった場合、クライアントはキャッシュされたfs_locationsデータを使用して、同じファイルシステムデータをホストしている代替サーバーを検出できます。クライアントは、fs_locationsデータのキャッシュを最新の状態に保つために、サーバーに定期的にfs_locationsデータを要求できます。
Since a GETATTR(fs_locations) operation would be used for refreshing cached fs_locations data, a server could mistake such a request as indicating recognition of an NFS4ERR_LEASE_MOVED condition. Therefore, a compound that is not intended to signal that a client has recognized a migrated lease SHOULD be prefixed with a guard operation that fails with NFS4ERR_MOVED if the filehandle being queried is no longer present on the server. The guard can be as simple as a GETFH operation.
GETATTR（fs_locations）操作は、キャッシュされたfs_locationsデータを更新するために使用されるため、サーバーは、NFS4ERR_LEASE_MOVED状態の認識を示すものとして、そのような要求を誤解する可能性があります。したがって、クライアントが移行されたリースを認識したことを通知することを目的としないコンパウンドには、クエリされているファイルハンドルがサーバー上に存在しない場合、NFS4ERR_MOVEDで失敗するガード操作がプレフィックスとして付加されるべきです（SHOULD）。ガードは、GETFH操作と同じくらい簡単です。
Though unlikely, it is possible that the target of such a compound could be migrated in the time after the guard operation is executed on the server but before the GETATTR(fs_locations) operation is encountered. When a client issues a GETATTR(fs_locations) operation as part of a compound not intended to signal recognition of a migrated lease, it SHOULD be prepared to process fs_locations data in the reply that shows the current location of the file system is gone.
可能性は低いですが、サーバー上でガード操作が実行された後、GETATTR（fs_locations）操作が発生する前に、このような化合物のターゲットが移行される可能性があります。クライアントが、移行されたリースの認識を通知することを意図していないコンパウンドの一部としてGETATTR（fs_locations）操作を発行する場合、ファイルシステムの現在の場所がなくなったことを示す応答でfs_locationsデータを処理する準備をする必要があります。
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.
移行時にクライアントがリースを適切に管理できるようにするために、移行先サーバーは、lease_time属性に適切な値を設定する必要があります。
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 refetch the lease_time attribute and may continue to use the value previously fetched (on the source server).
状態が透過的に転送される場合、その状態には、lease_time属性の正しい値が含まれている必要があります。ソースサーバーによって付与されたリースの期限切れが早まるため、宛先サーバーのlease_time属性をソースの属性よりも小さくすることはできません。状態が透過的に転送される移行では、クライアントは、lease_time属性を再フェッチする義務はなく、以前にフェッチした値（ソースサーバー上）を引き続き使用できます。
In the case in which lease merger occurs as part of state transfer, the lease_time attribute of the destination lease remains in effect. The client can simply renew that lease with its existing lease_time attribute. State in the source lease is renewed at the time of transfer so that it cannot expire, as long as the destination lease is appropriately renewed.
リースのマージが状態転送の一部として発生する場合、宛先リースのlease_time属性は引き続き有効です。クライアントは、既存のlease_time属性でそのリースを更新するだけです。ソースリースの状態は転送時に更新されるため、宛先リースが適切に更新されている限り、期限が切れることはありません。
If state has not been transferred transparently (i.e., the client needs to reclaim or re-obtain its locks), the client should fetch the value of lease_time on the new (i.e., destination) server, and use it 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.0 protocol.
状態が透過的に転送されていない場合（つまり、クライアントがロックを再利用または再取得する必要がある場合）、クライアントは新しい（宛先）サーバーのlease_timeの値をフェッチし、それを後続のロック要求に使用する必要があります。ただし、サーバーは、少なくともソースサーバーのlease_timeの間は猶予期間を尊重する必要があります。これにより、競合する可能性のある非再利用ロックが許可される前に、クライアントがロックを再利用する十分な時間を確保できます。新しいサーバーが古いサーバーのlease_timeの値を取得する方法は、サーバーの実装に任されています。 NFSバージョン4.0プロトコルでは指定されていません。
This section provides suggestions to help server implementers deal with issues involved in the transparent transfer of file-system-related data between servers. Servers are not obliged to follow these suggestions but should be sure that their approach to the issues handle all the potential problems addressed below.
このセクションでは、サーバー間のファイルシステム関連データの透過的な転送に関連する問題にサーバー実装者が対処するのに役立つ提案を提供します。サーバーはこれらの提案に従う義務はありませんが、問題に対する彼らのアプローチが以下で対処されるすべての潜在的な問題を処理することを確認する必要があります。
7.1. Relation of Locking State Transfer to Other Aspects of File System Motion
7.1. ロック状態転送とファイルシステムモーションの他の側面との関係
In many cases, state transfer will be part of a larger function wherein the contents of a file system are transferred from server to server. Although specifics will vary with the implementation, the relation between the transfer of persistent file data and metadata and the transfer of state will typically be described by one of the cases below.
多くの場合、状態転送は、ファイルシステムのコンテンツがサーバー間で転送される、より大きな機能の一部になります。詳細は実装によって異なりますが、永続ファイルデータとメタデータの転送と状態の転送の関係は、通常、以下のいずれかのケースで説明されます。
o In some implementations, access to the on-disk contents of a file system can be transferred from server to server by making the storage devices on which the file system resides physically accessible from multiple servers, and transferring the right and responsibility for handling that file system from server to server.
o 一部の実装では、ファイルシステムのディスク上のコンテンツへのアクセスは、ファイルシステムが存在するストレージデバイスを複数のサーバーから物理的にアクセス可能にし、そのファイルシステムを処理する権利と責任を移転することにより、サーバーからサーバーに転送できます。サーバーからサーバーへ。
In such implementations, the transfer of locking state happens on its own, as described in Section 7.2. The transfer of physical access to the file system happens after the locking state is transferred and before any subsequent access to the file system. In cases where such transfer is not instantaneous, there will be a period in which all operations on the file system are held off, either by having the operations themselves return NFS4ERR_DELAY or, where this is not allowed, by using the techniques described below in Section 7.2.
そのような実装では、7.2節で説明したように、ロック状態の転送はそれ自体で発生します。ファイルシステムへの物理アクセスの転送は、ロック状態が転送された後、ファイルシステムへのその後のアクセスの前に行われます。そのような転送が瞬間的でない場合、操作自体がNFS4ERR_DELAYを返すか、または許可されていない場合は、以下のセクションで説明する手法を使用することにより、ファイルシステム上のすべての操作が保留される期間があります。 7.2。
o In other implementations, file system data and metadata must be copied from the server where they have existed to the destination server. Because of the typical amounts of data involved, it is generally not practical to hold off access to the file system while this transfer is going on. Normal access to the file system, including modifying operations, will generally happen while the transfer is going on.
o 他の実装では、ファイルシステムのデータとメタデータは、それらが存在していたサーバーから宛先サーバーにコピーする必要があります。関係するデータの量は一般的であるため、この転送が行われている間は、ファイルシステムへのアクセスを保留することは一般的に現実的ではありません。変更操作を含むファイルシステムへの通常のアクセスは、通常、転送の進行中に行われます。
Eventually, the file system copying process will complete. At this point, there will be two valid copies of the file system, one on each of the source and destination servers. Servers may maintain that state of affairs by making sure that each modification to file system data is done on both the source and destination servers.
最終的に、ファイルシステムのコピープロセスが完了します。この時点で、ファイルシステムの有効なコピーが2つあり、ソースサーバーと宛先サーバーのそれぞれに1つずつ存在します。サーバーは、ファイルシステムデータに対する各変更がソースサーバーと宛先サーバーの両方で行われるようにすることで、その状態を維持できます。
Although the transfer of locking state can begin before the above state of affairs is reached, servers will often wait until it is arrived at to begin transfer of locking state. Once the transfer of locking state is completed, as described in the section below, clients may be notified of the migration event and access the destination file system on the destination server.
上記の状態に達する前にロック状態の転送を開始できますが、サーバーは、ロック状態の転送を開始するために到達するまで待機することがよくあります。以下のセクションで説明するように、ロック状態の転送が完了すると、クライアントに移行イベントが通知され、移行先サーバーの移行先ファイルシステムにアクセスできます。
o Another case in which file system data and metadata must be copied from server to server involves a variant of the pattern above. In cases in which a single file system moves between or among a small set of servers, it will transition to a server on which a previous instantiation of that same file system existed before. In such cases, it is often more efficient to update the previous file system instance to reflect changes made while the active file system was residing elsewhere rather than copying the file system data anew.
oファイルシステムのデータとメタデータをサーバー間でコピーする必要があるもう1つのケースは、上記のパターンの変形です。単一のファイルシステムが少数のサーバー間またはサーバー間を移動する場合、同じファイルシステムの以前のインスタンス化が以前に存在していたサーバーに移行します。このような場合、以前のファイルシステムインスタンスを更新して、ファイルシステムデータを新たにコピーするよりも、アクティブなファイルシステムが別の場所にある間に行われた変更を反映する方が効率的です。
In such cases, the copying of file system data and metadata is replaced by a process that validates each visible file system object, copying new objects and updating those that have changed since the file system was last present on the destination server. Although this process is generally shorter than a complete copy, it is generally long enough that it is not practical to hold off access to the file system while this update is going on.
このような場合、ファイルシステムデータとメタデータのコピーは、表示されている各ファイルシステムオブジェクトを検証し、新しいオブジェクトをコピーして、ファイルシステムが宛先サーバーに最後に存在してから変更されたオブジェクトを更新するプロセスに置き換えられます。このプロセスは通常、完全なコピーよりも短いですが、この更新が行われている間、ファイルシステムへのアクセスを保留することは実用的ではないため、一般に十分に長いです。
Eventually, the file system updating process will complete. At this point, there will be two valid copies of the file system, one on each of the source and destination servers. Servers may maintain that state of affairs just as is done in the previous case. Similarly, the transfer of locking state, once it is complete, allows the clients to be notified of the migration event and access the destination file system on the destination server.
最終的に、ファイルシステムの更新プロセスが完了します。この時点で、ファイルシステムの有効なコピーが2つあり、ソースサーバーと宛先サーバーのそれぞれに1つずつ存在します。サーバーは、前のケースと同じようにその状態を維持できます。同様に、ロック状態の転送は、完了すると、クライアントに移行イベントを通知し、宛先サーバーの宛先ファイルシステムにアクセスできるようにします。
When transferring locking state from the source to a destination server, there will be occasions when the source server will need to prevent operations that modify the state being transferred. For example, if the locking state at time T is sent to the destination server, any state change that occurs on the source server after that time but before the file system transfer is made effective will mean that the state on the destination server will differ from that on the source server, which matches what the client would expect to see.
ソースから宛先サーバーにロック状態を転送するとき、ソースサーバーは転送される状態を変更する操作を防止する必要がある場合があります。たとえば、時刻Tのロック状態が宛先サーバーに送信された場合、その時刻以降、ファイルシステム転送が有効になる前にソースサーバーで発生する状態変更は、宛先サーバーの状態とは異なることを意味します。ソースサーバー上で、クライアントが期待するものと一致します。
In general, a server can prevent some set of server-maintained data from changing by returning NFS4ERR_DELAY on operations that attempt to change that data. In the case of locking state for NFSv4.0, there are two specific issues that might interfere:
一般に、サーバーは、データを変更しようとする操作でNFS4ERR_DELAYを返すことにより、サーバーが管理するデータのセットが変更されるのを防ぐことができます。 NFSv4.0のロック状態の場合、干渉する可能性のある2つの特定の問題があります。
o Returning NFS4ERR_DELAY will not prevent state from changing in that owner-based sequence values will still change, even though NFS4ERR_DELAY is returned. For example, OPEN and LOCK will change state (in the form of owner seqid values) even when they return NFS4ERR_DELAY.
o NFS4ERR_DELAYが返されても、NFS4ERR_DELAYを返しても、所有者ベースのシーケンス値は変更されたままになるため、状態が変更されるのを防ぐことはできません。たとえば、OPENおよびLOCKは、NFS4ERR_DELAYを返した場合でも、（所有者seqid値の形式で）状態を変更します。
o Some operations that modify locking state are not allowed to return NFS4ERR_DELAY (i.e., OPEN_CONFIRM, RELEASE_LOCKOWNER, and RENEW).
o ロック状態を変更する一部の操作では、NFS4ERR_DELAY（つまり、OPEN_CONFIRM、RELEASE_LOCKOWNER、およびRENEW）を返すことが許可されていません。
Note that the first problem and most instances of the second can be addressed by returning NFS4ERR_DELAY on the operations that establish a filehandle within the target as one of the filehandles associated with the request, i.e., as either the current or saved filehandle. This would require returning NFS4ERR_DELAY under the following circumstances:
最初の問題と2番目の問題のほとんどのインスタンスは、ターゲットにファイルハンドルを要求に関連付けられたファイルハンドルの1つとして確立する操作でNFS4ERR_DELAYを返すことで、つまり現在のファイルハンドルまたは保存されたファイルハンドルとして対処できます。次の状況では、NFS4ERR_DELAYを返す必要があります。
o On a PUTFH that specifies a filehandle within the target file system.
o ターゲットファイルシステム内のファイルハンドルを指定するPUTFH。
o On a LOOKUP or LOOKUPP that crosses into the target file system.
o ターゲットファイルシステムと交差するLOOKUPまたはLOOKUPP。
As a result of doing this, OPEN_CONFIRM is dealt with, leaving only RELEASE_LOCKOWNER and RENEW still to be dealt with.
これを実行した結果、OPEN_CONFIRMが処理され、RELEASE_LOCKOWNERとRENEWのみが処理されます。
Note that if the server establishes and maintains a situation in which no request has, as either the current or saved filehandle, a filehandle within the target file system, no special handling of SAVEFH or RESTOREFH is required. Thus, the fact that these operations cannot return NFS4ERR_DELAY is not a problem since neither will establish a filehandle in the target file system as the current filehandle.
サーバーが、現在のファイルハンドルまたは保存されたファイルハンドルとして、ターゲットファイルシステム内のファイルハンドルとして要求がない状況を確立および維持する場合、SAVEFHまたはRESTOREFHの特別な処理は必要ありません。したがって、これらの操作がNFS4ERR_DELAYを返せないことは、どちらも現在のファイルハンドルとしてターゲットファイルシステムにファイルハンドルを確立しないため、問題にはなりません。
If the server is to establish the situation described above, it may have to take special note of long-running requests that started before state migration. Part of any solution to this issue will involve distinguishing two separate points in time at which handling for the target file system will change. Let us distinguish:
サーバーが上記の状況を確立する場合は、状態移行の前に開始された長時間実行されるリクエストに特別な注意を払う必要がある場合があります。この問題の解決策の一部として、ターゲットファイルシステムの処理が変更される2つの時点を区別する必要があります。区別しましょう：
o A time T after which the previously mentioned operations will return NFS4ERR_DELAY.
o 前述の操作がNFS4ERR_DELAYを返す時間T。
o A later time T' at which the server can consider file system locking state fixed, making it possible for it to be sent to the destination server.
o サーバーがファイルシステムのロック状態を修正済みと見なして、宛先サーバーに送信できるようになる、後の時刻T '。
For a server to decide on T', it must ensure that requests started before T cannot change target file system locking state, given that all those started after T are dealt with by returning NFS4ERR_DELAY upon setting filehandles within the target file system. Among the ways of doing this are:
サーバーがT 'を決定するには、Tの前に開始された要求がターゲットファイルシステムのロック状態を変更できないことを確認する必要があります。Tの後に開始されたすべての要求は、ターゲットファイルシステム内のファイルハンドルの設定時にNFS4ERR_DELAYを返すことで処理されます。これを行う方法には、次のものがあります。
o Keeping track of the earliest request started that is still in execution (for example, by keeping a list of active requests ordered by request start time). Requests that started before and are still in progress at time T may potentially affect the locking state; once the starting time of the earliest-started active request is later than T, the starting time of the first such request can be chosen as T' by the server since any request in progress after T' started after time T. Accordingly, it would not have been allowed to change locking state for the migrating file system and would have returned NFS4ERR_DELAY had it tried to make a change.
oまだ実行中の最初に開始されたリクエストを追跡します（たとえば、リクエストの開始時間順に並べられたアクティブなリクエストのリストを保持することにより）。以前に開始され、時刻Tでまだ進行中の要求は、ロック状態に影響を与える可能性があります。最も早く開始されたアクティブな要求の開始時刻がTより遅くなると、T 'の後に開始された要求は時間Tの後に開始されるため、最初のそのような要求の開始時刻はサーバーによってT'として選択できます。移行中のファイルシステムのロック状態を変更することは許可されておらず、変更を試みた場合にNFS4ERR_DELAYを返していました。
o Keeping track of the count of requests started before time T that have a filehandle within the target file system as either the current or saved filehandle. The server can then define T' to be the first time after T at which the count is zero.
o ターゲットファイルシステム内のファイルハンドルが現在のファイルハンドルまたは保存されたファイルハンドルのいずれかである、時刻Tより前に開始された要求の数を追跡します。次に、サーバーはT 'を、カウントがゼロになるTの後の最初の時間と定義できます。
The set of operations that change locking state include two that cannot be dealt with by the above approach, because they are not specific to a particular file system and do not use a current filehandle as an implicit parameter.
ロック状態を変更する操作のセットには、特定のファイルシステムに固有ではなく、現在のファイルハンドルを暗黙的なパラメーターとして使用しないため、上記のアプローチでは処理できない2つの操作が含まれます。
o RENEW can be dealt with by applying the renewal to state for non-transitioning file systems. The effect of renewal for the transitioning file system can be ignored, as long as the servers make sure that the lease on the destination server has an expiration time that is no earlier than the latest renewal done on the source server. This can be easily accomplished by making the lease expiration on the destination server equal to the time in which the state transfer was completed plus the lease period.
o RENEWは、非遷移ファイルシステムの状態に更新を適用することで処理できます。サーバーが移行先サーバーのリースの有効期限が移行元サーバーで行われた最新の更新より前でないことを確認している限り、移行中のファイルシステムの更新の影響は無視できます。これは、移行先サーバーのリースの有効期限を、状態転送が完了した時間にリース期間を加えた時間と等しくすることで簡単に実現できます。
o RELEASE_LOCKOWNER can be handled by propagating the fact of the lock-owner deletion (e.g., by using an RPC) to the destination server. Such a propagation RPC can be done as part of the operation, or the existence of the deletion can be recorded locally and propagation of owner deletions to the destination server done as a batch later. In either case, the actual deletions on the destination server have to be delayed until all of the other state information has been transferred.
o RELEASE_LOCKOWNERは、ロック所有者の削除の事実（RPCを使用するなど）を宛先サーバーに伝達することで処理できます。このような伝播RPCは操作の一部として実行できます。または、削除の存在をローカルに記録し、後でバッチとして所有者の削除を宛先サーバーに伝播することもできます。いずれの場合も、他のすべての状態情報が転送されるまで、移行先サーバーでの実際の削除を遅らせる必要があります。
Alternatively, RELEASE_LOCKOWNER can be dealt with by returning NFS4ERR_DELAY. In order to avoid compatibility issues for clients not prepared to accept NFS4ERR_DELAY in response to RELEASE_LOCKOWNER, care must be exercised. (See Section 8.3 for details.)
または、RELEASE_LOCKOWNERは、NFS4ERR_DELAYを返すことで処理できます。 RELEASE_LOCKOWNERに応答してNFS4ERR_DELAYを受け入れる準備ができていないクライアントの互換性の問題を回避するには、注意が必要です。 （詳細については、セクション8.3を参照してください。）
The approach outlined above, wherein NFS4ERR_DELAY is returned based primarily on the use of current and saved filehandles in the file system, prevents all reference to the transitioning file system rather than limiting the delayed operations to those that change locking state on the transitioning file system. Because of this, servers may choose to limit the time during which this broad approach is used by adopting a layered approach to the issue.
上記で概説したアプローチでは、NFS4ERR_DELAYは主にファイルシステム内の現在および保存されているファイルハンドルの使用に基づいて返されるため、遅延する操作を移行中のファイルシステムのロック状態を変更する操作に制限するのではなく、移行中のファイルシステムへのすべての参照を防止します。このため、サーバーは、問題に対して階層化されたアプローチを採用することにより、この広範なアプローチが使用される時間を制限することを選択する場合があります。
o During the preparatory phase, operations that change, create, or destroy locks or modify the valid set of stateids will return NFS4ERR_DELAY. During this phase, owner-associated seqids may change, and the identity of the file system associated with the last request for a given owner may change as well. Also, RELEASE_LOCKOWNER operations may be processed without returning NFS4ERR_DELAY as long as the fact of the lock-owner deletion is recorded locally for later transmission.
o 準備段階では、ロックを変更、作成、または破棄したり、有効な状態IDのセットを変更したりすると、NFS4ERR_DELAYが返されます。このフェーズでは、所有者に関連付けられたseqidが変更される場合があり、特定の所有者に対する最後の要求に関連付けられたファイルシステムのIDも変更される場合があります。また、ロック所有者の削除の事実が後で送信するためにローカルに記録されている限り、RELEASE_LOCKOWNER操作はNFS4ERR_DELAYを返さずに処理できます。
o During the restrictive phase, operations that change locking state for the file system in transition are prevented by returning NFS4ERR_DELAY on any attempt to make a filehandle within that file system either the current or saved filehandle for a request. RELEASE_LOCKOWNER operations may return NFS4ERR_DELAY, but if they are processed, the lock-owner deletion needs to be communicated immediately to the destination server.
o 制限フェーズでは、ファイルシステム内のファイルハンドルを要求に対して現在または保存済みのファイルハンドルにしようとすると、NFS4ERR_DELAYを返すことで、移行中のファイルシステムのロック状態を変更する操作を防止します。 RELEASE_LOCKOWNER操作はNFS4ERR_DELAYを返す場合がありますが、それらが処理された場合、ロック所有者の削除を宛先サーバーにすぐに通知する必要があります。
A possible sequence would be the following.
可能なシーケンスは次のようになります。
o The server enters the preparatory phase for the transitioning file system.
o サーバーは、移行するファイルシステムの準備段階に入ります。
o At this point, locking state, including stateids, locks, and owner strings, is transferred to the destination server. The seqids associated with owners are either not transferred or transferred on a provisional basis, subject to later change.
o この時点で、stateid、locks、およびowner文字列を含むロック状態が宛先サーバーに転送されます。所有者に関連付けられたseqidは転送されないか、暫定的に転送されますが、後で変更される可能性があります。
o After the above has been transferred, the server may enter the restrictive phase for the file system.
o 上記の転送後、サーバーはファイルシステムの制限フェーズに入る場合があります。
o At this point, the updated seqid values may be sent to the destination server.
o この時点で、更新されたseqid値が宛先サーバーに送信されます。
Reporting regarding pending owner deletions (as a result of RELEASE_LOCKOWNER operations) can be communicated at the same time.
保留中の所有者の削除に関するレポート（RELEASE_LOCKOWNER操作の結果として）も同時に通知できます。
o Once it is known that all of this information has been transferred to the destination server, and there are no pending RELEASE_LOCKOWNER notifications outstanding, the source server may treat the file system transition as having occurred and return NFS4ERR_MOVED when an attempt is made to access it.
o この情報のすべてが宛先サーバーに転送され、保留中のRELEASE_LOCKOWNER通知が未処理であることが判明すると、ソースサーバーはファイルシステムの移行を発生したものとして扱い、それにアクセスしようとするとNFS4ERR_MOVEDを返すことがあります。
This section contains a number of items that relate to the changes in the section above, but which, for one reason or another, exist in different portions of the specification to be updated.
このセクションには、上記のセクションの変更に関連するいくつかの項目が含まれていますが、何らかの理由で、仕様の更新される異なる部分に存在しています。
Summarized here are all the remaining changes, not included in the two main sections.
ここでは、残りのすべての変更点を要約します。2つの主要セクションには含まれていません。
o New definition of the error NFS4ERR_CLID_INUSE, appearing in Section 8.2. This replaces the definition in Section 13.1.10.1 in [RFC7530].
o セクション8.2に記載されているエラーNFS4ERR_CLID_INUSEの新しい定義。これは、[RFC7530]のセクション13.1.10.1の定義を置き換えます。
o A revision of the error definitions section to allow RELEASE_LOCKOWNER to return NFS4ERR_DELAY, with appropriate constraints to assure interoperability with clients not expecting this error to be returned. These changes are discussed in Section 8.2 and modify the error tables in Sections 13.2 and 13.4 in [RFC7530].
o エラー定義セクションが改訂され、RELEASE_LOCKOWNERがNFS4ERR_DELAYを返すことができるようになりました。適切な制約により、このエラーが返されることを期待しないクライアントとの相互運用性が保証されます。これらの変更については、セクション8.2で説明し、[RFC7530]のセクション13.2および13.4でエラーテーブルを変更します。
o A revised description of SETCLIENTID, appearing in Section 8.4. This brings the description into sync with the rest of the specification regarding NFS4ERR_CLID_INUSE. The revised description replaces the one in Section 16.33 of [RFC7530].
o セクション8.4にあるSETCLIENTIDの改訂された説明。これにより、NFS4ERR_CLID_INUSEに関する残りの仕様と説明が同期します。改訂された説明は、[RFC7530]のセクション16.33の説明を置き換えます。
o Some security-related changes appear in Sections 8.5 and 8.6. The Security Considerations section of this document (Section 9) describes the effect on the corresponding section (Section 19) in [RFC7530].
o 一部のセキュリティ関連の変更は、セクション8.5および8.6に記載されています。このドキュメントのセキュリティに関する考慮事項セクション（セクション9）では、[RFC7530]の対応するセクション（セクション19）への影響について説明しています。
The definition of this error is now as follows:
このエラーの定義は次のとおりです。
The SETCLIENTID operation has found that the id string within the specified nfs_client_id4 was previously presented with a different principal and that client instance currently holds an active lease. A server MAY return this error if the same principal is used, but a change in authentication flavor gives good reason to reject the new SETCLIENTID operation as not bona fide.
SETCLIENTID操作は、指定されたnfs_client_id4内のID文字列が以前に異なるプリンシパルで提示されており、そのクライアントインスタンスが現在アクティブなリースを保持していることを検出しました。同じプリンシパルが使用されている場合、サーバーはこのエラーを返す可能性がありますが、認証フレーバーの変更により、新しいSETCLIENTID操作を正当ではないものとして拒否する正当な理由が与えられます。
The existing error tables should be considered modified to allow NFS4ERR_DELAY to be returned by RELEASE_LOCKOWNER. However, the scope of this addition is limited and is not to be considered as making this error return generally acceptable.
既存のエラーテーブルは、NFS4ERR_DELAYがRELEASE_LOCKOWNERによって返されるように変更されていると考える必要があります。ただし、この追加の範囲は制限されており、このエラーの戻りを一般的に許容できるものと見なしてはなりません。
It needs to be made clear that servers may not return this error to clients not prepared to support file system migration. Such clients may be following the error specifications in [RFC7530] and so might not expect NFS4ERR_DELAY to be returned on RELEASE_LOCKOWNER.
サーバーがファイルシステムの移行をサポートする準備ができていないクライアントにこのエラーを返さない可能性があることを明確にする必要があります。このようなクライアントは、[RFC7530]のエラー仕様に従っている可能性があるため、RELEASE_LOCKOWNERでNFS4ERR_DELAYが返されるとは想定されていない可能性があります。
The following constraint applies to this additional error return, as if it were a note appearing together with the newly allowed error code:
次の制約は、新たに許可されたエラーコードと一緒に表示されるメモであるかのように、この追加のエラーリターンに適用されます。
In order to make server state fixed for a file system being migrated, a server MAY return NFS4ERR_DELAY in response to a RELEASE_LOCKOWNER that will affect locking state being propagated to a destination server. The source server MUST NOT do so unless it is likely that it will later return NFS4ERR_MOVED for the file system in question.
移行中のファイルシステムのサーバー状態を修正するために、サーバーは、移行先サーバーに伝達されるロック状態に影響を与えるRELEASE_LOCKOWNERに応答してNFS4ERR_DELAYを返す場合があります。問題のファイルシステムに対して後でNFS4ERR_MOVEDを返す可能性が高い場合を除き、ソースサーバーはこれを行わないでください。
In the context of lock-owner release, the set of file systems, such that server state being made fixed can result in NFS4ERR_DELAY, must include the file system on which the operation associated with the current lock-owner seqid was performed.
ロック所有者のリリースのコンテキストでは、サーバーの状態が修正されてNFS4ERR_DELAYになるようなファイルシステムのセットに、現在のロック所有者seqidに関連付けられた操作が実行されたファイルシステムを含める必要があります。
In addition, this set may include other file systems on which an operation associated with an earlier seqid for the current lock-owner seqid was performed, since servers will have to deal with the issue of an owner being used in succession for multiple file systems.
さらに、サーバーは複数のファイルシステムで連続して使用される所有者の問題に対処する必要があるため、このセットには、現在のロック所有者seqidの以前のseqidに関連付けられた操作が実行された他のファイルシステムが含まれる場合があります。
Thus, if a client is prepared to receive NFS4ERR_MOVED after creating state associated with a given file system, it also needs to be prepared to receive NFS4ERR_DELAY in response to RELEASE_LOCKOWNER, if it has used that owner in connection with a file on that file system.
したがって、特定のファイルシステムに関連付けられた状態を作成した後でクライアントがNFS4ERR_MOVEDを受信する準備ができている場合、そのファイルシステム上のファイルに関連してその所有者を使用している場合、RELEASE_LOCKOWNERに応答してNFS4ERR_DELAYを受信する準備も必要です。
client, callback, callback_ident -> clientid, setclientid_confirm
client、callback、callback_ident-> clientid、setclientid_confirm
struct SETCLIENTID4args {
nfs_client_id4 client;
cb_client4 callback;
uint32_t callback_ident;
};
struct SETCLIENTID4resok {
clientid4 clientid;
verifier4 setclientid_confirm;
};
union SETCLIENTID4res switch (nfsstat4 status) {
case NFS4_OK:
SETCLIENTID4resok resok4;
case NFS4ERR_CLID_INUSE:
clientaddr4 client_using;
default:
void;
};
The client uses the SETCLIENTID operation to notify the server of its intention to use a particular client identifier, callback, and callback_ident for subsequent requests that entail creating lock, share reservation, and delegation state on the server. Upon successful completion, the server will return a shorthand client ID that, if confirmed via a separate step, will be used in subsequent file locking and file open requests. Confirmation of the client ID must be done via the SETCLIENTID_CONFIRM operation to return the client ID and setclientid_confirm values, as verifiers, to the server. The reason why two verifiers are necessary is that it is possible to use SETCLIENTID and SETCLIENTID_CONFIRM to modify the callback and callback_ident information but not the shorthand client ID. In that event, the setclientid_confirm value is effectively the only verifier.
クライアントはSETCLIENTID操作を使用して、サーバー上でのロック、共有予約、および委任状態の作成を伴う後続の要求に対して、特定のクライアント識別子、コールバック、およびcallback_identを使用する意図をサーバーに通知します。正常に完了すると、サーバーは省略形のクライアントIDを返します。別の手順で確認された場合は、後続のファイルロックおよびファイルオープンリクエストで使用されます。クライアントIDの確認は、クライアントIDとsetclientid_confirmの値をベリファイアとしてサーバーに返すために、SETCLIENTID_CONFIRM操作を介して行う必要があります。 2つの検証が必要な理由は、SETCLIENTIDとSETCLIENTID_CONFIRMを使用して、コールバックとcallback_identの情報を変更できるが、省略形のクライアントIDは変更できないためです。その場合、事実上、setclientid_confirm値が唯一のベリファイアになります。
The callback information provided in this operation will be used if the client is provided an open delegation at a future point. Therefore, the client must correctly reflect the program and port numbers for the callback program at the time SETCLIENTID is used.
この操作で提供されるコールバック情報は、将来クライアントにオープンな委任が提供される場合に使用されます。したがって、クライアントは、SETCLIENTIDの使用時に、コールバックプログラムのプログラムとポート番号を正しく反映する必要があります。
The callback_ident value is used by the server on the callback. The client can leverage the callback_ident to eliminate the need for more than one callback RPC program number, while still being able to determine which server is initiating the callback.
callback_ident値は、サーバーがコールバックで使用します。クライアントは、callback_identを利用して、コールバックを開始しているサーバーを判別しながら、複数のコールバックRPCプログラム番号を不要にすることができます。
To specify the implementation of SETCLIENTID, the following notations are used.
SETCLIENTIDの実装を指定するには、次の表記法を使用します。
Let:
みましょう：
x be the value of the client.id subfield of the SETCLIENTID4args structure.
xは、SETCLIENTID4args構造体のclient.idサブフィールドの値です。
v be the value of the client.verifier subfield of the SETCLIENTID4args structure.
v SETCLIENTID4args構造のclient.verifierサブフィールドの値。
c be the value of the client ID field returned in the SETCLIENTID4resok structure.
cは、SETCLIENTID4resok構造体で返されるクライアントIDフィールドの値です。
k represent the value combination of the callback and callback_ident fields of the SETCLIENTID4args structure.
kは、SETCLIENTID4args構造体のcallbackおよびcallback_identフィールドの値の組み合わせを表します。
s be the setclientid_confirm value returned in the SETCLIENTID4resok structure.
■SETCLIENTID4resok構造体で返されるsetclientid_confirm値。
{ v, x, c, k, s } be a quintuple for a client record. A client record is confirmed if there has been a SETCLIENTID_CONFIRM operation to confirm it. Otherwise, it is unconfirmed. An unconfirmed record is established by a SETCLIENTID call.
{v、x、c、k、s}は、クライアントレコードの5つ組です。確認のためのSETCLIENTID_CONFIRM操作があった場合、クライアントレコードが確認されます。それ以外の場合は未確認です。未確認のレコードは、SETCLIENTID呼び出しによって確立されます。
Since SETCLIENTID is a non-idempotent operation, our treatment assumes use of a duplicate request cache (DRC). For a discussion of the DRC, see Section 9.1.7 of [RFC7530].
SETCLIENTIDはべき等ではない操作であるため、ここでの扱いは重複要求キャッシュ（DRC）の使用を前提としています。 DRCの説明については、[RFC7530]のセクション9.1.7を参照してください。
When the server gets a SETCLIENTID { v, x, k } request, it first does a number of preliminary checks as listed below before proceeding to the main part of SETCLIENTID processing.
サーバーがSETCLIENTID {v、x、k}リクエストを受け取ると、SETCLIENTID処理の主要部分に進む前に、以下にリストされているように、最初にいくつかの予備チェックを行います。
o It first looks up the request in the DRC. If there is a hit, it returns the result cached in the DRC. The server does NOT remove client state (locks, shares, delegations) nor does it modify any recorded callback and callback_ident information for client { x }. The server now proceeds to the main part of SETCLIENTID.
o まずDRCでリクエストを検索します。ヒットがある場合、DRCにキャッシュされた結果を返します。サーバーはクライアントの状態（ロック、共有、委任）を削除せず、クライアント{x}の記録されたコールバックとcallback_ident情報を変更しません。サーバーはSETCLIENTIDのメイン部分に進みます。
o Otherwise (i.e., in the case of any DRC miss), the server takes the client ID string x and searches for confirmed client records for x that the server may have recorded from previous SETCLIENTID calls. If there are no such records, or if all such records have a recorded principal that matches that of the current request's principal, then the preparatory phase proceeds as follows.
oそれ以外の場合（つまり、DRCミスの場合）、サーバーはクライアントID文字列xを取得し、サーバーが以前のSETCLIENTID呼び出しから記録したxの確認済みクライアントレコードを検索します。そのようなレコードがない場合、またはそのようなすべてのレコードに、現在のリクエストのプリンシパルと一致するプリンシパルが記録されている場合、準備フェーズは次のように進みます。
* If there is a confirmed client record with a matching client ID string and a non-matching principal, the server checks the current state of the associated lease. If there is no associated state for the lease, or the lease has expired, the server proceeds to the main part of SETCLIENTID.
* 一致するクライアントID文字列と一致しないプリンシパルを持つ確認済みのクライアントレコードがある場合、サーバーは関連するリースの現在の状態をチェックします。リースに関連付けられた状態がない場合、またはリースの有効期限が切れている場合、サーバーはSETCLIENTIDのメイン部分に進みます。
* Otherwise, the server is being asked to do a SETCLIENTID for a client by a non-matching principal while there is active state. In this case, the server rejects the SETCLIENTID request returning an NFS4ERR_CLID_INUSE error, since use of a single client with multiple principals is not allowed. Note that even though the previously used clientaddr4 is returned with this error, the use of the same id string with multiple clientaddr4s is not prohibited, while its use with multiple principals is prohibited.
* そうでない場合、サーバーは、アクティブな状態がある間、一致しないプリンシパルによってクライアントに対してSETCLIENTIDを実行するように求められます。この場合、サーバーはSETCLIENTID要求を拒否し、NFS4ERR_CLID_INUSEエラーを返します。これは、複数のプリンシパルを持つ単一のクライアントの使用が許可されていないためです。以前に使用されたclientaddr4がこのエラーで返されても、複数のclientaddr4で同じID文字列を使用することは禁止されていませんが、複数のプリンシパルでの使用は禁止されています。
If the SETCLIENTID has not been dealt with by DRC processing, and has not been rejected with an NFS4ERR_CLID_INUSE error, then the main part of SETCLIENTID processing proceeds, as described below.
SETCLIENTIDがDRC処理で処理されておらず、NFS4ERR_CLID_INUSEエラーで拒否されていない場合は、SETCLIENTID処理の主要部分が以下のように続行されます。
o The server checks if it has recorded a confirmed record for { v, x, c, l, s }, where l may or may not equal k. If so, and since the id verifier v of the request matches that which is confirmed and recorded, the server treats this as a probable callback information update and records an unconfirmed { v, x, c, k, t } and leaves the confirmed { v, x, c, l, s } in place, such that t != s. It does not matter if k equals l or not. Any pre-existing unconfirmed { v, x, c, *, * } is removed.
o サーバーは、{v、x、c、l、s}の確認済みレコードを記録したかどうかをチェックします。ここで、lはkと等しい場合と等しくない場合があります。その場合、リクエストのIDベリファイアvが確認および記録されたものと一致するため、サーバーはこれをコールバック情報の更新の可能性として扱い、未確認の{v、x、c、k、t}を記録して確認済みの{ v、x、c、l、s}が所定の位置に配置され、t！= sとなる。 kがlに等しいかどうかは問題ではありません。既存の未確認の{v、x、c、*、*}は削除されます。
The server returns { c, t }. It is indeed returning the old clientid4 value c, because the client apparently only wants to update callback value k to value l. It's possible this request is one from the Byzantine router that has stale callback information, but this is not a problem. The callback information update is only confirmed if followed up by a SETCLIENTID_CONFIRM { c, t }.
サーバーは{c、t}を返します。実際、クライアントはコールバック値kを値lに更新したいだけなので、古いclientid4値cを返します。このリクエストは、古いコールバック情報を持つビザンチンルーターからのリクエストである可能性がありますが、これは問題ではありません。コールバック情報の更新は、SETCLIENTID_CONFIRM {c、t}が続く場合にのみ確認されます。
The server awaits confirmation of k via SETCLIENTID_CONFIRM { c, t }.
サーバーは、SETCLIENTID_CONFIRM {c、t}によるkの確認を待ちます。
The server does NOT remove client (lock/share/delegation) state for x.
サーバーは、xのクライアント（ロック/共有/委任）状態を削除しません。
o The server has previously recorded a confirmed { u, x, c, l, s } record such that v != u, l may or may not equal k, and has not recorded any unconfirmed { *, x, *, *, * } record for x. The server records an unconfirmed { v, x, d, k, t } (d != c, t != s).
o サーバーは以前に、確認済みの{u、x、c、l、s}レコードを記録したため、v！= u、lはkに等しい場合と異なる場合があり、未確認の{*、x、*、*、* xのレコード。サーバーは未確認の{v、x、d、k、t}（d！= c、t！= s）を記録します。
The server returns { d, t }.
サーバーは{d、t}を返します。
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM { d, t }.
サーバーは、SETCLIENTID_CONFIRM {d、t}による{d、k}の確認を待ちます。
The server does NOT remove client (lock/share/delegation) state for x.
サーバーは、xのクライアント（ロック/共有/委任）状態を削除しません。
o The server has previously recorded a confirmed { u, x, c, l, s } record such that v != u, l may or may not equal k, and recorded an unconfirmed { w, x, d, m, t } record such that c != d, t != s, m may or may not equal k, m may or may not equal l, and k may or may not equal l. Whether w == v or w != v makes no difference. The server simply removes the unconfirmed { w, x, d, m, t } record and replaces it with an unconfirmed { v, x, e, k, r } record, such that e != d, e != c, r != t, r != s.
o サーバーは以前に、確認済みの{u、x、c、l、s}レコードを記録したため、v！= u、lはkに等しい場合と等しくない場合があり、未確認の{w、x、d、m、t}レコードを記録しましたc！= d、t！= s、mはkと等しくても等しくなくてもよく、mはlと等しくても等しくなくてもよく、kはlと等しくても等しくなくてもかまいません。 w == vでもw！= vでも違いはありません。サーバーは、未確認の{w、x、d、m、t}レコードを削除し、それを未確認の{v、x、e、k、r}レコードに置き換えるだけで、e！= d、e！= c、r ！= t、r！= s。
The server returns { e, r }.
サーバーは{e、r}を返します。
The server awaits confirmation of { e, k } via SETCLIENTID_CONFIRM { e, r }.
サーバーは、SETCLIENTID_CONFIRM {e、r}による{e、k}の確認を待ちます。
The server does NOT remove client (lock/share/delegation) state for x.
サーバーは、xのクライアント（ロック/共有/委任）状態を削除しません。
o The server has no confirmed { *, x, *, *, * } for x. It may or may not have recorded an unconfirmed { u, x, c, l, s }, where l may or may not equal k, and u may or may not equal v. Any unconfirmed record { u, x, c, l, * }, regardless whether u == v or l == k, is replaced with an unconfirmed record { v, x, d, k, t } where d != c, t != s.
o サーバーにはxの確認済み{*、x、*、*、*}がありません。未確認の{u、x、c、l、s}が記録されている場合と記録されていない場合があり、lはkと等しい場合と異なる場合があり、uはvと異なる場合があります。未確認のレコード{u、x、c、l 、*}は、u == vでもl == kでも、未確認のレコード{v、x、d、k、t}で置き換えられます。ここで、d！= c、t！= sです。
The server returns { d, t }.
サーバーは{d、t}を返します。
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM { d, t }. The server does NOT remove client (lock/share/ delegation) state for x.
サーバーは、SETCLIENTID_CONFIRM {d、t}による{d、k}の確認を待ちます。サーバーは、xのクライアント（ロック/共有/委任）状態を削除しません。
The server generates the clientid and setclientid_confirm values and must take care to ensure that these values are extremely unlikely to ever be regenerated.
サーバーはclientidとsetclientid_confirmの値を生成し、これらの値が再生成される可能性が極めて低いことを確認するように注意する必要があります。
Although the means by which the source and destination server communicate is not specified by NFSv4.0, the following security-related considerations for inter-server communication should be noted.
ソースおよび宛先サーバーが通信する手段はNFSv4.0では指定されていませんが、サーバー間通信に関する以下のセキュリティ関連の考慮事項に注意する必要があります。
o Communication between source and destination servers needs to be carried out in a secure manner, with protection against deliberate modification of data in transit provided by using either a private network or a security mechanism that ensures integrity. In many cases, privacy will also be required, requiring a strengthened security mechanism if a private network is not used.
o 送信元サーバーと送信先サーバーの間の通信は、プライベートネットワークまたは整合性を保証するセキュリティメカニズムを使用して提供される転送中のデータの意図的な変更に対する保護を備えた安全な方法で実行する必要があります。多くの場合、プライバシーも要求され、プライベートネットワークを使用しない場合は、強化されたセキュリティメカニズムが必要になります。
o Effective implementation of the file system migration function requires that a trust relationship exist between source and destination servers. The details of that trust relationship depend on the specifics of the inter-server transfer protocol, which is outside the scope of this specification.
o ファイルシステム移行機能を効果的に実装するには、ソースサーバーと宛先サーバーの間に信頼関係が存在する必要があります。その信頼関係の詳細は、サーバー間転送プロトコルの詳細に依存します。これは、この仕様の範囲外です。
o The source server may communicate to the destination server security-related information in order to allow it to more rigorously validate clients' identity. For example, the destination server might reject a SETCLIENTID done with a different principal or with a different IP address than was done previously by the client on the source server. However, the destination server MUST NOT use this information to allow any operation to be performed by the client that would not be allowed otherwise.
o ソースサーバーは、クライアントのIDをより厳密に検証できるようにするために、宛先サーバーのセキュリティ関連情報と通信する場合があります。たとえば、移行先サーバーは、移行元サーバーのクライアントによって以前に実行されたものとは異なるプリンシパルまたは異なるIPアドレスで実行されたSETCLIENTIDを拒否する場合があります。ただし、宛先サーバーは、この情報を使用して、他の方法では許可されない操作をクライアントが実行できるようにしてはなりません（MUST NOT）。
The penultimate paragraph of Section 19 of [RFC7530] should be revised to read as follows:
[RFC7530]のセクション19の最後から2番目の段落は、次のように修正する必要があります。
Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are responsible for the release of client state, it is imperative that the principal used for these operations be checked against and match the previous use of these operations. In addition, use of integrity protection is desirable on the SETCLIENTID operation, to prevent an attack whereby a change in the boot instance id (verifier) forces an undesired loss of client state. See Section 5 for further discussion.
操作SETCLIENTID / SETCLIENTID_CONFIRMはクライアントの状態の解放を担当するため、これらの操作に使用されるプリンシパルをチェックして、これらの操作の以前の使用と一致させることが不可欠です。さらに、SETCLIENTID操作では整合性保護を使用して、ブートインスタンスID（ベリファイア）の変更によってクライアントの状態が意図せず失われるような攻撃を防ぐことが望ましいです。詳細については、セクション5を参照してください。
The security considerations of [RFC7530] remain appropriate with the exception of the modification to the penultimate paragraph specified in Section 8.6 of this document and the addition of the material in Section 8.5.
[RFC7530]のセキュリティに関する考慮事項は、このドキュメントのセクション8.6で指定された最後から2番目の段落の変更とセクション8.5での資料の追加を除いて、引き続き適切です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7530]ヘインズ、T。、エド。およびD. Noveck編、「Network File System（NFS）Version 4 Protocol」、RFC 7530、DOI 10.17487 / RFC7530、2015年3月、<http://www.rfc-editor.org/info/rfc7530>。
[INFO-MIGR] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, "NFSv4 migration: Implementation experience and spec issues to resolve", Work in Progress, draft-ietf-nfsv4- migration-issues-09, February 2016.
[INFO-MIGR] Noveck、D.、Ed。、Shivam、P.、Lever、C。、およびB. Baker、「NFSv4の移行：実装経験と解決すべき仕様の問題」、進行中の作業、draft-ietf-nfsv4 -移行の問題-09、2016年2月。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, DOI 10.17487/RFC1813, June 1995, <http://www.rfc-editor.org/info/rfc1813>.
[RFC1813] Callaghan、B.、Pawlowski、B。、およびP. Staubach、「NFSバージョン3プロトコル仕様」、RFC 1813、DOI 10.17487 / RFC1813、1995年6月、<http://www.rfc-editor.org/ info / rfc1813>。
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <http://www.rfc-editor.org/info/rfc5661>.
[RFC5661] Shepler、S.、Ed。、Eisler、M.、Ed。、and D. Noveck、Ed。、 "Network File System（NFS）Version 4 Minor Version 1 Protocol"、RFC 5661、DOI 10.17487 / RFC5661、 2010年1月、<http://www.rfc-editor.org/info/rfc5661>。
Acknowledgements
謝辞
The editor and authors of this document gratefully acknowledge the contributions of Trond Myklebust of Primary Data and Robert Thurlow of Oracle. We also thank Tom Haynes of Primary Data and Spencer Shepler of Microsoft for their guidance and suggestions.
このドキュメントの編集者および作成者は、プライマリデータのトロンドマイクルバストおよびオラクルのロバートサーロウの貢献に深く感謝します。また、ガイダンスと提案を提供してくれたPrimary DataのTom HaynesとMicrosoftのSpencer Sheplerにも感謝します。
Special thanks go to members of the Oracle Solaris NFS team, especially Rick Mesta and James Wahlig, for their work implementing an NFSv4.0 migration prototype and identifying many of the issues addressed here.
Oracle Solaris NFSチームのメンバー、特にRick MestaとJames WahligのNFSv4.0移行プロトタイプの実装と、ここで取り上げられている問題の多くを特定してくださったことに感謝します。
Authors' Addresses
著者のアドレス
David Noveck (editor) Hewlett Packard Enterprise 165 Dascomb Road Andover, MA 01810 United States of America
David Noveck（編集者）Hewlett Packard Enterprise 165 Dascomb Road Andover、MA 01810アメリカ合衆国
Phone: +1 978 474 2011
Email: davenoveck@gmail.com
Piyush Shivam Oracle Corporation 5300 Riata Park Ct. Austin, TX 78727 United States of America
Piyush Shivam Oracle Corporation 5300 Riata Park Ct。オースティン、テキサス州78727アメリカ合衆国
Phone: +1 512 401 1019
Email: piyush.shivam@oracle.com
Charles Lever Oracle Corporation 1015 Granger Avenue Ann Arbor, MI 48104 United States of America
Charles Lever Oracle Corporation 1015 Granger Avenueアナーバー、ミシガン州48104アメリカ合衆国
Phone: +1 734 274 2396
Email: chuck.lever@oracle.com
Bill Baker Oracle Corporation 5300 Riata Park Ct. Austin, TX 78727 United States of America
ビルベイカーオラクルコーポレーション5300 Riata Park Ct。オースティン、テキサス州78727アメリカ合衆国
Phone: +1 512 401 1081
Email: bill.baker@oracle.com