Internet Engineering Task Force (IETF) B. Halevy
Request for Comments: 5664 B. Welch
Category: Standards Track J. Zelenka
ISSN: 2070-1721 Panasas
January 2010
Object-Based Parallel NFS (pNFS) Operations
Abstract
抽象
Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout-type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification.
パラレルNFS（pNFSの）は、クライアントが直接NFSv4サーバが使用するストレージ上のファイルデータにアクセスできるようにするネットワークファイルシステムバージョン4（NFSv4の）を拡張します。データ・アクセス用のサーバをバイパスするこの機能は、パフォーマンスと並列性の両方を増加させるが、レイアウトタイプとしても知られ、使用されているストレージのクラスに依存しているそのうちのいくつかは、データアクセスのための追加のクライアント機能を必要とすることができます。 NFSv4のマイナーバージョン1における主pNFSの操作とデータ型は、レイアウトタイプに依存しない層を指定します。レイアウト・タイプ固有の情報は、その内部構造は、さらに、特定のレイアウトタイプ仕様で規定された不透明なデータ構造を使用して搬送されます。この文書では、メインのNFSv4マイナーバージョン1仕様にコンパニオンとしてNFSv4.1オブジェクトベースpNFSのレイアウトタイプを指定します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション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/rfc5664.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5664で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. XDR Description of the Objects-Based Layout Protocol ............4
2.1. Code Components Licensing Notice ...........................4
3. Basic Data Type Definitions .....................................6
3.1. pnfs_osd_objid4 ............................................6
3.2. pnfs_osd_version4 ..........................................6
3.3. pnfs_osd_object_cred4 ......................................7
3.4. pnfs_osd_raid_algorithm4 ...................................8
4. Object Storage Device Addressing and Discovery ..................8
4.1. pnfs_osd_targetid_type4 ...................................10
4.2. pnfs_osd_deviceaddr4 ......................................10
4.2.1. SCSI Target Identifier .............................11
4.2.2. Device Network Address .............................11
5. Object-Based Layout ............................................12
5.1. pnfs_osd_data_map4 ........................................13
5.2. pnfs_osd_layout4 ..........................................14
5.3. Data Mapping Schemes ......................................14
5.3.1. Simple Striping ....................................15
5.3.2. Nested Striping ....................................16
5.3.3. Mirroring ..........................................17
5.4. RAID Algorithms ...........................................18
5.4.1. PNFS_OSD_RAID_0 ....................................18
5.4.2. PNFS_OSD_RAID_4 ....................................18
5.4.3. PNFS_OSD_RAID_5 ....................................18
5.4.4. PNFS_OSD_RAID_PQ ...................................19
5.4.5. RAID Usage and Implementation Notes ................19
6. Object-Based Layout Update .....................................20
6.1. pnfs_osd_deltaspaceused4 ..................................20
6.2. pnfs_osd_layoutupdate4 ....................................21
7. Recovering from Client I/O Errors ..............................21
8. Object-Based Layout Return .....................................22
8.1. pnfs_osd_errno4 ...........................................23
8.2. pnfs_osd_ioerr4 ...........................................24
8.3. pnfs_osd_layoutreturn4 ....................................24
9. Object-Based Creation Layout Hint ..............................25
9.1. pnfs_osd_layouthint4 ......................................25
10. Layout Segments ...............................................26
10.1. CB_LAYOUTRECALL and LAYOUTRETURN .........................27
10.2. LAYOUTCOMMIT .............................................27
11. Recalling Layouts .............................................27
11.1. CB_RECALL_ANY ............................................28
12. Client Fencing ................................................29
13. Security Considerations .......................................29
13.1. OSD Security Data Types ..................................30
13.2. The OSD Security Protocol ................................30
13.3. Protocol Privacy Requirements ............................32
13.4. Revoking Capabilities ....................................32
14. IANA Considerations ...........................................33
15. References ....................................................33
15.1. Normative References .....................................33
15.2. Informative References ...................................34
Appendix A. Acknowledgments ......................................35
In pNFS, the file server returns typed layout structures that describe where file data is located. There are different layouts for different storage systems and methods of arranging data on storage devices. This document describes the layouts used with object-based storage devices (OSDs) that are accessed according to the OSD storage protocol standard (ANSI INCITS 400-2004 [1]).
pNFSのでは、ファイルサーバのリターンは、ファイルデータが配置されている場所について説明したレイアウト構造を入力しました。異なるストレージシステムおよびストレージ・デバイス上のデータを配置する方法のためのさまざまなレイアウトがあります。この文書では、OSDストレージプロトコル標準（ANSI INCITS 400から2004 [1]）に応じてアクセスされるオブジェクトベースの記憶装置（のOSD）で使用されるレイアウトを記述する。
An "object" is a container for data and attributes, and files are stored in one or more objects. The OSD protocol specifies several operations on objects, including READ, WRITE, FLUSH, GET ATTRIBUTES, SET ATTRIBUTES, CREATE, and DELETE. However, using the object-based layout the client only uses the READ, WRITE, GET ATTRIBUTES, and FLUSH commands. The other commands are only used by the pNFS server.
「オブジェクト」は、データと属性のコンテナで、ファイルが1つまたは複数のオブジェクトに格納されています。 OSDプロトコルは、READ、WRITE、FLUSH、属性を取得、SETは、CREATE属性、およびDELETEなどのオブジェクトに対して複数の操作を指定します。ただし、属性を取得、WRITE、クライアントのみREADを使用するオブジェクトベースのレイアウトを使用して、FLUSHコマンド。他のコマンドは、唯一のpNFSサーバによって使用されています。
An object-based layout for pNFS includes object identifiers, capabilities that allow clients to READ or WRITE those objects, and various parameters that control how file data is striped across their component objects. The OSD protocol has a capability-based security scheme that allows the pNFS server to control what operations and what objects can be used by clients. This scheme is described in more detail in the "Security Considerations" section (Section 13).
pNFSのためのオブジェクトベースのレイアウトは、オブジェクト識別子、クライアントはそれらのオブジェクトを読み書きすることを可能にする機能、ファイルデータは、それらのコンポーネントオブジェクトにわたってストライピングされる方法を制御する様々なパラメータを含みます。 OSDプロトコルは、pNFSのサーバは、クライアントが使用することができるものの操作とどのようなオブジェクトを制御することを可能にする能力ベースのセキュリティスキームを持っています。この方式は、「セキュリティの考慮事項」のセクション（セクション13）においてより詳細に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
This document contains the external data representation (XDR [3]) description of the NFSv4.1 objects layout protocol. The XDR description is embedded in this document in a way that makes it simple for the reader to extract into a ready-to-compile form. The reader can feed this document into the following shell script to produce the machine readable XDR description of the NFSv4.1 objects layout protocol:
この文書は、外部データ表現が含まれている（XDR [3]）NFSv4.1の説明は、レイアウトプロトコルオブジェクト。 XDRの説明は、それが単純な読者がすぐにコンパイル形式に抽出することを可能にするように、この文書に埋め込まれています。読者はNFSv4.1の機械可読XDR記述を生成するために、次のシェル・スクリプトにこの文書を供給することができるレイアウトプロトコルオブジェクト。
#!/bin/sh grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
ます。＃！/ bin / shのはgrep '^ * ///' $ * | SEDの？^ * /// ?? ' | SEDの？^ * /// $ ?? '
That is, if the above script is stored in a file called "extract.sh", and this document is in a file called "spec.txt", then the reader can do:
上記のスクリプトは、その後、読者が行うことができ、「extract.sh」と呼ばれるファイルに保存されており、この文書は「spec.txt」というファイルになっている場合には、次のとおりです。
sh extract.sh < spec.txt > pnfs_osd_prot.x
SH extract.sh <spec.txt> pnfs_osd_prot.x
The effect of the script is to remove leading white space from each line, plus a sentinel sequence of "///".
スクリプトの効果は、主要な白の各ラインからのスペース、プラス「///」のセンチネル配列を除去することです。
The embedded XDR file header follows. Subsequent XDR descriptions, with the sentinel sequence are embedded throughout the document.
埋め込みXDRファイルヘッダは以下の通りです。センチネル配列とそれに続くXDRの説明は、文書全体に埋め込まれています。
Note that the XDR code contained in this document depends on types from the NFSv4.1 nfs4_prot.x file ([4]). This includes both nfs types that end with a 4, such as offset4, length4, etc., as well as more generic types such as uint32_t and uint64_t.
この文書に含まれるXDRコードがNFSv4.1のnfs4_prot.xファイルの種類（[4]）に依存することに留意されたいです。これは、等OFFSET4、LENGTH4、並びにのuint32_tとuint64_tを、より一般的なタイプとして4で終わるNFSタイプ、の両方を含みます。
The XDR description, marked with lines beginning with the sequence "///", as well as scripts for extracting the XDR description are Code Components as described in Section 4 of "Legal Provisions Relating to IETF Documents" [5]. These Code Components are licensed according to the terms of Section 4 of "Legal Provisions Relating to IETF Documents".
「IETFドキュメントに関連法規定」の第4章で説明したようにシーケンス「///」だけでなく、XDRの記述を抽出するためのスクリプトで始まる行でマークされたXDRの記述は、コードコンポーネントをされている[5]。これらのコードコンポーネントは、「IETFドキュメントに関連法規定」の第4章の条項に従ってライセンスされています。
/// /*
/// * Copyright (c) 2010 IETF Trust and the persons identified
/// * as authors of the code. All rights reserved.
/// *
/// * Redistribution and use in source and binary forms, with
/// * or without modification, are permitted provided that the
/// * following conditions are met:
/// *
/// * o Redistributions of source code must retain the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer.
/// *
/// * o Redistributions in binary form must reproduce the above
/// * copyright notice, this list of conditions and the
/// * following disclaimer in the documentation and/or other
/// * materials provided with the distribution.
/// *
/// * o Neither the name of Internet Society, IETF or IETF
/// * Trust, nor the names of specific contributors, may be
/// * used to endorse or promote products derived from this
/// * software without specific prior written permission.
/// *
/// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
/// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
/// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
/// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
/// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
/// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
/// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
/// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
/// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
/// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
/// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
/// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
/// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
/// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
/// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
/// *
/// * This code was derived from RFC 5664.
/// * Please reproduce this note if possible.
/// */
///
/// /*
/// * pnfs_osd_prot.x
/// */
///
/// %#include <nfs4_prot.x>
///
The following sections define basic data types and constants used by the Object-Based Layout protocol.
以下のセクションでは、オブジェクトベースのレイアウトプロトコルによって使用される基本的なデータ型と定数を定義します。
An object is identified by a number, somewhat like an inode number. The object storage model has a two-level scheme, where the objects within an object storage device are grouped into partitions.
オブジェクトは幾分inode番号のような番号によって識別されます。オブジェクト・ストレージ・モデルは、オブジェクト・ストレージ・デバイス内のオブジェクトをパーティションにグループ化された2つのレベルのスキームを有します。
/// struct pnfs_osd_objid4 {
/// deviceid4 oid_device_id;
/// uint64_t oid_partition_id;
/// uint64_t oid_object_id;
/// };
///
The pnfs_osd_objid4 type is used to identify an object within a partition on a specified object storage device. "oid_device_id" selects the object storage device from the set of available storage devices. The device is identified with the deviceid4 type, which is an index into addressing information about that device returned by the GETDEVICELIST and GETDEVICEINFO operations. The deviceid4 data type is defined in NFSv4.1 [6]. Within an OSD, a partition is identified with a 64-bit number, "oid_partition_id". Within a partition, an object is identified with a 64-bit number, "oid_object_id". Creation and management of partitions is outside the scope of this document, and is a facility provided by the object-based storage file system.
pnfs_osd_objid4型が指定されたオブジェクト・ストレージ・デバイス上のパーティション内のオブジェクトを識別するために使用されます。 「oid_device_id」が使用可能なストレージデバイスのセットからオブジェクト・ストレージ・デバイスを選択します。装置はGETDEVICELISTとGETDEVICEINFO操作によって返され、そのデバイスに関する情報をアドレスへのインデックスであるdeviceid4タイプで識別されます。 deviceid4データ型はNFSv4.1で定義されている[6]。 OSD内、パーティションは、64ビット数、「oid_partition_id」で識別されます。パーティション内で、オブジェクトは、64ビット数、「oid_object_id」で識別されます。パーティションの作成と管理は、この文書の範囲外であり、オブジェクトベースのストレージファイルシステムによって提供される機能です。
/// enum pnfs_osd_version4 { /// PNFS_OSD_MISSING = 0, /// PNFS_OSD_VERSION_1 = 1, /// PNFS_OSD_VERSION_2 = 2 /// }; ///
///列挙pnfs_osd_version4 {/// PNFS_OSD_MISSING = 0、/// PNFS_OSD_VERSION_1 = 1、/// PNFS_OSD_VERSION_2 = 2 ///}。 ///
pnfs_osd_version4 is used to indicate the OSD protocol version or whether an object is missing (i.e., unavailable). Some of the object-based layout-supported RAID algorithms encode redundant information and can compensate for missing components, but the data placement algorithm needs to know what parts are missing.
pnfs_osd_version4は、OSDプロトコルのバージョンを示すために使用されるか、またはオブジェクトが欠落しているかどうか（すなわち、使用不能にされます）。オブジェクトベースのレイアウトがサポートRAIDアルゴリズムのいくつかは、冗長情報を符号化し、不足しているコンポーネントを補償することができるが、データの配置アルゴリズムは、部品が欠けているかを知る必要があります。
At this time, the OSD standard is at version 1.0, and we anticipate a version 2.0 of the standard (SNIA T10/1729-D [14]). The second generation OSD protocol has additional proposed features to support more robust error recovery, snapshots, and byte-range capabilities. Therefore, the OSD version is explicitly called out in the information returned in the layout. (This information can also be deduced by looking inside the capability type at the format field, which is the first byte. The format value is 0x1 for an OSD v1 capability. However, it seems most robust to call out the version explicitly.)
このとき、OSD規格はバージョン1.0であり、そして我々は、標準的な（SNIA T10 / 1729-D [14]）のバージョン2.0を予測します。第二世代のOSDプロトコルは、より強力なエラー回復、スナップショット、およびバイト範囲機能をサポートするための機能を追加提案しました。そのため、OSDのバージョンは、明示的なレイアウトで返された情報に呼び出されます。 （この情報は、最初のバイトであるフォーマットフィールドでの機能タイプ、内側に見ることで推測することができる。フォーマット値はOSD v1の機能のための0x1のです。しかし、明示的にバージョンを呼び出すために最も強力なようです。）
/// enum pnfs_osd_cap_key_sec4 {
/// PNFS_OSD_CAP_KEY_SEC_NONE = 0,
/// PNFS_OSD_CAP_KEY_SEC_SSV = 1
/// };
///
/// struct pnfs_osd_object_cred4 {
/// pnfs_osd_objid4 oc_object_id;
/// pnfs_osd_version4 oc_osd_version;
/// pnfs_osd_cap_key_sec4 oc_cap_key_sec;
/// opaque oc_capability_key<>;
/// opaque oc_capability<>;
/// };
///
The pnfs_osd_object_cred4 structure is used to identify each component comprising the file. The "oc_object_id" identifies the component object, the "oc_osd_version" represents the osd protocol version, or whether that component is unavailable, and the "oc_capability" and "oc_capability_key", along with the "oda_systemid" from the pnfs_osd_deviceaddr4, provide the OSD security credentials needed to access that object. The "oc_cap_key_sec" value denotes the method used to secure the oc_capability_key (see Section 13.1 for more details).
pnfs_osd_object_cred4構造は、ファイルを構成する各コンポーネントを識別するために使用されます。 「oc_object_id」はコンポーネントオブジェクトを識別し、「oc_osd_version」は、OSDプロトコルバージョンを表すか、またはそのコンポーネントが使用できない、とpnfs_osd_deviceaddr4から「oda_systemid」とともに「oc_capability」および「oc_capability_key」かどうか、OSDセキュリティを提供しますそのオブジェクトにアクセスするために必要な資格情報。 「oc_cap_key_sec」値が（詳細は13.1節を参照）oc_capability_keyを確保するために使用する方法を示しています。
To comply with the OSD security requirements, the capability key SHOULD be transferred securely to prevent eavesdropping (see Section 13). Therefore, a client SHOULD either issue the LAYOUTGET or GETDEVICEINFO operations via RPCSEC_GSS with the privacy service or previously establish a secret state verifier (SSV) for the sessions via the NFSv4.1 SET_SSV operation. The pnfs_osd_cap_key_sec4 type is used to identify the method used by the server to secure the capability key.
OSDのセキュリティ要件に準拠するために、機能キー（セクション13を参照）盗聴を防ぐために、安全に転送する必要があります。そのため、クライアントは、プライバシーサービスをRPCSEC_GSS経由LAYOUTGETまたはGETDEVICEINFO操作を発行したり、以前にNFSv4.1 SET_SSV操作によってセッションのための秘密の状態の検証（SSV）を確立する必要がありますどちらか。 pnfs_osd_cap_key_sec4タイプは、機能キーを保護するためにサーバによって使用される方法を識別するために使用されます。
o PNFS_OSD_CAP_KEY_SEC_NONE denotes that the oc_capability_key is not encrypted, in which case the client SHOULD issue the LAYOUTGET or GETDEVICEINFO operations with RPCSEC_GSS with the privacy service or the NFSv4.1 transport should be secured by using methods that are external to NFSv4.1 like the use of IPsec [15] for transporting the NFSV4.1 protocol.
O PNFS_OSD_CAP_KEY_SEC_NONEは、クライアントがプライバシーサービスやNFSv4.1輸送とRPCSEC_GSSとLAYOUTGETまたはGETDEVICEINFO操作は使用などのNFSv4.1の外部にある方法を使用して保護されなければならない発行する必要があり、その場合には、oc_capability_keyが暗号化されていないことを表しNFSV4.1プロトコルを搬送するためのIPsecの[15]。
o PNFS_OSD_CAP_KEY_SEC_SSV denotes that the oc_capability_key contents are encrypted using the SSV GSS context and the capability key as inputs to the GSS_Wrap() function (see GSS-API [7]) with the conf_req_flag set to TRUE. The client MUST use the secret SSV key as part of the client's GSS context to decrypt the capability key using the value of the oc_capability_key field as the input_message to the GSS_unwrap() function. Note that to prevent eavesdropping of the SSV key, the client SHOULD issue SET_SSV via RPCSEC_GSS with the privacy service.
O PNFS_OSD_CAP_KEY_SEC_SSVはoc_capability_key内容SSV GSSコンテキストとにGSS_Wrap（）関数への入力として機能キーを用いて暗号化されることを示す（GSS-APIを参照し[7]）TRUEに設定conf_req_flag有します。クライアントははgss_unwrap（）関数にinput_messageとしてoc_capability_keyフィールドの値を使用して機能キーを解読するために、クライアントのGSSコンテキストの一部として秘密SSVキーを使用しなければなりません。 SSVキーの盗聴を防ぐために、なお、クライアントは、プライバシーサービスをRPCSEC_GSS経由SET_SSVを発行する必要があります。
The actual method chosen depends on whether the client established a SSV key with the server and whether it issued the operation with the RPCSEC_GSS privacy method. Naturally, if the client did not establish an SSV key via SET_SSV, the server MUST use the PNFS_OSD_CAP_KEY_SEC_NONE method. Otherwise, if the operation was not issued with the RPCSEC_GSS privacy method, the server SHOULD secure the oc_capability_key with the PNFS_OSD_CAP_KEY_SEC_SSV method. The server MAY use the PNFS_OSD_CAP_KEY_SEC_SSV method also when the operation was issued with the RPCSEC_GSS privacy method.
選ばれた実際の方法は、クライアントがサーバーとSSVキーを確立しているかどうかに依存し、それはRPCSEC_GSSプライバシー法と操作を発行したかどうか。クライアントがSET_SSV経由SSVキーを確立していない場合は当然、サーバーはPNFS_OSD_CAP_KEY_SEC_NONEメソッドを使用する必要があります。操作はRPCSEC_GSSプライバシー法で発行されていなかった場合はそうでない場合は、サーバーはPNFS_OSD_CAP_KEY_SEC_SSV方法でoc_capability_keyを確保すべきです。操作はRPCSEC_GSSプライバシー法で発行されたときにサーバーにもPNFS_OSD_CAP_KEY_SEC_SSVメソッドを使用するかもしれません。
/// enum pnfs_osd_raid_algorithm4 {
/// PNFS_OSD_RAID_0 = 1,
/// PNFS_OSD_RAID_4 = 2,
/// PNFS_OSD_RAID_5 = 3,
/// PNFS_OSD_RAID_PQ = 4 /* Reed-Solomon P+Q */
/// };
///
pnfs_osd_raid_algorithm4 represents the data redundancy algorithm used to protect the file's contents. See Section 5.4 for more details.
pnfs_osd_raid_algorithm4は、ファイルの内容を保護するために使用されるデータの冗長性アルゴリズムを表します。詳細は、5.4節を参照してください。
Data operations to an OSD require the client to know the "address" of each OSD's root object. The root object is synonymous with the Small Computer System Interface (SCSI) logical unit. The client specifies SCSI logical units to its SCSI protocol stack using a representation local to the client. Because these representations are local, GETDEVICEINFO must return information that can be used by the client to select the correct local representation.
OSDへのデータの操作は、各OSDのルートオブジェクトの「アドレス」を知っているクライアントが必要です。ルートオブジェクトはSCSI（Small Computer System Interface）の論理ユニットと同義です。クライアントは、クライアントのローカルな表現を使用して、そのSCSIプロトコルスタックにSCSI論理ユニットを指定します。これらの表現はローカルなので、GETDEVICEINFOは正しいローカルな表現を選択するために、クライアントで使用できる情報を返す必要があります。
In the block world, a set offset (logical block number or track/ sector) contains a disk label. This label identifies the disk uniquely. In contrast, an OSD has a standard set of attributes on its root object. For device identification purposes, the OSD System ID (root information attribute number 3) and the OSD Name (root information attribute number 9) are used as the label. These appear in the pnfs_osd_deviceaddr4 type below under the "oda_systemid" and "oda_osdname" fields.
ブロックの世界では、オフセットのセット（論理ブロック番号やトラック/セクタ）は、ディスクのラベルが含まれています。このラベルは一意にディスクを識別します。これとは対照的に、OSDは、そのルートオブジェクトの属性の標準セットを持っています。デバイス識別目的のために、OSDシステムIDとラベルとして使用されているOSD名（ルート情報番号9属性）（ルート情報番号3属性）。これらは、「oda_systemid」と「oda_osdname」フィールドの下に、以下のpnfs_osd_deviceaddr4タイプに表示されます。
In some situations, SCSI target discovery may need to be driven based on information contained in the GETDEVICEINFO response. One example of this is Internet SCSI (iSCSI) targets that are not known to the client until a layout has been requested. The information provided as the "oda_targetid", "oda_targetaddr", and "oda_lun" fields in the pnfs_osd_deviceaddr4 type described below (see Section 4.2) allows the client to probe a specific device given its network address and optionally its iSCSI Name (see iSCSI [8]), or when the device network address is omitted, allows it to discover the object storage device using the provided device name or SCSI Device Identifier (see SPC-3 [9].)
いくつかの状況では、SCSIターゲット検出はGETDEVICEINFO応答に含まれる情報に基づいて駆動する必要があるかもしれません。この一例は、レイアウトが要求されるまで、クライアントに知られていないインターネットSCSI（iSCSIの）目標です。 「oda_targetid」、「oda_targetaddr」として提供された情報、及び後述pnfs_osd_deviceaddr4タイプの「oda_lun」フィールド（セクション4.2を参照）は、クライアントがそのネットワークアドレスと、任意にそのiSCSIネーム（iSCSIの参照[与えられた特定のデバイスをプローブすることができ8]）、またはデバイスのネットワークアドレスが省略された場合、それが設けられたデバイス名またはSCSIデバイス識別子を使用して、オブジェクト・ストレージ・デバイスを発見することを可能にする（[9] SPC-3を参照）。
The oda_systemid is implicitly used by the client, by using the object credential signing key to sign each request with the request integrity check value. This method protects the client from unintentionally accessing a device if the device address mapping was changed (or revoked). The server computes the capability key using its own view of the systemid associated with the respective deviceid present in the credential. If the client's view of the deviceid mapping is stale, the client will use the wrong systemid (which must be system-wide unique) and the I/O request to the OSD will fail to pass the integrity check verification.
oda_systemidは、暗黙的に要求の整合性チェック値を持つ各要求に署名するオブジェクトの資格署名キーを使用して、クライアントによって使用されます。この方法では、意図せずに、デバイスアドレスのマッピングを変更（または取り消さ）された場合に、デバイスへのアクセスからクライアントを保護します。サーバは、資格の各デバイスIDの存在と関連するSYSTEMIDの独自のビューを使用して機能キーを計算します。デバイスIDマッピングのクライアントのビューが古くなっている場合、クライアントは、整合性チェックの検証を渡すために失敗します（システム全体で一意である必要があります）間違っSYSTEMIDとOSDへのI / O要求を使用します。
To recover from this condition the client should report the error and return the layout using LAYOUTRETURN, and invalidate all the device address mappings associated with this layout. The client can then ask for a new layout if it wishes using LAYOUTGET and resolve the referenced deviceids using GETDEVICEINFO or GETDEVICELIST.
この状態から回復するには、クライアントはエラーを報告し、LAYOUTRETURNを使用してレイアウトを返し、このレイアウトに関連付けられているすべてのデバイスアドレスのマッピングを無効にする必要があります。クライアントは、それが望む場合LAYOUTGETを使用して、新しいレイアウトを求めるとGETDEVICEINFOまたはGETDEVICELISTを使用して参照deviceidsを解決することができます。
The server MUST provide the oda_systemid and SHOULD also provide the oda_osdname. When the OSD name is present, the client SHOULD get the root information attributes whenever it establishes communication with the OSD and verify that the OSD name it got from the OSD matches the one sent by the metadata server. To do so, the client uses the root_obj_cred credentials.
サーバーはoda_systemidを提供しなければならないし、またoda_osdnameを提供する必要があります。 OSD名が存在する場合、クライアントはOSDとの通信を確立するたびに、ルート情報の属性を取得し、それはOSDから得たOSD名はメタデータサーバーから送信されたものと一致することを確認する必要があります。そのためには、クライアントがroot_obj_cred資格情報を使用しています。
The following enum specifies the manner in which a SCSI target can be specified. The target can be specified as a SCSI Name, or as an SCSI Device Identifier.
以下の列挙は、SCSIターゲットを指定することができる方法を指定します。ターゲットは、SCSI名として、またはSCSIデバイス識別子として指定することができます。
/// enum pnfs_osd_targetid_type4 { /// OBJ_TARGET_ANON = 1, /// OBJ_TARGET_SCSI_NAME = 2, /// OBJ_TARGET_SCSI_DEVICE_ID = 3 /// }; ///
///列挙pnfs_osd_targetid_type4 {/// OBJ_TARGET_ANON = 1、/// OBJ_TARGET_SCSI_NAME = 2、/// OBJ_TARGET_SCSI_DEVICE_ID = 3 ///}。 ///
The specification for an object device address is as follows:
次のように対象デバイスアドレスの仕様は次のとおりです。
/// union pnfs_osd_targetid4 switch (pnfs_osd_targetid_type4 oti_type) {
/// case OBJ_TARGET_SCSI_NAME:
/// string oti_scsi_name<>;
///
/// case OBJ_TARGET_SCSI_DEVICE_ID:
/// opaque oti_scsi_device_id<>;
///
/// default:
/// void;
/// };
///
/// union pnfs_osd_targetaddr4 switch (bool ota_available) {
/// case TRUE:
/// netaddr4 ota_netaddr;
/// case FALSE:
/// void;
/// };
///
/// struct pnfs_osd_deviceaddr4 {
/// pnfs_osd_targetid4 oda_targetid;
/// pnfs_osd_targetaddr4 oda_targetaddr;
/// opaque oda_lun[8];
/// opaque oda_systemid<>;
/// pnfs_osd_object_cred4 oda_root_obj_cred;
/// opaque oda_osdname<>;
/// };
///
When "oda_targetid" is specified as an OBJ_TARGET_SCSI_NAME, the "oti_scsi_name" string MUST be formatted as an "iSCSI Name" as specified in iSCSI [8] and [10]. Note that the specification of the oti_scsi_name string format is outside the scope of this document. Parsing the string is based on the string prefix, e.g., "iqn.", "eui.", or "naa." and more formats MAY be specified in the future in accordance with iSCSI Names properties.
「oda_targetid」はOBJ_TARGET_SCSI_NAMEとして指定された場合のiSCSIで指定されるように、「oti_scsi_name」string「はiSCSI名」としてフォーマットされている必要があり[8]、[10]。 oti_scsi_name文字列形式の仕様はこの文書の範囲外であることに留意されたいです。文字列を解析することは、例えば、「IQN。」、「EUI。」、または文字列のプレフィックスに基づいて「NAA。」そしてより多くのフォーマットは、iSCSI名の性質に応じて、将来的に指定することができます。
Currently, the iSCSI Name provides for naming the target device using a string formatted as an iSCSI Qualified Name (IQN) or as an Extended Unique Identifier (EUI) [11] string. Those are typically used to identify iSCSI or Secure Routing Protocol (SRP) [16] devices. The Network Address Authority (NAA) string format (see [10]) provides for naming the device using globally unique identifiers, as defined in Fibre Channel Framing and Signaling (FC-FS) [17]. These are typically used to identify Fibre Channel or SAS [18] (Serial Attached SCSI) devices. In particular, such devices that are dual-attached both over Fibre Channel or SAS and over iSCSI.
現在、iSCSI名は、iSCSI修飾名（IQN）または拡張固有識別子（EUI）[11]文字列としてフォーマットされた文字列を使用して、ターゲットデバイスに名前を付けるために提供します。それらは、典型的には、iSCSIを同定またはルーティングプロトコル（SRP）[16]デバイスを固定するために使用されます。ネットワークアドレス権限（NAA）は、文字列の形式は、ファイバチャネルフレーミングおよびシグナリング（FC-FS）で定義されるように、グローバルに一意の識別子を使用してデバイスの命名を提供する[17]（[10]参照します）。これらは、典型的には、ファイバチャネルまたはSAS [18]（シリアル接続SCSI）デバイスを識別するために使用されます。具体的には、ファイバチャネルまたはSAS上およびiSCSI上の両方のデュアル取り付けられているような装置。
When "oda_targetid" is specified as an OBJ_TARGET_SCSI_DEVICE_ID, the "oti_scsi_device_id" opaque field MUST be formatted as a SCSI Device Identifier as defined in SPC-3 [9] VPD Page 83h (Section 7.6.3. "Device Identification VPD Page"). If the Device Identifier is identical to the OSD System ID, as given by oda_systemid, the server SHOULD provide a zero-length oti_scsi_device_id opaque value. Note that similarly to the "oti_scsi_name", the specification of the oti_scsi_device_id opaque contents is outside the scope of this document and more formats MAY be specified in the future in accordance with SPC-3.
「oda_targetid」はOBJ_TARGET_SCSI_DEVICE_IDとして指定された場合SPC-3で定義されるように、「oti_scsi_device_id」不透明なフィールドは、SCSIデバイス識別子としてフォーマットする必要があり[9] VPDページ83H（セクション7.6.3。「デバイス識別VPDページ」）。デバイス識別子は、OSDシステムIDと同一である場合、oda_systemidによって与えられるように、サーバは、長さゼロoti_scsi_device_id不透明な値を提供すべきです。同様に、「oti_scsi_name」に、oti_scsi_device_id不透明コンテンツの仕様はこの文書の範囲外であり、より多くのフォーマットは、SPC-3に従って、将来に指定されてもよいことに留意されたいです。
The OBJ_TARGET_ANON pnfs_osd_targetid_type4 MAY be used for providing no target identification. In this case, only the OSD System ID, and optionally the provided network address, are used to locate the device.
OBJ_TARGET_ANON pnfs_osd_targetid_type4には、目標識別を提供しないために使用されるかもしれません。この場合、唯一のOSDシステムID、および必要に応じて設けられたネットワークアドレスは、デバイスの位置を特定するために使用されます。
The optional "oda_targetaddr" field MAY be provided by the server as a hint to accelerate device discovery over, e.g., the iSCSI transport protocol. The network address is given with the netaddr4 type, which specifies a TCP/IP based endpoint (as specified in NFSv4.1 [6]). When given, the client SHOULD use it to probe for the SCSI device at the given network address. The client MAY still use other discovery mechanisms such as Internet Storage Name Service (iSNS) [12] to locate the device using the oda_targetid. In particular, such an external name service SHOULD be used when the devices may be attached to the network using multiple connections, and/or multiple storage fabrics (e.g., Fibre-Channel and iSCSI).
オプションの「oda_targetaddr」フィールドは、例えば、上のiSCSIトランスポートプロトコルをデバイス発見を加速するヒントとして、サーバによって提供されてもよいです。ネットワークアドレスは、TCP / IPベースのエンドポイントを指定netaddr4タイプ、で与えられる（NFSv4.1で指定されるように[6]）。与えられたとき、クライアントは、特定のネットワークアドレスでSCSIデバイスをプローブするためにそれを使用する必要があります。クライアントはまだoda_targetidを使用してデバイスの位置を特定するために、このようなインターネットストレージネームサービス（iSNS）[12]などの他の検出メカニズムを使用するかもしれません。特に、装置は、複数の接続を使用してネットワークに接続することができる場合、そのような外部のネームサービスが使用されるべき、および/または複数のストレージファブリック（たとえば、ファイバ・チャネルおよびiSCSI）。
The "oda_lun" field identifies the OSD 64-bit Logical Unit Number, formatted in accordance with SAM-3 [13]. The client uses the Logical Unit Number to communicate with the specific OSD Logical Unit. Its use is defined in detail by the SCSI transport protocol, e.g., iSCSI [8].
「oda_lun」フィールドは、SAM-3 [13]に従ってフォーマットOSD 64ビット論理ユニット番号を識別する。クライアントは、特定のOSD論理ユニットと通信するための論理ユニット番号を使用しています。その使用は、SCSIトランスポートプロトコル、例えば、iSCSIの[8]で詳細に定義されています。
The layout4 type is defined in the NFSv4.1 [6] as follows:
layout4タイプはNFSv4.1で定義されている[6]を次のように
enum layouttype4 { LAYOUT4_NFSV4_1_FILES = 1, LAYOUT4_OSD2_OBJECTS = 2, LAYOUT4_BLOCK_VOLUME = 3 };
列挙layouttype4 {LAYOUT4_NFSV4_1_FILES = 1、LAYOUT4_OSD2_OBJECTS = 2、LAYOUT4_BLOCK_VOLUME = 3}。
struct layout_content4 {
layouttype4 loc_type;
opaque loc_body<>;
};
struct layout4 {
offset4 lo_offset;
length4 lo_length;
layoutiomode4 lo_iomode;
layout_content4 lo_content;
};
This document defines structure associated with the layouttype4 value, LAYOUT4_OSD2_OBJECTS. The NFSv4.1 [6] specifies the loc_body structure as an XDR type "opaque". The opaque layout is uninterpreted by the generic pNFS client layers, but obviously must be interpreted by the object storage layout driver. This section defines the structure of this opaque value, pnfs_osd_layout4.
この文書はlayouttype4値、LAYOUT4_OSD2_OBJECTSに関連付けられた構造を定義します。 NFSv4.1 [6]「不透明」XDRタイプとしてloc_body構造を指定します。不透明なレイアウトは、汎用のpNFSクライアント層に解釈されることなくされているが、明らかにオブジェクトストレージレイアウトドライバによって解釈されなければなりません。このセクションではpnfs_osd_layout4、この不透明な値の構造を定義します。
/// struct pnfs_osd_data_map4 {
/// uint32_t odm_num_comps;
/// length4 odm_stripe_unit;
/// uint32_t odm_group_width;
/// uint32_t odm_group_depth;
/// uint32_t odm_mirror_cnt;
/// pnfs_osd_raid_algorithm4 odm_raid_algorithm;
/// };
///
The pnfs_osd_data_map4 structure parameterizes the algorithm that maps a file's contents over the component objects. Instead of limiting the system to simple striping scheme where loss of a single component object results in data loss, the map parameters support mirroring and more complicated schemes that protect against loss of a component object.
pnfs_osd_data_map4構造は、コンポーネントオブジェクト上でファイルの内容をマップするアルゴリズムをパラメータ化。代わりに、データ損失の単一コンポーネントオブジェクト結果の損失は、地図のパラメータはコンポーネントオブジェクトの損失を防ぐミラー化より複雑なスキームをサポートする単純なストライピング方式にシステムを制限します。
"odm_num_comps" is the number of component objects the file is striped over. The server MAY grow the file by adding more components to the stripe while clients hold valid layouts until the file has reached its final stripe width. The file length in this case MUST be limited to the number of bytes in a full stripe.
「odm_num_comps」コンポーネントの数は、ファイルがオーバーストライピングされるオブジェクトです。サーバーは、ファイルがその最終的なストライプ幅に到達するまで、クライアントが有効なレイアウトを保持しながら、ストライプに複数の部品を追加することで、ファイルを成長します。この場合、ファイルの長さは、完全なストライプのバイト数に制限されなければなりません。
The "odm_stripe_unit" is the number of bytes placed on one component before advancing to the next one in the list of components. The number of bytes in a full stripe is odm_stripe_unit times the number of components. In some RAID schemes, a stripe includes redundant information (i.e., parity) that lets the system recover from loss or damage to a component object.
「odm_stripe_unit」はコンポーネントのリスト内の次のいずれかに進める前に、一つの成分上に配置されたバイト数です。完全なストライプのバイト数は、コンポーネントのodm_stripe_unit倍の数です。いくつかのRAID方式において、ストライプは、システムは、コンポーネントオブジェクトに損失または損傷から回復することができ、冗長な情報（すなわち、パリティ）を含みます。
The "odm_group_width" and "odm_group_depth" parameters allow a nested striping pattern (see Section 5.3.2 for details). If there is no nesting, then odm_group_width and odm_group_depth MUST be zero. The size of the components array MUST be a multiple of odm_group_width.
「odm_group_width」と「odm_group_depth」パラメータは、ネストされたストライプパターンを（詳細は5.3.2項を参照）を可能にします。何のネスティングがない場合、odm_group_widthとodm_group_depthはゼロでなければなりません。 components配列の大きさはodm_group_widthの倍数でなければなりません。
The "odm_mirror_cnt" is used to replicate a file by replicating its component objects. If there is no mirroring, then odm_mirror_cnt MUST be 0. If odm_mirror_cnt is greater than zero, then the size of the component array MUST be a multiple of (odm_mirror_cnt+1).
「odm_mirror_cnt」は、そのコンポーネントのオブジェクトを複製することにより、ファイルを複製するために使用されます。何ミラーリングがない場合、odm_mirror_cntは0でなければなりませんodm_mirror_cntがゼロより大きい場合、成分アレイのサイズは、（odm_mirror_cnt + 1）の倍数でなければなりません。
See Section 5.3 for more details.
詳細は、5.3節を参照してください。
/// struct pnfs_osd_layout4 {
/// pnfs_osd_data_map4 olo_map;
/// uint32_t olo_comps_index;
/// pnfs_osd_object_cred4 olo_components<>;
/// };
///
The pnfs_osd_layout4 structure specifies a layout over a set of component objects. The "olo_components" field is an array of object identifiers and security credentials that grant access to each object. The organization of the data is defined by the pnfs_osd_data_map4 type that specifies how the file's data is mapped onto the component objects (i.e., the striping pattern). The data placement algorithm that maps file data onto component objects assumes that each component object occurs exactly once in the array of components. Therefore, component objects MUST appear in the olo_components array only once. The components array may represent all objects comprising the file, in which case "olo_comps_index" is set to zero and the number of entries in the olo_components array is equal to olo_map.odm_num_comps. The server MAY return fewer components than odm_num_comps, provided that the returned components are sufficient to access any byte in the layout's data range (e.g., a sub-stripe of "odm_group_width" components). In this case, olo_comps_index represents the position of the returned components array within the full array of components that comprise the file.
pnfs_osd_layout4構造は、コンポーネントオブジェクトのセットにわたってレイアウトを指定します。 「olo_components」フィールドには、オブジェクト識別子と、各オブジェクトへのアクセスを許可するセキュリティ資格情報の配列です。データの編成は、ファイルのデータがコンポーネントオブジェクト（すなわち、ストライピングパターン）にマッピングされる方法を指定pnfs_osd_data_map4タイプによって定義されます。コンポーネントオブジェクトにファイルのデータをマップデータ配置アルゴリズムは、各コンポーネントオブジェクトは、コンポーネントの配列に正確に一度発生すると仮定しています。したがって、コンポーネントオブジェクトは一度だけolo_componentsアレイに現れなければなりません。成分アレイ「olo_comps_index」がゼロに設定され、olo_componentsアレイ内のエントリの数がolo_map.odm_num_compsに等しいされた場合にファイルを含むすべてのオブジェクトを表すことができます。サーバはodm_num_compsより少ない構成要素を戻り、戻ったコンポーネントは、レイアウトのデータ範囲（例えば、「odm_group_width」成分のサブストライプ）の任意のバイトにアクセスするのに十分であることを条件とします。この場合、olo_comps_indexは、ファイルを構成するコンポーネントの完全なアレイ内の返された構成要素アレイの位置を表します。
Note that the layout depends on the file size, which the client learns from the generic return parameters of LAYOUTGET, by doing GETATTR commands to the metadata server. The client uses the file size to decide if it should fill holes with zeros or return a short read. Striping patterns can cause cases where component objects are shorter than other components because a hole happens to correspond to the last part of the component object.
レイアウトは、クライアントがGETATTRは、メタデータ・サーバにコマンドを実行して、LAYOUTGETの一般的なリターン・パラメータから学習し、ファイルサイズ、に依存することに注意してください。クライアントは、それがゼロで穴を埋めるか、短い読み込みを返すべきかどうかを判断するために、ファイルのサイズを使用しています。ストライピングパターンは穴がコンポーネントオブジェクトの最後の部分に対応して起こるので、コンポーネントオブジェクトが他の成分よりも短い場合を引き起こす可能性があります。
This section describes the different data mapping schemes in detail. The object layout always uses a "dense" layout as described in NFSv4.1 [6]. This means that the second stripe unit of the file starts at offset 0 of the second component, rather than at offset stripe_unit bytes. After a full stripe has been written, the next stripe unit is appended to the first component object in the list without any holes in the component objects.
このセクションでは、詳細に異なるデータマッピング方式を説明しています。 NFSv4.1 [6]に記載のようにオブジェクトのレイアウトは、常に「密」レイアウトを使用します。これは、ファイルの第2のストライプ部はstripe_unitバイトオフセットむしろよりも、第二の成分のオフセット0から始まることを意味します。完全なストライプが書き込まれた後、次のストライプ部は、コンポーネントオブジェクト内の任意の穴なしで、リスト内の最初のコンポーネントオブジェクトに添付されています。
The mapping from the logical offset within a file (L) to the component object C and object-specific offset O is defined by the following equations:
論理からのマッピングは、コンポーネントオブジェクトCへのファイル（L）内のオフセット及びオブジェクト固有のOは、次式によって定義されるオフセット
L = logical offset into the file W = total number of components S = W * stripe_unit N = L / S C = (L-(N*S)) / stripe_unit O = (N*stripe_unit)+(L%stripe_unit)
L =論理ファイル・W =成分S = Wの*のstripe_unit N = L / S C =（1-（N * S））/ stripe_unit O =（N * stripe_unit）+（1％のstripe_unit）の総数にオフセット
In these equations, S is the number of bytes in a full stripe, and N is the stripe number. C is an index into the array of components, so it selects a particular object storage device. Both N and C count from zero. O is the offset within the object that corresponds to the file offset. Note that this computation does not accommodate the same object appearing in the olo_components array multiple times.
これらの式において、Sは、完全なストライプのバイト数であり、Nは、ストライプ番号です。 Cは、部品の配列へのインデックスであるので、特定のオブジェクト・ストレージ・デバイスを選択します。 NとCの両方がゼロからカウント。 Oは、ファイルオフセットに対応するオブジェクト内のオフセットされます。この計算は、olo_componentsアレイ内で複数回出現する同じオブジェクトに対応しないことに注意してください。
For example, consider an object striped over four devices, <D0 D1 D2 D3>. The stripe_unit is 4096 bytes. The stripe width S is thus 4 * 4096 = 16384.
例えば、4つのデバイス、<D0 D1 D2 D3>上にストライプオブジェクトを考えます。 stripe_unitは4096バイトです。ストライプ幅Sは、このように4×4096 = 16384です。
Offset 0: N = 0 / 16384 = 0 C = 0-0/4096 = 0 (D0) O = 0*4096 + (0%4096) = 0
オフセット0：N = 0/16384 = 0 C = 0-0 / 4096 = 0（D0）O = 0 * 4096 +（0％4096）= 0
Offset 4096: N = 4096 / 16384 = 0 C = (4096-(0*16384)) / 4096 = 1 (D1) O = (0*4096)+(4096%4096) = 0
4096オフセット：N = 4096/16384 = 0 C =（4096-（0 * 16384））/ 4096 = 1（D1）O =（* 4096 0）+（4096 4096％）= 0
Offset 9000: N = 9000 / 16384 = 0 C = (9000-(0*16384)) / 4096 = 2 (D2) O = (0*4096)+(9000%4096) = 808
9000オフセット：N = 9000/16384 = 0 C =（9000-（0 * 16384））/ 4096 = 2（D2）O =（* 4096 0）+（9000パーセント4096）= 808
Offset 132000: N = 132000 / 16384 = 8 C = (132000-(8*16384)) / 4096 = 0 (D0) O = (8*4096) + (132000%4096) = 33696
オフセット132000：N = 132000/16384 = 8 C =（132000-（8 * 16384））/ 4096 = 0（D0）O =（* 4096 8）+（13.2万%4096）= 33696
The odm_group_width and odm_group_depth parameters allow a nested striping pattern. odm_group_width defines the width of a data stripe and odm_group_depth defines how many stripes are written before advancing to the next group of components in the list of component objects for the file. The math used to map from a file offset to a component object and offset within that object is shown below. The computations map from the logical offset L to the component index C and offset relative O within that component object.
odm_group_widthとodm_group_depthパラメータは、ネストされたストライプパターンを可能にします。 odm_group_widthはデータストライプの幅を定義し、odm_group_depthは、ファイルのコンポーネントオブジェクトのリスト内のコンポーネントの次のグループに進む前に書かれているどのように多くのストライプ定義します。そのオブジェクト内のコンポーネントオブジェクトにオフセット及びオフセットファイルからマッピングするために使用される数学は以下に示されています。成分指数Cへの論理オフセットLから演算マップとは、そのコンポーネント・オブジェクト内の相対Oオフセット。
L = logical offset into the file W = total number of components S = stripe_unit * group_depth * W T = stripe_unit * group_depth * group_width U = stripe_unit * group_width M = L / S G = (L - (M * S)) / T H = (L - (M * S)) % T N = H / U C = (H - (N * U)) / stripe_unit + G * group_width O = L % stripe_unit + N * stripe_unit + M * group_depth * stripe_unit
L =論理ファイルWにオフセット=コンポーネントの総数Sの= stripe_unit * group_depth * WT = stripe_unit * group_depth * group_width U = stripe_unit * group_width M = L / SG =（L - （M * S））/ TH =（ L - （M * S））％のTN = H / UC =（H - （N * U））/ stripe_unit + G * group_width O = 1％のstripe_unit + N * stripe_unit + M *のgroup_depth * stripe_unit
In these equations, S is the number of bytes striped across all component objects before the pattern repeats. T is the number of bytes striped within a group of component objects before advancing to the next group. U is the number of bytes in a stripe within a group. M is the "major" (i.e., across all components) stripe number, and N is the "minor" (i.e., across the group) stripe number. G counts the groups from the beginning of the major stripe, and H is the byte offset within the group.
これらの式において、Sは、パターンを繰り返す前に、すべてのコンポーネントオブジェクトにわたってストライプのバイト数です。 Tは、次のグループに進む前に、コンポーネントオブジェクトのグループ内のストライプのバイト数です。 Uは、グループ内のストライプのバイト数です。 Mは、「主要な」（すなわち、すべてのコンポーネント間の）ストライプの数であり、Nは「マイナー」（すなわち、グループ全体）ストライプ番号です。 Gは、主要なストライプの最初からグループをカウントし、そしてHは、グループ内でのバイトオフセットです。
For example, consider an object striped over 100 devices with a group_width of 10, a group_depth of 50, and a stripe_unit of 1 MB. In this scheme, 500 MB are written to the first 10 components, and 5000 MB are written before the pattern wraps back around to the first component in the array.
例えば、10のgroup_width、50のgroup_depth、および1メガバイトのstripe_unit 100台のデバイス上にストライプオブジェクトを考えます。この方式では、500メガバイトは、第10の構成要素に書き込まれ、そしてパターンは、アレイ中の第1成分程度バックラップの前に5000メガバイトが書かれています。
Offset 0: W = 100 S = 1 MB * 50 * 100 = 5000 MB T = 1 MB * 50 * 10 = 500 MB U = 1 MB * 10 = 10 MB M = 0 / 5000 MB = 0 G = (0 - (0 * 5000 MB)) / 500 MB = 0 H = (0 - (0 * 5000 MB)) % 500 MB = 0 N = 0 / 10 MB = 0 C = (0 - (0 * 10 MB)) / 1 MB + 0 * 10 = 0 O = 0 % 1 MB + 0 * 1 MB + 0 * 50 * 1 MB = 0
W = 100、S = 1のMB * 50 * 100 = 5000メガバイトT = 1 MB * 50 * 10 = 500 MB U = 1 MB * 10 = 10 MB M = 0/5000 MB = 0、G =（ - 0：0をオフセット（* 5000 0 MB））/ 500メガバイト= 0 H =（0 - （* 5000 0 MB））500％MB = 0 N = 0/10 MB = 0 C =（0 - （0×10 MB））/ 1メガバイト* 10 + 0 = 0 = 0％O 1メガバイト+ 0 * 1メガバイト+ 0 * 50 * 1メガバイト= 0
Offset 27 MB: M = 27 MB / 5000 MB = 0 G = (27 MB - (0 * 5000 MB)) / 500 MB = 0 H = (27 MB - (0 * 5000 MB)) % 500 MB = 27 MB N = 27 MB / 10 MB = 2 C = (27 MB - (2 * 10 MB)) / 1 MB + 0 * 10 = 7 O = 27 MB % 1 MB + 2 * 1 MB + 0 * 50 * 1 MB = 2 MB
（ - （0 * 5000メガバイト）27とMB）/ 500メガバイト= 0 H =（28 MB - （0 * 5000メガバイト））％500メガバイト= 27メガバイトM = 27 MB / 5000メガバイト= 0、G = 27 MBのオフセットN = 27 MB / 10メガバイト= 2 C =（28 MB - （2×10 MB））/ 1メガバイト+ 0×10 = 7 O = 27メガバイト％1メガバイト+ 2 * 1メガバイト+ 0 * 50 * 1メガバイト= 2メガバイト
Offset 7232 MB: M = 7232 MB / 5000 MB = 1 G = (7232 MB - (1 * 5000 MB)) / 500 MB = 4 H = (7232 MB - (1 * 5000 MB)) % 500 MB = 232 MB N = 232 MB / 10 MB = 23 C = (232 MB - (23 * 10 MB)) / 1 MB + 4 * 10 = 42 O = 7232 MB % 1 MB + 23 * 1 MB + 1 * 50 * 1 MB = 73 MB
7232メガバイトオフセット： - / 500メガバイト= 4 H =（7232メガバイト - （1 * 5000メガバイト））M = 7232メガバイト/ 5000メガバイト= 1 G =（（1 * 5000メガバイト）7232メガバイト）％を500メガバイト= 232メガバイトN = 232メガバイト/ 10メガバイト= 23 C =（232メガバイト - （23×10 MB））/ 1メガバイト+ 4 * 10 = 42 O = 7232メガバイト％の1メガバイト+ 23 * 1 MBは+ 1 * 50 * 1メガバイト= 73メガバイト
The odm_mirror_cnt is used to replicate a file by replicating its component objects. If there is no mirroring, then odm_mirror_cnt MUST be 0. If odm_mirror_cnt is greater than zero, then the size of the olo_components array MUST be a multiple of (odm_mirror_cnt+1). Thus, for a classic mirror on two objects, odm_mirror_cnt is one. Note that mirroring can be defined over any RAID algorithm and striping pattern (either simple or nested). If odm_group_width is also non-zero, then the size of the olo_components array MUST be a multiple of odm_group_width * (odm_mirror_cnt+1). Replicas are adjacent in the olo_components array, and the value C produced by the above equations is not a direct index into the olo_components array. Instead, the following equations determine the replica component index RCi, where i ranges from 0 to odm_mirror_cnt.
odm_mirror_cntは、そのコンポーネントのオブジェクトを複製することにより、ファイルを複製するために使用されます。何ミラーリングがない場合、odm_mirror_cntは0でなければなりませんodm_mirror_cntがゼロより大きい場合、olo_componentsアレイのサイズは、（odm_mirror_cnt + 1）の倍数でなければなりません。このように、二つのオブジェクト上の古典的なミラーのために、odm_mirror_cntは1です。ミラーリングは、任意のRAIDアルゴリズム及び（単純またはネストされたいずれか）ストライピングパターン上に定義することができることに留意されたいです。 odm_group_widthも非ゼロである場合、olo_componentsアレイのサイズはodm_group_width *（odm_mirror_cnt + 1）の倍数でなければなりません。レプリカはolo_componentsアレイに隣接しており、上記式によって生成される値Cはolo_components配列への直接指標ではありません。その代わりに、以下の式は、iは0からodm_mirror_cntの範囲レプリカ成分インデックスRCiとを決定します。
C = component index for striping or two-level striping i ranges from 0 to odm_mirror_cnt, inclusive RCi = C * (odm_mirror_cnt+1) + i
ストライピングまたは二レベルのストライピングのためのC =成分インデックスiは0からodm_mirror_cntの範囲、包括RCiが= C×（odm_mirror_cnt + 1）+ I
pnfs_osd_raid_algorithm4 determines the algorithm and placement of redundant data. This section defines the different redundancy algorithms. Note: The term "RAID" (Redundant Array of Independent Disks) is used in this document to represent an array of component objects that store data for an individual file. The objects are stored on independent object-based storage devices. File data is encoded and striped across the array of component objects using algorithms developed for block-based RAID systems.
pnfs_osd_raid_algorithm4は、冗長データのアルゴリズムと配置を決定します。このセクションでは、異なる冗長性アルゴリズムを定義します。注：用語「RAID」（独立ディスクの冗長アレイ）は、個々のファイルのデータを格納するコンポーネントオブジェクトの配列を表すために本書で使用されています。目的は、独立オブジェクトベースのストレージデバイスに格納されています。ファイルデータは、符号化とブロックベースのRAIDシステム用に開発されたアルゴリズムを使用してコンポーネントオブジェクトのアレイにわたってストライピングされます。
PNFS_OSD_RAID_0 means there is no parity data, so all bytes in the component objects are data bytes located by the above equations for C and O. If a component object is marked as PNFS_OSD_MISSING, the pNFS client MUST either return an I/O error if this component is attempted to be read or, alternatively, it can retry the READ against the pNFS server.
PNFS_OSD_RAID_0にはパリティデータがないことを意味し、コンポーネントオブジェクトのすべてのバイトは、コンポーネントオブジェクトがPNFS_OSD_MISSINGとしてマークされている場合、CおよびOのための上記の式で配置されたデータ・バイトであるこの場合ので、pNFSのクライアントは、I / Oエラーを返さなければならないのいずれかでコンポーネントは、代替的には、pNFSのサーバに対してREADを再試行することができ、読み取ることを試み、またはれます。
PNFS_OSD_RAID_4 means that the last component object, or the last in each group (if odm_group_width is greater than zero), contains parity information computed over the rest of the stripe with an XOR operation. If a component object is unavailable, the client can read the rest of the stripe units in the damaged stripe and recompute the missing stripe unit by XORing the other stripe units in the stripe. Or the client can replay the READ against the pNFS server that will presumably perform the reconstructed read on the client's behalf.
PNFS_OSD_RAID_4は、最後のコンポーネントオブジェクト、または（odm_group_widthがゼロより大きい場合）、各グループの最後に、XOR演算を持つストライプの残りの部分にわたって計算パリティ情報を含むことを意味します。コンポーネントオブジェクトが利用できない場合、クライアントは、損傷ストライプにストライプユニットの残りの部分を読み、ストライプ内の他のストライプユニットのXORをとることによって欠落ストライプユニットを再計算することができます。またはクライアントはおそらく、クライアントに代わって再構築された読み取りを行いますのpNFSサーバーに対してREADを再生することができます。
When parity is present in the file, then there is an additional computation to map from the file offset L to the offset that accounts for embedded parity, L'. First compute L', and then use L' in the above equations for C and O.
パリティは、ファイル内に存在する場合、そのファイルからマッピングするための追加の計算は、埋め込まれたパリティを占めているオフセットL」にLを相殺しています。 C及びOのための上記の式におけるL「を使用し、次いで、及び」第一の計算L
L = file offset, not accounting for parity P = number of parity devices in each stripe W = group_width, if not zero, else size of olo_components array N = L / (W-P * stripe_unit) L' = N * (W * stripe_unit) + (L % (W-P * stripe_unit))
L =ファイルオフセット、パリティを占めていないP =各ストライプWにおけるパリティ装置の数= group_width、そうでない場合はゼロ、olo_componentsアレイの他のサイズN = L /（WP * stripe_unit）L」= N *（Wの*のstripe_unit） +（1％（WPの*のstripe_unit））
PNFS_OSD_RAID_5 means that the position of the parity data is rotated on each stripe or each group (if odm_group_width is greater than zero). In the first stripe, the last component holds the parity. In the second stripe, the next-to-last component holds the parity, and so on. In this scheme, all stripe units are rotated so that I/O is evenly spread across objects as the file is read sequentially. The rotated parity layout is illustrated here, with numbers indicating the stripe unit.
PNFS_OSD_RAID_5は（odm_group_widthがゼロより大きい場合）、パリティデータの位置は、各ストライプまたは各グループに回転させることを意味します。最初のストライプでは、最後のコンポーネントは、パリティを保持しています。第2のストライプでは、次から最後のコンポーネントは、そうでパリティを保持し、そして。ファイルが順次読み出されるようにI / Oが均等オブジェクトに分散されているように、この方式では、すべてのストライプユニットを回転させます。回転パリティレイアウトはストライプ部を示す数字と、ここに示されています。
0 1 2 P 4 5 P 3 8 P 6 7 P 9 a b
0 1 2 P 4 P 3 P 8 6 7 P 9 B
To compute the component object C, first compute the offset that accounts for parity L' and use that to compute C. Then rotate C to get C'. Finally, increase C' by one if the parity information comes at or before C' within that stripe. The following equations illustrate this by computing I, which is the index of the component that contains parity for a given stripe.
コンポーネントオブジェクトCを計算するには、最初の「次にCがCを得るために回転させ、Cを計算するためにそれを使用」パリティLを占め、そのオフセットを計算します。そのストライプ内の「パリティ情報を時またはCの前に来る場合は、1つによって」最後に、Cを増加させます。以下の式は、与えられたストライプのパリティを含むコンポーネントの指標であるIを計算することによってこれを示します。
L = file offset, not accounting for parity W = odm_group_width, if not zero, else size of olo_components array N = L / (W-1 * stripe_unit) (Compute L' as describe above) (Compute C based on L' as described above) C' = (C - (N%W)) % W I = W - (N%W) - 1 if (C' <= I) { C'++ }
L =ファイル記載されているようにodm_group_width = Wパリティを占めない、オフセット、そうでない場合はゼロ、olo_componentsアレイの他のサイズN = L /（W-1 * stripe_unit）（計算L '上記のように）（計算C Lに基づいて'上記）C '=（C - （N％のW））％WI = W - （N％のW） - 1であれば（C' <= I）{C '} ++
PNFS_OSD_RAID_PQ is a double-parity scheme that uses the Reed-Solomon P+Q encoding scheme [19]. In this layout, the last two component objects hold the P and Q data, respectively. P is parity computed with XOR, and Q is a more complex equation that is not described here. The equations given above for embedded parity can be used to map a file offset to the correct component object by setting the number of parity components to 2 instead of 1 for RAID4 or RAID5. Clients may simply choose to read data through the metadata server if two components are missing or damaged.
PNFS_OSD_RAID_PQは、リードソロモンP + Qの符号化方式[19]を使用して二重パリティ方式です。このレイアウトでは、最後の二つのコンポーネントオブジェクトは、それぞれ、PおよびQデータを保持します。 PはXORで計算パリティあり、そしてQは、ここで説明されていない、より複雑な方程式です。埋め込まれたパリティについて上記で与えられた式は、RAID4、又はRAID5のための2の代わりに1にパリティコンポーネントの数を設定することにより、正しいコンポーネントオブジェクトにオフセットファイルをマッピングするために使用することができます。クライアントは、単に二つの成分が存在しないか、または破損している場合、メタデータサーバを介してデータを読み取るために選択することができます。
RAID layouts with redundant data in their stripes require additional serialization of updates to ensure correct operation. Otherwise, if two clients simultaneously write to the same logical range of an object, the result could include different data in the same ranges of mirrored tuples, or corrupt parity information. It is the responsibility of the metadata server to enforce serialization requirements such as this. For example, the metadata server may do so by not granting overlapping write layouts within mirrored objects.
それらのストライプ内の冗長データとRAIDレイアウトが正しい動作を保証するために、更新の追加のシリアル化を必要とします。 2つのクライアントが同時にオブジェクトの同一の論理範囲に書き込む場合はそうでなければ、結果は、ミラーリングされたタプルの同じ範囲内の異なるデータ、または破損パリティ情報を含むことができます。これは、このような直列化要件を強制するメタデータサーバの責任です。例えば、メタデータサーバは、ミラーリングされたオブジェクト内の重複書き込みレイアウトを許可しないことで、そうすることができます。
layoutupdate4 is used in the LAYOUTCOMMIT operation to convey updates to the layout and additional information to the metadata server. It is defined in the NFSv4.1 [6] as follows:
layoutupdate4は、メタデータサーバへのレイアウトや追加情報への更新を伝えるためにLAYOUTCOMMIT操作で使用されています。以下のように[6] NFSv4.1で定義されています。
struct layoutupdate4 {
layouttype4 lou_type;
opaque lou_body<>;
};
The layoutupdate4 type is an opaque value at the generic pNFS client level. If the lou_type layout type is LAYOUT4_OSD2_OBJECTS, then the lou_body opaque value is defined by the pnfs_osd_layoutupdate4 type.
layoutupdate4タイプは、汎用のpNFSクライアントレベルでの不透明な値です。 lou_typeレイアウトタイプがLAYOUT4_OSD2_OBJECTSある場合、lou_body不透明値はpnfs_osd_layoutupdate4タイプによって定義されます。
Object-Based pNFS clients are not allowed to modify the layout. Therefore, the information passed in pnfs_osd_layoutupdate4 is used only to update the file's attributes. In addition to the generic information the client can pass to the metadata server in LAYOUTCOMMIT such as the highest offset the client wrote to and the last time it modified the file, the client MAY use pnfs_osd_layoutupdate4 to convey the capacity consumed (or released) by writes using the layout, and to indicate that I/O errors were encountered by such writes.
オブジェクトベースのpNFSクライアントは、レイアウトを変更することはできません。したがって、pnfs_osd_layoutupdate4に渡される情報には、ファイルの属性を更新するためにのみ使用されます。一般的な情報に加えて、クライアントは、このような最高のクライアントが書いた最後の時間は、それがファイルを変更し、クライアントが書き込みによって容量が消費（または解放）を伝えるためにpnfs_osd_layoutupdate4を使用するかもしれオフセットとしてLAYOUTCOMMITにメタデータ・サーバに渡すことができますレイアウトを使用して、およびI / Oエラーは、このような書き込みによって発生したことを示すために。
/// union pnfs_osd_deltaspaceused4 switch (bool dsu_valid) {
/// case TRUE:
/// int64_t dsu_delta;
/// case FALSE:
/// void;
/// };
///
pnfs_osd_deltaspaceused4 is used to convey space utilization information at the time of LAYOUTCOMMIT. For the file system to properly maintain capacity-used information, it needs to track how much capacity was consumed by WRITE operations performed by the client. In this protocol, the OSD returns the capacity consumed by a write (*), which can be different than the number of bytes written because of internal overhead like block-level allocation and indirect blocks, and the client reflects this back to the pNFS server so it can accurately track quota. The pNFS server can choose to trust this information coming from the clients and therefore avoid querying the OSDs at the time of LAYOUTCOMMIT. If the client is unable to obtain this information from the OSD, it simply returns invalid olu_delta_space_used.
pnfs_osd_deltaspaceused4はLAYOUTCOMMITの時空間利用情報を伝えるために使用されます。ファイルシステムが正常に容量-使用される情報を維持するためには、クライアントによって実行されるWRITE操作によって消費されたどのくらいの容量を追跡する必要があります。このプロトコルでは、OSDがあるため、ブロックレベルの割り当てと間接ブロックなどの内部オーバーヘッドの書き込まれたバイト数とは異なることができ、書き込み（*）によって消費される容量を返し、クライアントはpNFSのサーバにこのバックを反映しますそれは正確にクォータを追跡することができます。 pNFSのサーバは、クライアントからこの情報を信頼し、したがって、LAYOUTCOMMITの時のOSDを照会することを避けるために選択することができます。クライアントは、OSDからこの情報を取得できない場合、それは単にolu_delta_space_used無効返します。
/// struct pnfs_osd_layoutupdate4 {
/// pnfs_osd_deltaspaceused4 olu_delta_space_used;
/// bool olu_ioerr_flag;
/// };
///
"olu_delta_space_used" is used to convey capacity usage information back to the metadata server.
「olu_delta_space_used」バックメタデータサーバへの容量の使用状況に関する情報を伝えるために使用されます。
The "olu_ioerr_flag" is used when I/O errors were encountered while writing the file. The client MUST report the errors using the pnfs_osd_ioerr4 structure (see Section 8.1) at LAYOUTRETURN time.
ファイルの書き込み中にI / Oエラーが発生した際に「olu_ioerr_flag」が使用されています。クライアントはLAYOUTRETURN時（8.1節を参照）pnfs_osd_ioerr4構造を使用して、エラーを報告しなければなりません。
If the client updated the file successfully before hitting the I/O errors, it MAY use LAYOUTCOMMIT to update the metadata server as described above. Typically, in the error-free case, the server MAY turn around and update the file's attributes on the storage devices. However, if I/O errors were encountered, the server better not attempt to write the new attributes on the storage devices until it receives the I/O error report; therefore, the client MUST set the olu_ioerr_flag to true. Note that in this case, the client SHOULD send both the LAYOUTCOMMIT and LAYOUTRETURN operations in the same COMPOUND RPC.
クライアントは、I / Oエラーを打つ前に、ファイルを正常に更新した場合、それは上記のように、メタデータ・サーバを更新するためにLAYOUTCOMMITを使用するかもしれません。一般的に、エラーのない場合には、サーバが振り向くと、ストレージ・デバイス上のファイルの属性を更新することができます。 I / Oエラーが発生した場合は、サーバーは、より良い、それがI / Oエラーレポートを受信するまでのストレージデバイス上に新しい属性を記述しようとしません。そのため、クライアントがtrueにolu_ioerr_flagを設定しなければなりません。この場合には、クライアントが同じ化合物のRPCにLAYOUTCOMMITとLAYOUTRETURN操作の両方を送るべきであることに注意してください。
The pNFS client may encounter errors when directly accessing the object storage devices. However, it is the responsibility of the metadata server to handle the I/O errors. When the LAYOUT4_OSD2_OBJECTS layout type is used, the client MUST report the I/O errors to the server at LAYOUTRETURN time using the pnfs_osd_ioerr4 structure (see Section 8.1).
直接オブジェクト・ストレージ・デバイスにアクセスする際のpNFSクライアントは、エラーが発生することがあります。しかし、I / Oエラーを処理するために、メタデータサーバの責任です。 LAYOUT4_OSD2_OBJECTSレイアウトタイプを使用する場合、クライアントはpnfs_osd_ioerr4構造を（8.1節を参照）を使用してLAYOUTRETURN時にサーバーへのI / Oエラーを報告しなければなりません。
The metadata server analyzes the error and determines the required recovery operations such as repairing any parity inconsistencies, recovering media failures, or reconstructing missing objects.
メタデータサーバがエラーを分析し、このような、任意のパリティの不一致を修復メディア障害の回復、または欠落しているオブジェクトを再構築するなど、必要なリカバリ操作を決定します。
The metadata server SHOULD recall any outstanding layouts to allow it exclusive write access to the stripes being recovered and to prevent other clients from hitting the same error condition. In these cases, the server MUST complete recovery before handing out any new layouts to the affected byte ranges.
メタデータサーバが回収されていると、同じエラー条件を打つから、他のクライアントを防ぐために、それをストライプへの排他的書き込みアクセスを許可するように、未処理のレイアウトを思い出すべきです。これらのケースでは、サーバーは、影響を受けたバイト範囲に新しいレイアウトを配る前に復旧を完了する必要があります。
Although it MAY be acceptable for the client to propagate a corresponding error to the application that initiated the I/O operation and drop any unwritten data, the client SHOULD attempt to retry the original I/O operation by requesting a new layout using LAYOUTGET and retry the I/O operation(s) using the new layout, or the client MAY just retry the I/O operation(s) using regular NFS READ or WRITE operations via the metadata server. The client SHOULD attempt to retrieve a new layout and retry the I/O operation using OSD commands first and only if the error persists, retry the I/O operation via the metadata server.
それはI / O操作を開始したアプリケーションに対応するエラーを伝播し、任意の書き込まれていないデータを削除するには、クライアントのために許容することができるが、クライアントがLAYOUTGETを使用して新しいレイアウトを要求することにより、元のI / O操作を再試行し、再試行を試みる必要があります新しいレイアウトを使用してI / O操作（複数可）、またはクライアントは、単にメタデータ・サーバを経由して定期的なNFS READまたはWRITE操作を使用してI / O操作（複数可）を再試行することができます。クライアントは、新しいレイアウトを取得しようと、第1およびエラーが続く場合にのみ、メタデータ・サーバを経由してI / O操作を再試行コマンドOSDを使用してI / O操作を再試行する必要があります。
layoutreturn_file4 is used in the LAYOUTRETURN operation to convey layout-type specific information to the server. It is defined in the NFSv4.1 [6] as follows:
layoutreturn_file4がサーバにレイアウト・タイプ固有の情報を伝えるためLAYOUTRETURN操作で使用されています。以下のように[6] NFSv4.1で定義されています。
struct layoutreturn_file4 {
offset4 lrf_offset;
length4 lrf_length;
stateid4 lrf_stateid;
/* layouttype4 specific data */
opaque lrf_body<>;
};
union layoutreturn4 switch(layoutreturn_type4 lr_returntype) {
case LAYOUTRETURN4_FILE:
layoutreturn_file4 lr_layout;
default:
void;
};
struct LAYOUTRETURN4args {
/* CURRENT_FH: file */
bool lora_reclaim;
layoutreturn_stateid lora_recallstateid;
layouttype4 lora_layout_type;
layoutiomode4 lora_iomode;
layoutreturn4 lora_layoutreturn;
};
If the lora_layout_type layout type is LAYOUT4_OSD2_OBJECTS, then the lrf_body opaque value is defined by the pnfs_osd_layoutreturn4 type.
lora_layout_typeレイアウトタイプがLAYOUT4_OSD2_OBJECTSある場合、lrf_body不透明値はpnfs_osd_layoutreturn4タイプによって定義されます。
The pnfs_osd_layoutreturn4 type allows the client to report I/O error information back to the metadata server as defined below.
pnfs_osd_layoutreturn4タイプは、以下に定義するクライアントは、メタデータサーバに戻ってI / Oエラー情報を報告することができます。
/// enum pnfs_osd_errno4 { /// PNFS_OSD_ERR_EIO = 1, /// PNFS_OSD_ERR_NOT_FOUND = 2, /// PNFS_OSD_ERR_NO_SPACE = 3, /// PNFS_OSD_ERR_BAD_CRED = 4, /// PNFS_OSD_ERR_NO_ACCESS = 5, /// PNFS_OSD_ERR_UNREACHABLE = 6, /// PNFS_OSD_ERR_RESOURCE = 7 /// }; ///
///列挙pnfs_osd_errno4 {/// PNFS_OSD_ERR_EIO = 1、/// PNFS_OSD_ERR_NOT_FOUND = 2、/// PNFS_OSD_ERR_NO_SPACE = 3、/// PNFS_OSD_ERR_BAD_CRED = 4、/// PNFS_OSD_ERR_NO_ACCESS = 5、/// PNFS_OSD_ERR_UNREACHABLE = 6、// / PNFS_OSD_ERR_RESOURCE = 7 ///}。 ///
pnfs_osd_errno4 is used to represent error types when read/write errors are reported to the metadata server. The error codes serve as hints to the metadata server that may help it in diagnosing the exact reason for the error and in repairing it.
pnfs_osd_errno4は読み取り/書き込みエラーをメタデータサーバに報告されているときにエラーの種類を表すために使用されます。エラーコードは、エラーの正確な理由を診断し、それを修復して、それを助けるかもしれメタデータサーバへのヒントとして役立ちます。
o PNFS_OSD_ERR_EIO indicates the operation failed because the object storage device experienced a failure trying to access the object. The most common source of these errors is media errors, but other internal errors might cause this as well. In this case, the metadata server should go examine the broken object more closely; hence, it should be used as the default error code.
O PNFS_OSD_ERR_EIOは、オブジェクト・ストレージ・デバイスがオブジェクトにアクセスしようと失敗を経験したため、操作が失敗したことを示します。これらのエラーの最も一般的な原因は、メディアエラーであるが、他の内部エラーも同様にこれを引き起こす可能性があります。この場合、メタデータサーバは、より密接に壊れたオブジェクトを調べて行く必要があります。したがって、それはデフォルトのエラー・コードとして使用する必要があります。
o PNFS_OSD_ERR_NOT_FOUND indicates the object ID specifies an object that does not exist on the object storage device.
O PNFS_OSD_ERR_NOT_FOUNDは、オブジェクトIDは、オブジェクト・ストレージ・デバイス上に存在しないオブジェクトを指定示します。
o PNFS_OSD_ERR_NO_SPACE indicates the operation failed because the object storage device ran out of free capacity during the operation.
O PNFS_OSD_ERR_NO_SPACEは、オブジェクト・ストレージ・デバイスが動作中に空き容量を使い果たしたため、操作が失敗したことを示します。
o PNFS_OSD_ERR_BAD_CRED indicates the security parameters are not valid. The primary cause of this is that the capability has expired, or the access policy tag (a.k.a., capability version number) has been changed to revoke capabilities. The client will need to return the layout and get a new one with fresh capabilities.
O PNFS_OSD_ERR_BAD_CREDは、セキュリティパラメータが有効でない示します。この主な原因は、機能の有効期限が切れている、またはアクセスポリシータグ（別称、機能のバージョン番号が）機能を取り消すために変更されていることです。クライアントは、レイアウトを返し、新鮮な機能を持つ新しいものを取得する必要があります。
o PNFS_OSD_ERR_NO_ACCESS indicates the capability does not allow the requested operation. This should not occur in normal operation because the metadata server should give out correct capabilities, or none at all.
O PNFS_OSD_ERR_NO_ACCESSは、要求された操作を許可しない能力を示します。メタデータサーバが正しい機能、またはまったくなしを配る必要があるので、これは通常の操作では発生しません。
o PNFS_OSD_ERR_UNREACHABLE indicates the client did not complete the I/O operation at the object storage device due to a communication failure. Whether or not the I/O operation was executed by the OSD is undetermined.
O PNFS_OSD_ERR_UNREACHABLEは、クライアントが通信障害へのオブジェクト・ストレージ・デバイスでI / O操作を完了しませんでした示しています。 I / O操作はOSDによって実行されたかどうかは未定です。
o PNFS_OSD_ERR_RESOURCE indicates the client did not issue the I/O operation due to a local problem on the initiator (i.e., client) side, e.g., when running out of memory. The client MUST guarantee that the OSD command was never dispatched to the OSD.
メモリが不足したときにO PNFS_OSD_ERR_RESOURCE起因開始剤（すなわち、クライアント）側、例えば、上のローカル問題にI / O操作を発行していないクライアントを示しています。クライアントは、OSDコマンドがOSDに派遣されなかったことを保証しなければなりません。
/// struct pnfs_osd_ioerr4 {
/// pnfs_osd_objid4 oer_component;
/// length4 oer_comp_offset;
/// length4 oer_comp_length;
/// bool oer_iswrite;
/// pnfs_osd_errno4 oer_errno;
/// };
///
The pnfs_osd_ioerr4 structure is used to return error indications for objects that generated errors during data transfers. These are hints to the metadata server that there are problems with that object. For each error, "oer_component", "oer_comp_offset", and "oer_comp_length" represent the object and byte range within the component object in which the error occurred; "oer_iswrite" is set to "true" if the failed OSD operation was data modifying, and "oer_errno" represents the type of error.
pnfs_osd_ioerr4構造は、データ転送中にエラーが発生したオブジェクトのエラー表示を返すために使用されます。これらは、そのオブジェクトに問題があるメタデータサーバへのヒントです。各エラーのために、「oer_component」、「oer_comp_offset」、および「oer_comp_length」エラーが発生したコンポーネント・オブジェクト内のオブジェクトとバイト範囲を表します。失敗したOSD操作は、データが変更、および「oer_errno」された場合「oer_iswrite」は「真」に設定されているエラーのタイプを表します。
Component byte ranges in the optional pnfs_osd_ioerr4 structure are used for recovering the object and MUST be set by the client to cover all failed I/O operations to the component.
任意pnfs_osd_ioerr4構造におけるコンポーネントのバイト範囲がオブジェクトを回復するために使用され、すべてのコンポーネントにI / O操作を失敗覆うように、クライアントによって設定されなければなりません。
/// struct pnfs_osd_layoutreturn4 {
/// pnfs_osd_ioerr4 olr_ioerr_report<>;
/// };
///
When OSD I/O operations failed, "olr_ioerr_report<>" is used to report these errors to the metadata server as an array of elements of type pnfs_osd_ioerr4. Each element in the array represents an error that occurred on the object specified by oer_component. If no errors are to be reported, the size of the olr_ioerr_report<> array is set to zero.
OSD I / O操作が失敗した場合は、「olr_ioerr_report <>」型pnfs_osd_ioerr4の要素の配列として、メタデータ・サーバにこれらのエラーを報告するために使用されます。アレイ内の各要素はoer_componentによって指定されたオブジェクトで発生したエラーを表しています。エラーが報告されていない場合、olr_ioerr_report <>配列のサイズはゼロに設定されます。
The layouthint4 type is defined in the NFSv4.1 [6] as follows:
layouthint4タイプはNFSv4.1で定義されている[6]を次のように
struct layouthint4 {
layouttype4 loh_type;
opaque loh_body<>;
};
The layouthint4 structure is used by the client to pass a hint about the type of layout it would like created for a particular file. If the loh_type layout type is LAYOUT4_OSD2_OBJECTS, then the loh_body opaque value is defined by the pnfs_osd_layouthint4 type.
layouthint4構造は、それが特定のファイルのために作成された希望のレイアウトのタイプについてのヒントを渡すために、クライアントによって使用されます。 loh_typeレイアウトタイプがLAYOUT4_OSD2_OBJECTSある場合、loh_body不透明値はpnfs_osd_layouthint4タイプによって定義されます。
/// union pnfs_osd_max_comps_hint4 switch (bool omx_valid) {
/// case TRUE:
/// uint32_t omx_max_comps;
/// case FALSE:
/// void;
/// };
///
/// union pnfs_osd_stripe_unit_hint4 switch (bool osu_valid) {
/// case TRUE:
/// length4 osu_stripe_unit;
/// case FALSE:
/// void;
/// };
///
/// union pnfs_osd_group_width_hint4 switch (bool ogw_valid) {
/// case TRUE:
/// uint32_t ogw_group_width;
/// case FALSE:
/// void;
/// };
///
/// union pnfs_osd_group_depth_hint4 switch (bool ogd_valid) {
/// case TRUE:
/// uint32_t ogd_group_depth;
/// case FALSE:
/// void;
/// };
///
/// union pnfs_osd_mirror_cnt_hint4 switch (bool omc_valid) {
/// case TRUE:
/// uint32_t omc_mirror_cnt;
/// case FALSE:
/// void;
/// };
///
/// union pnfs_osd_raid_algorithm_hint4 switch (bool ora_valid) {
/// case TRUE:
/// pnfs_osd_raid_algorithm4 ora_raid_algorithm;
/// case FALSE:
/// void;
/// };
///
/// struct pnfs_osd_layouthint4 {
/// pnfs_osd_max_comps_hint4 olh_max_comps_hint;
/// pnfs_osd_stripe_unit_hint4 olh_stripe_unit_hint;
/// pnfs_osd_group_width_hint4 olh_group_width_hint;
/// pnfs_osd_group_depth_hint4 olh_group_depth_hint;
/// pnfs_osd_mirror_cnt_hint4 olh_mirror_cnt_hint;
/// pnfs_osd_raid_algorithm_hint4 olh_raid_algorithm_hint;
/// };
///
This type conveys hints for the desired data map. All parameters are optional so the client can give values for only the parameters it cares about, e.g. it can provide a hint for the desired number of mirrored components, regardless of the RAID algorithm selected for the file. The server should make an attempt to honor the hints, but it can ignore any or all of them at its own discretion and without failing the respective CREATE operation.
このタイプは、所望のデータマップのためのヒントを伝えます。クライアントは、例えば、それは気に唯一のパラメータの値を与えることができますので、すべてのパラメータはオプションですそれは関係なく、ファイルの選択したRAIDアルゴリズムの、ミラーリングされた構成要素の所望の数のためのヒントを提供することができます。サーバーはヒントを尊重しようとする試みをしなければならないが、それは、独自の裁量とCREATEそれぞれの操作を失敗することなく、それらのいずれかまたは全てを無視することができます。
The "olh_max_comps_hint" can be used to limit the total number of component objects comprising the file. All other hints correspond directly to the different fields of pnfs_osd_data_map4.
「olh_max_comps_hint」は、ファイルを含むコンポーネントオブジェクトの総数を制限するために使用することができます。他のすべてのヒントはpnfs_osd_data_map4の異なるフィールドに直接対応します。
The pnfs layout operations operate on logical byte ranges. There is no requirement in the protocol for any relationship between byte ranges used in LAYOUTGET to acquire layouts and byte ranges used in CB_LAYOUTRECALL, LAYOUTCOMMIT, or LAYOUTRETURN. However, using OSD byte-range capabilities poses limitations on these operations since the capabilities associated with layout segments cannot be merged or split. The following guidelines should be followed for proper operation of object-based layouts.
pNFSのレイアウト操作は、論理的なバイト範囲で動作します。 CB_LAYOUTRECALL、LAYOUTCOMMIT、又はLAYOUTRETURNで使用されるレイアウトおよびバイト範囲を取得するLAYOUTGETで使用されるバイト範囲の間の任意の関係のためのプロトコルで必要はありません。レイアウトのセグメントに関連付けられた機能がマージまたは分割することができないので、OSDバイト範囲の機能を使用すると、これらの操作上の制限を課します。次のガイドラインは、オブジェクトベースのレイアウトが正しく動作するために従うべきです。
In general, the object-based layout driver should keep track of each layout segment it got, keeping record of the segment's iomode, offset, and length. The server should allow the client to get multiple overlapping layout segments but is free to recall the layout to prevent overlap.
一般的には、オブジェクトベースのレイアウトドライバはセグメントのIOModeに、オフセット、および長さの記録を維持する、それが得た各レイアウト・セグメントを追跡する必要があります。サーバは、クライアントが複数重なったレイアウト・セグメントを取得することができますが、重複を防ぐために、レイアウトをリコールして自由であるべきです。
In response to CB_LAYOUTRECALL, the client should return all layout segments matching the given iomode and overlapping with the recalled range. When returning the layouts for this byte range with LAYOUTRETURN, the client MUST NOT return a sub-range of a layout segment it has; each LAYOUTRETURN sent MUST completely cover at least one outstanding layout segment.
CB_LAYOUTRECALLに応答して、クライアントは、リコールの範囲で与えられIOModeに重複に一致するすべてのレイアウト・セグメントを返すべきです。 LAYOUTRETURNこのバイト範囲のためのレイアウトを返すとき、クライアントはそれを持っていレイアウトセグメントのサブ範囲を返してはなりません。完全少なくとも一つの未処理のレイアウト・セグメントをカバーしなければならない送信された各LAYOUTRETURN。
The server, in turn, should release any segment that exactly matches the clientid, iomode, and byte range given in LAYOUTRETURN. If no exact match is found, then the server should release all layout segments matching the clientid and iomode and that are fully contained in the returned byte range. If none are found and the byte range is a subset of an outstanding layout segment with for the same clientid and iomode, then the client can be considered malfunctioning and the server SHOULD recall all layouts from this client to reset its state. If this behavior repeats, the server SHOULD deny all LAYOUTGETs from this client.
サーバは、順番に、正確にLAYOUTRETURNに与えられたclientid、IOModeに、バイトの範囲に一致する任意のセグメントを解放する必要があります。正確に一致が見つからない場合、サーバはクライアントIDとIOModeに一致するすべてのレイアウト・セグメントを解放し、完全に返されるバイト範囲に含まれているべきです。何も見つからず、バイト範囲、同じClientIDとIOModeにためと優れたレイアウト・セグメントのサブセットであるされている場合、クライアントは誤動作と考えることができ、サーバはその状態をリセットするために、このクライアントからのすべてのレイアウトを思い出すべきです。この動作が繰り返された場合、サーバは、このクライアントからのすべてのLAYOUTGETsを拒否すべきです。
LAYOUTCOMMIT is only used by object-based pNFS to convey modified attributes hints and/or to report the presence of I/O errors to the metadata server (MDS). Therefore, the offset and length in LAYOUTCOMMIT4args are reserved for future use and should be set to 0.
LAYOUTCOMMITのみヒント属性および/またはメタデータサーバ（MDS）にI / Oエラーの存在を報告するように変更を伝えるためにオブジェクトベースのpNFSで使用されます。したがって、LAYOUTCOMMIT4argsのオフセットと長さは、将来の使用のために予約され、0に設定されるべきです。
The object-based metadata server should recall outstanding layouts in the following cases:
オブジェクトベースのメタデータ・サーバは、次のような場合には、優れたレイアウトを思い出す必要があります。
o When the file's security policy changes, i.e., Access Control Lists (ACLs) or permission mode bits are set.
Oと、ファイルのセキュリティ・ポリシーの変更、すなわち、アクセス制御リスト（ACL）または許可モードのビットが設定されています。
o When the file's aggregation map changes, rendering outstanding layouts invalid.
Oファイルの集計マップの変更は、無効な優れたレイアウトをレンダリングする場合。
o When there are sharing conflicts. For example, the server will issue stripe-aligned layout segments for RAID-5 objects. To prevent corruption of the file's parity, multiple clients must not hold valid write layouts for the same stripes. An outstanding READ/WRITE (RW) layout should be recalled when a conflicting LAYOUTGET is received from a different client for LAYOUTIOMODE4_RW and for a byte range overlapping with the outstanding layout segment.
共有競合があるO。例えば、サーバは、RAID-5オブジェクトのストライプ整列レイアウト・セグメントを発行します。ファイルのパリティの破損を防ぐために、複数のクライアントが同じストライプのための有効なライトのレイアウトを保持していなければなりません。競合LAYOUTGETがLAYOUTIOMODE4_RWため、優れたレイアウト・セグメントのバイト範囲の重複のために異なるクライアントから受信されたときに未処理のREAD / WRITE（RW）のレイアウトを想起すべきです。
The metadata server can use the CB_RECALL_ANY callback operation to notify the client to return some or all of its layouts. The NFSv4.1 [6] defines the following types:
メタデータサーバは、そのレイアウトの一部またはすべてを返すようにクライアントに通知するためにCB_RECALL_ANYコールバック操作を使用することができます。 NFSv4.1 [6]は、次のタイプが定義されています。
const RCA4_TYPE_MASK_OBJ_LAYOUT_MIN = 8;
const RCA4_TYPE_MASK_OBJ_LAYOUT_MAX = 9;
struct CB_RECALL_ANY4args {
uint32_t craa_objects_to_keep;
bitmap4 craa_type_mask;
};
Typically, CB_RECALL_ANY will be used to recall client state when the server needs to reclaim resources. The craa_type_mask bitmap specifies the type of resources that are recalled and the craa_objects_to_keep value specifies how many of the recalled objects the client is allowed to keep. The object-based layout type mask flags are defined as follows. They represent the iomode of the recalled layouts. In response, the client SHOULD return layouts of the recalled iomode that it needs the least, keeping at most craa_objects_to_keep object-based layouts.
一般的に、CB_RECALL_ANYは、サーバーがリソースを再利用する必要がある場合に、クライアントの状態をリコールするために使用されます。 craa_type_maskビットマップは、リコールとcraa_objects_to_keep値は、クライアントが続けることができる方法を想起したオブジェクトの数を指定されたリソースの種類を指定します。次のようにオブジェクトベースのレイアウト型マスクフラグが定義されています。彼らは、リコールのレイアウトのIOModeにを表しています。応答では、クライアントは、それはせいぜいcraa_objects_to_keepオブジェクトベースのレイアウトを保ち、最低を必要としていることを想起しIOModeにのレイアウトを返すべきです。
/// enum pnfs_osd_cb_recall_any_mask { /// PNFS_OSD_RCA4_TYPE_MASK_READ = 8, /// PNFS_OSD_RCA4_TYPE_MASK_RW = 9 /// }; ///
///列挙pnfs_osd_cb_recall_any_mask {/// PNFS_OSD_RCA4_TYPE_MASK_READ = 8、/// PNFS_OSD_RCA4_TYPE_MASK_RW = 9 ///}。 ///
The PNFS_OSD_RCA4_TYPE_MASK_READ flag notifies the client to return layouts of iomode LAYOUTIOMODE4_READ. Similarly, the PNFS_OSD_RCA4_TYPE_MASK_RW flag notifies the client to return layouts of iomode LAYOUTIOMODE4_RW. When both mask flags are set, the client is notified to return layouts of either iomode.
PNFS_OSD_RCA4_TYPE_MASK_READフラグはIOModeにLAYOUTIOMODE4_READのレイアウトを返すようにクライアントに通知します。同様に、PNFS_OSD_RCA4_TYPE_MASK_RWフラグがIOModeにLAYOUTIOMODE4_RWのレイアウトを返すようにクライアントに通知します。両方のマスクのフラグが設定されている場合は、クライアントは、どちらかIOModeにのレイアウトを返すように通知されます。
In cases where clients are uncommunicative and their lease has expired or when clients fail to return recalled layouts within a lease period at the least (see "Recalling a Layout"[6]), the server MAY revoke client layouts and/or device address mappings and reassign these resources to other clients. To avoid data corruption, the metadata server MUST fence off the revoked clients from the respective objects as described in Section 13.4.
クライアントが通信不能であり、そのリースの有効期限が切れているか、クライアントが（「レイアウトを想起し」を参照してください。[6]）、サーバはクライアントのレイアウトおよび/またはデバイスのアドレスマッピングを取り消すことができる、少なくともリース期間内にリコールのレイアウトを返すために失敗した場合のケースではそして他のクライアントにこれらのリソースを再割り当てします。データの破損を避けるために、各オブジェクトから取り消されたクライアントオフメタデータサーバMUSTフェンスは、13.4節で説明したように。
The pNFS extension partitions the NFSv4 file system protocol into two parts, the control path and the data path (storage protocol). The control path contains all the new operations described by this extension; all existing NFSv4 security mechanisms and features apply to the control path. The combination of components in a pNFS system is required to preserve the security properties of NFSv4 with respect to an entity accessing data via a client, including security countermeasures to defend against threats that NFSv4 provides defenses for in environments where these threats are considered significant.
pNFSの拡張は、二つの部分、制御パスとデータパス（ストレージプロトコル）へのNFSv4ファイルシステムプロトコルを仕切ります。制御パスは、この拡張によって記載されているすべての新しい操作が含まれています。すべての既存のNFSv4のセキュリティメカニズムと機能は、制御パスに適用されます。 pNFSのシステム内の構成要素の組み合わせはNFSv4のは、これらの脅威が重要であると考えられる環境にするための防御を提供する脅威から守るためのセキュリティ対策など、クライアントを介してデータにアクセスするエンティティに対してのNFSv4のセキュリティ特性を維持するために必要とされます。
The metadata server enforces the file access-control policy at LAYOUTGET time. The client should use suitable authorization credentials for getting the layout for the requested iomode (READ or RW) and the server verifies the permissions and ACL for these credentials, possibly returning NFS4ERR_ACCESS if the client is not allowed the requested iomode. If the LAYOUTGET operation succeeds the client receives, as part of the layout, a set of object capabilities allowing it I/O access to the specified objects corresponding to the requested iomode. When the client acts on I/O operations on behalf of its local users, it MUST authenticate and authorize the user by issuing respective OPEN and ACCESS calls to the metadata server, similar to having NFSv4 data delegations. If access is allowed, the client uses the corresponding (READ or RW) capabilities to perform the I/O operations at the object storage devices. When the metadata server receives a request to change a file's permissions or ACL, it SHOULD recall all layouts for that file and it MUST change the capability version attribute on all objects comprising the file to implicitly invalidate any outstanding capabilities before committing to the new permissions and ACL. Doing this will ensure that clients re-authorize their layouts according to the modified permissions and ACL by requesting new layouts. Recalling the layouts in this case is courtesy of the server intended to prevent clients from getting an error on I/Os done after the capability version changed.
メタデータサーバは、LAYOUTGET時にファイルのアクセス制御ポリシーを適用します。クライアントは、要求されたIOModeにするためにレイアウトを取得するため、適切な認証の資格情報を使用する必要があります（READまたはRW）と、サーバは、クライアントが要求IOModeには許可されていない場合は、おそらくNFS4ERR_ACCESSを返し、これらの資格情報の権限とACLを検証します。 LAYOUTGET操作は、クライアントは、レイアウトの一部として、受信成功した場合は、オブジェクト機能のセットはそれを要求したIOModeに対応する指定されたオブジェクトへのI / Oアクセスを許可します。クライアントは、そのローカルユーザーの代わりにI / O操作に作用すると、それがそれぞれのOPENとアクセスを発行してユーザーを認証し、承認する必要がありNFSv4のデータの代表団を持つと同様に、メタデータサーバへの呼び出し。アクセスが許可されている場合、クライアントは、オブジェクト・ストレージ・デバイスでI / O操作を実行するために、対応する（READまたはRW）機能を使用しています。メタデータサーバは、ファイルのアクセス権またはACLを変更する要求を受信すると、そのファイルのすべてのレイアウトを思い出すべきで、それが暗黙のうちに新しいアクセス権にコミットする前に、未処理の機能を無効にするために、ファイルを構成するすべてのオブジェクトに対する機能のバージョン属性を変更する必要がありますし、 ACL。これを行うと、クライアントは新しいレイアウトを要求することによって変更アクセス権とACLに応じてそのレイアウト承認を再度ていることを確認します。この場合にはレイアウトを想起すると、機能のバージョンが変更された後に行うI / Oの上のエラーを取得してからクライアントを防止することを目的とサーバーの礼儀です。
The object storage protocol MUST implement the security aspects described in version 1 of the T10 OSD protocol definition [1]. The standard defines four security methods: NOSEC, CAPKEY, CMDRSP, and ALLDATA. To provide minimum level of security allowing verification and enforcement of the server access control policy using the layout security credentials, the NOSEC security method MUST NOT be used for any I/O operation. The remainder of this section gives an overview of the security mechanism described in that standard. The goal is to give the reader a basic understanding of the object security model. Any discrepancies between this text and the actual standard are obviously to be resolved in favor of the OSD standard.
オブジェクト・ストレージ・プロトコル[1]はT10 OSDプロトコル定義のバージョン1に記載のセキュリティ態様を実装しなければなりません。 NOSEC、CAPKEY、CMDRSP、およびALLDATA：標準は、4つのセキュリティメソッドを定義します。セキュリティ許可の検証、レイアウトのセキュリティ資格情報を使用してサーバーへのアクセス制御ポリシーの施行の最小レベルを提供するために、NOSECのセキュリティ方式は、任意のI / O操作のために使用してはいけません。このセクションの残りの部分は、その標準に記載されているセキュリティ・メカニズムの概要を示します。目標は、読者にオブジェクトのセキュリティモデルの基本的な理解を与えることです。このテキストと実際の標準間の矛盾は、OSDの規格を優先して解決することが明らかにされています。
There are three main data types associated with object security: a capability, a credential, and security parameters. The capability is a set of fields that specifies an object and what operations can be performed on it. A credential is a signed capability. Only a security manager that knows the secret device keys can correctly sign a capability to form a valid credential. In pNFS, the file server acts as the security manager and returns signed capabilities (i.e., credentials) to the pNFS client. The security parameters are values computed by the issuer of OSD commands (i.e., the client) that prove they hold valid credentials. The client uses the credential as a signing key to sign the requests it makes to OSD, and puts the resulting signatures into the security_parameters field of the OSD command. The object storage device uses the secret keys it shares with the security manager to validate the signature values in the security parameters.
機能、資格、およびセキュリティパラメータ：オブジェクトのセキュリティに関連する3つの主なデータの種類があります。機能は、オブジェクトを指定し、どのような操作がそれに実行することができるフィールドのセットです。資格は、署名機能です。秘密デバイス鍵を知っている唯一のセキュリティマネージャが正しく、有効な資格を形成する能力が署名することができます。 pNFSのでは、ファイルサーバのセキュリティマネージャとして機能し、戻りpNFSのクライアントに機能（すなわち、資格証明）を署名しました。セキュリティパラメータは、彼らが有効な資格情報を保持することを証明OSDコマンド（すなわち、クライアント）の発行者によって計算された値です。クライアントは、それがOSDになり要求に署名するための署名鍵としての資格を使用し、OSDコマンドのsecurity_parametersフィールドに結果の署名を置きます。オブジェクト・ストレージ・デバイスは、セキュリティパラメータの署名値を検証するために、セキュリティマネージャと共有する秘密鍵を使用します。
The security types are opaque to the generic layers of the pNFS client. The credential contents are defined as opaque within the pnfs_osd_object_cred4 type. Instead of repeating the definitions here, the reader is referred to Section 4.9.2.2 of the OSD standard.
セキュリティタイプは、pNFSのクライアントの一般的な層に不透明です。資格内容はpnfs_osd_object_cred4型内不透明として定義されます。代わりに、ここでの定義を繰り返すことで、読者はOSD標準のセクション4.9.2.2を参照します。
The object storage protocol relies on a cryptographically secure capability to control accesses at the object storage devices. Capabilities are generated by the metadata server, returned to the client, and used by the client as described below to authenticate their requests to the object-based storage device. Capabilities therefore achieve the required access and open mode checking. They allow the file server to define and check a policy (e.g., open mode) and the OSD to enforce that policy without knowing the details (e.g., user IDs and ACLs).
オブジェクト・ストレージ・プロトコルは、オブジェクト・ストレージ・デバイスにアクセスを制御するために、安全な暗号化能力に依存しています。オブジェクトベースのストレージデバイスへの要求を認証するために、以下のような機能は、メタデータサーバによって生成されたクライアントに返され、クライアントによって使用されています。機能は、そのために必要なアクセスおよびオープンモードのチェックを実現します。彼らは、ファイルサーバが定義および詳細（例えば、ユーザID、およびACL）を知ることなく、そのポリシーを適用するポリシー（例えば、オープンモード）とOSDをチェックすることを可能にします。
Since capabilities are tied to layouts, and since they are used to enforce access control, when the file ACL or mode changes the outstanding capabilities MUST be revoked to enforce the new access permissions. The server SHOULD recall layouts to allow clients to gracefully return their capabilities before the access permissions change.
機能はレイアウトに関連付けられているので、それらは、ファイルACLまたはモードは、優れた機能は、新しいアクセス許可を適用するために取り消さなければならない変更した場合、アクセス制御を適用するために使用されているので。サーバーは、クライアントが優雅にアクセス権限を変更する前にその機能を返すことができるようにレイアウトを思い出すべきです。
Each capability is specific to a particular object, an operation on that object, a byte range within the object (in OSDv2), and has an explicit expiration time. The capabilities are signed with a secret key that is shared by the object storage devices and the metadata managers. Clients do not have device keys so they are unable to forge the signatures in the security parameters. The combination of a capability, the OSD System ID, and a signature is called a "credential" in the OSD specification.
各機能は、そのオブジェクトに対する操作の特定のオブジェクトに固有である、（OSDv2における）オブジェクト内のバイト範囲、及び明示的な有効期限を有します。機能は、オブジェクト・ストレージ・デバイスとメタデータマネージャで共有されている秘密鍵で署名されています。彼らはセキュリティパラメータで署名を偽造することができないので、クライアントは、デバイス鍵を持っていません。能力、OSDシステムID、および署名の組合せは、OSDの明細書では「資格」と呼ばれます。
The details of the security and privacy model for object storage are defined in the T10 OSD standard. The following sketch of the algorithm should help the reader understand the basic model.
オブジェクトストレージのセキュリティとプライバシーモデルの詳細はT10 OSD標準で定義されています。アルゴリズムの次のスケッチは、読者が基本的なモデルを理解するのに役立つはずです。
LAYOUTGET returns a CapKey and a Cap, which, together with the OSD System ID, are also called a credential. It is a capability and a signature over that capability and the SystemID. The OSD Standard refers to the CapKey as the "Credential integrity check value" and to the ReqMAC as the "Request integrity check value".
LAYOUTGETはCapKeyと一緒にOSDシステムのIDと、また資格と呼ばれ、キャップを、返します。それは能力とその能力とシステムIDを超える署名です。 OSD規格は、「要求の整合性チェック値」と「資格整合性チェック値」としてCapKeyにしてReqMACを指します。
CapKey = MAC<SecretKey>(Cap, SystemID) Credential = {Cap, SystemID, CapKey}
CapKey = MAC <のSecretKey>（CAP、システムID）資格= {キャップ、システムID、CapKey}
The client uses CapKey to sign all the requests it issues for that object using the respective Cap. In other words, the Cap appears in the request to the storage device, and that request is signed with the CapKey as follows:
クライアントは、それがそれぞれのキャップを使用して、そのオブジェクトのために発行したすべての要求に署名するCapKeyを使用しています。換言すれば、キャップは、ストレージデバイスへの要求に表示され、次のようにその要求はCapKeyで署名されています。
ReqMAC = MAC<CapKey>(Req, ReqNonce) Request = {Cap, Req, ReqNonce, ReqMAC}
ReqMAC = MAC <CapKey>（必須、ReqNonce）要求= {キャップ、必須、ReqNonce、ReqMAC}
The following is sent to the OSD: {Cap, Req, ReqNonce, ReqMAC}. The OSD uses the SecretKey it shares with the metadata server to compare the ReqMAC the client sent with a locally computed value:
{キャップ、必須、ReqNonce、ReqMAC}：以下は、OSDに送信されます。 OSDは、それがローカルに計算した値で送信されたクライアントReqMACを比較するために、メタデータサーバと共有するのSecretKeyを使用しています。
LocalCapKey = MAC<SecretKey>(Cap, SystemID) LocalReqMAC = MAC<LocalCapKey>(Req, ReqNonce)
LocalCapKey = MAC <のSecretKey>（CAP、システムID）LocalReqMAC = MAC <LocalCapKey>（必須、ReqNonce）
and if they match the OSD assumes that the capabilities came from an authentic metadata server and allows access to the object, as allowed by the Cap.
それらが一致する場合とOSDは機能が本物のメタデータサーバから来て、キャップによって許可され、オブジェクトへのアクセスを許可することを前提としています。
Note that if the server LAYOUTGET reply, holding CapKey and Cap, is snooped by another client, it can be used to generate valid OSD requests (within the Cap access restrictions).
CapKeyとキャップを保持するサーバLAYOUTGET応答が、別のクライアントによって詮索されている場合、（キャップアクセス制限内で）有効なOSD要求を生成するために使用することができることに注意してください。
To provide the required privacy requirements for the capability key returned by LAYOUTGET, the GSS-API [7] framework can be used, e.g., by using the RPCSEC_GSS privacy method to send the LAYOUTGET operation or by using the SSV key to encrypt the oc_capability_key using the GSS_Wrap() function. Two general ways to provide privacy in the absence of GSS-API that are independent of NFSv4 are either an isolated network such as a VLAN or a secure channel provided by IPsec [15].
LAYOUTGETによって返された機能キーのために必要なプライバシー要件を提供するために、GSS-APIは、[7]の枠組みを使用してoc_capability_keyを暗号化するために、例えば、LAYOUTGET操作を送信するためにRPCSEC_GSSプライバシー法を使用して、またはSSVキーを使用して、使用することができますGSS_Wrap（）関数。 NFSv4の独立しているGSS-APIの非存在下でのプライバシーを提供するための2つの一般的な方法は、VLANなどの単離されたネットワークやIPsec [15]によって提供される安全なチャネルのいずれかです。
At any time, the metadata server may invalidate all outstanding capabilities on an object by changing its POLICY ACCESS TAG attribute. The value of the POLICY ACCESS TAG is part of a capability, and it must match the state of the object attribute. If they do not match, the OSD rejects accesses to the object with the sense key set to ILLEGAL REQUEST and an additional sense code set to INVALID FIELD IN CDB. When a client attempts to use a capability and is rejected this way, it should issue a LAYOUTCOMMIT for the object and specify PNFS_OSD_BAD_CRED in the olr_ioerr_report parameter. The client may elect to issue a compound LAYOUTRETURN/LAYOUTGET (or LAYOUTCOMMIT/LAYOUTRETURN/LAYOUTGET) to attempt to fetch a refreshed set of capabilities.
いつでも、メタデータサーバは、そのポリシーのアクセスタグ属性を変更することにより、オブジェクトのすべての優れた機能を無効にすることができます。ポリシーアクセスタグの値は、機能の一部であり、それはオブジェクト属性の状態と一致しなければなりません。それらが一致しない場合は、OSDはILLEGAL REQUESTとCDB内の無効なフィールドに設定され、追加のセンスコードに設定されたセンスキーを持つオブジェクトへのアクセスを拒否します。クライアントが機能を使用しようとすると、このように拒否された場合、そのオブジェクトのためのLAYOUTCOMMITを発行し、olr_ioerr_reportパラメータでPNFS_OSD_BAD_CREDを指定する必要があります。クライアントは、能力のリフレッシュセットをフェッチしようとする化合物LAYOUTRETURN / LAYOUTGET（またはLAYOUTCOMMIT / LAYOUTRETURN / LAYOUTGET）を発行することを選択することができます。
The metadata server may elect to change the access policy tag on an object at any time, for any reason (with the understanding that there is likely an associated performance penalty, especially if there are outstanding layouts for this object). The metadata server MUST revoke outstanding capabilities when any one of the following occurs:
メタデータサーバは、（このオブジェクトのための優れたレイアウトがある場合は特に、関連するパフォーマンスペナルティがありそうであることを理解した上で）何らかの理由で、任意の時点でのオブジェクトのアクセスポリシータグを変更することを選ぶことができます。以下のいずれかが発生したときに、メタデータ・サーバは、優れた機能を取り消す必要があり：
o the permissions on the object change,
オブジェクト変更の権限O、
o a conflicting mandatory byte-range lock is granted, or
競合必須バイト範囲ロックが付与され、O、または
o a layout is revoked and reassigned to another client.
Oレイアウトが取り消され、別のクライアントに再割り当てされます。
A pNFS client will typically hold one layout for each byte range for either READ or READ/WRITE. The client's credentials are checked by the metadata server at LAYOUTGET time and it is the client's responsibility to enforce access control among multiple users accessing the same file. It is neither required nor expected that the pNFS client will obtain a separate layout for each user accessing a shared object. The client SHOULD use OPEN and ACCESS calls to check user permissions when performing I/O so that the server's access control policies are correctly enforced. The result of the ACCESS operation may be cached while the client holds a valid layout as the server is expected to recall layouts when the file's access permissions or ACL change.
pNFSのクライアントは、通常、READまたはREAD / WRITEのいずれかのために各バイトの範囲のための1つのレイアウトを保持します。クライアントの資格情報はLAYOUTGET時にメタデータ・サーバによってチェックされ、同じファイルにアクセスする複数のユーザー間でのアクセス制御を強化するために、クライアントの責任です。それは必要としないものpNFSクライアントが共有オブジェクトにアクセスするユーザーごとに個別のレイアウトを取得することが予想もされていません。クライアントがOPEN使用すべきであるとACCESSは、サーバのアクセス制御ポリシーが正しく適用されるように、I / Oを実行するときに、ユーザーのアクセス権を確認するために呼び出します。クライアントが有効なレイアウトを保持しているサーバがレイアウトをリコールすることが予想されるとして、アクセス動作の結果がキャッシュされるとき、ファイルのアクセス権限やACLの変更。
As described in NFSv4.1 [6], new layout type numbers have been assigned by IANA. This document defines the protocol associated with the existing layout type number, LAYOUT4_OSD2_OBJECTS, and it requires no further actions for IANA.
NFSv4.1 [6]に記載のように、新しいレイアウトタイプ番号は、IANAによって割り当てられています。この文書では、既存のレイアウトタイプ番号、LAYOUT4_OSD2_OBJECTSに関連するプロトコルを定義し、それはIANAのためのさらなるアクションを必要としません。
[1] Weber, R., "Information Technology - SCSI Object-Based Storage Device Commands (OSD)", ANSI INCITS 400-2004, December 2004.
[1]ウェーバー、R.、 "情報技術 - SCSIオブジェクトベースのストレージ・デバイス・コマンド（OSD）"、ANSI INCITS 400から2004まで、2004年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Eisler, M., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[3]アイスラー、M.、 "XDR：外部データ表現標準"、STD 67、RFC 4506、2006年5月。
[4] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", RFC 5662, January 2010.
[4] Shepler、S.編、アイスラー、M.、編、及びD. Noveck編、 "ネットワークファイルシステム（NFS）バージョン4マイナーバージョン1外部データ表現標準（XDR）の説明"、RFC 5662、2010年1月。
[5] IETF Trust, "Legal Provisions Relating to IETF Documents", November 2008, <http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>.
[5] IETFトラスト、2008年11月、 "IETFドキュメントに関連法規定"、<http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>。
[6] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
[6] Shepler、S.編、アイスラー、M.、編、及びD. Noveck編、 "ネットワークファイルシステム（NFS）バージョン4マイナーバージョン1つのプロトコル"、RFC 5661、2010年1月。
[7] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[7]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[8] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[8] Satran、J.、メタ、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、 "インターネットの小さいコンピュータシステム（のiSCSI）"、RFC 3720、2004年4月。
[9] Weber, R., "SCSI Primary Commands - 3 (SPC-3)", ANSI INCITS 408-2005, October 2005.
[9]ウェーバー、R.、 "SCSIプライマリコマンド - 3（SPC-3）"、ANSI INCITS 408から2005まで、2005年10月。
[10] Krueger, M., Chadalapaka, M., and R. Elliott, "T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names", RFC 3980, February 2005.
[10]クルーガー、M.、Chadalapaka、M.、およびR.エリオット、RFC 3980、2005年2月 "T11ネットワーク局（NAA）のiSCSIノード名の形式を命名アドレス"。
[11] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", <http://standards.ieee.org/regauth/oui/tutorials/EUI64.html>.
<http://standards.ieee.org/regauth/oui/tutorials/EUI64.html> [11] IEEE、 "64ビットのグローバル識別子（EUI-64）登録機関のためのガイドライン"。
[12] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.
[12]ツェン、J.、ギボンズ、K.、Travostino、F.、デュレイニー、C.、およびJ. Souzaの、 "インターネットストレージネームサービス（iSNSの）"、RFC 4171、2005年9月。
[13] Weber, R., "SCSI Architecture Model - 3 (SAM-3)", ANSI INCITS 402-2005, February 2005.
[13]ウェーバー、R.、 "SCSIアーキテクチャモデル - 3（SAM-3）"、ANSI INCITS 402から2005、2005年2月。
[14] Weber, R., "SCSI Object-Based Storage Device Commands -2 (OSD-2)", January 2009, <http://www.t10.org/cgi-bin/ac.pl?t=f&f=osd2r05a.pdf>.
[14]ウェーバー、R.は、 "SCSIオブジェクトベースのストレージデバイスはコマンド-2（OSD-2）" 2009年1月、<http://www.t10.org/cgi-bin/ac.pl?t=f&f = osd2r05a.pdf>。
[15] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[15]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[16] T10 1415-D, "SCSI RDMA Protocol (SRP)", ANSI INCITS 365-2002, December 2002.
[16] T10 1415-D、 "SCSI RDMAプロトコル（SRP）"、ANSI INCITS 365から2002まで、2002年12月。
[17] T11 1619-D, "Fibre Channel Framing and Signaling - 2 (FC-FS-2)", ANSI INCITS 424-2007, February 2007.
[17] T11 1619-D、 "ファイバチャネルフレーミングとシグナリング - 2（FC-FS-2）"、ANSI INCITS 424から2007、2007年2月。
[18] T10 1601-D, "Serial Attached SCSI - 1.1 (SAS-1.1)", ANSI INCITS 417-2006, June 2006.
[18] T10 1601-D、 "シリアルアタッチドSCSI - 1.1（SAS-1.1）"、ANSI INCITS 417から2006まで、2006年6月。
[19] MacWilliams, F. and N. Sloane, "The Theory of Error-Correcting Codes, Part I", 1977.
[19] MacWilliams、F.およびN.スローン、 "誤り訂正符号の理論、パートI"、1977年。
Appendix A. Acknowledgments
付録A.謝辞
Todd Pisek was a co-editor of the initial versions of this document. Daniel E. Messinger, Pete Wyckoff, Mike Eisler, Sean P. Turner, Brian E. Carpenter, Jari Arkko, David Black, and Jason Glasgow reviewed and commented on this document.
トッド・セックは、このドキュメントの初期バージョンの共同編集者でした。ダニエルE. Messinger、ピート・ワイコフ、マイク・アイスラー、ショーン・P.ターナー、ブライアンE.カーペンター、ヤリArkko、デビッド・ブラック、およびジェイソングラスゴーの見直しと、この文書についてコメントしました。
Authors' Addresses
著者のアドレス
Benny Halevy Panasas, Inc. 1501 Reedsdale St. Suite 400 Pittsburgh, PA 15233 USA
ベニー・アレヴィPanasasの株式会社1501 Reedsdaleセントスイート400ピッツバーグ、PA 15233 USA
Phone: +1-412-323-3500 EMail: bhalevy@panasas.com URI: http://www.panasas.com/
電話：+ 1-412-323-3500 Eメール：bhalevy@panasas.com URI：http://www.panasas.com/
Brent Welch Panasas, Inc. 6520 Kaiser Drive Fremont, CA 95444 USA
ブレントウェルチPanasasの株式会社6520カイザードライブフリーモント、CA 95444 USA
Phone: +1-510-608-7770 EMail: welch@panasas.com URI: http://www.panasas.com/
電話：+ 1-510-608-7770 Eメール：welch@panasas.com URI：http://www.panasas.com/
Jim Zelenka Panasas, Inc. 1501 Reedsdale St. Suite 400 Pittsburgh, PA 15233 USA
ジム・ゼレンカPanasasの株式会社1501 Reedsdaleセントスイート400ピッツバーグ、PA 15233 USA
Phone: +1-412-323-3500 EMail: jimz@panasas.com URI: http://www.panasas.com/
電話：+ 1-412-323-3500 Eメール：jimz@panasas.com URI：http://www.panasas.com/