Internet Engineering Task Force (IETF) J. Lentini
Request for Comments: 5716 C. Everhart
Category: Informational NetApp
ISSN: 2070-1721 D. Ellard
BBN Technologies
R. Tewari
M. Naik
IBM Almaden
January 2010
Internet Engineering Task Force (IETF) J. Lentini
Request for Comments: 5716 C. Everhart
Category: Informational NetApp
ISSN: 2070-1721 D. Ellard
BBN Technologies
R. Tewari
M. Naik
IBM Almaden
January 2010
Requirements for Federated File Systems
联邦文件系统的要求
Abstract
摘要
This document describes and lists the functional requirements of a federated file system and defines related terms.
本文档描述并列出了联邦文件系统的功能需求，并定义了相关术语。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc5716.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5716.
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Overview ........................................................3
1.1. Requirements Language ......................................4
2. Purpose .........................................................5
3. Examples and Discussion .........................................5
3.1. Create a Fileset and Its FSL(s) ............................5
3.1.1. Creating a Fileset and an FSN .......................6
3.1.2. Adding a Replica of a Fileset .......................6
3.2. Junction Resolution ........................................7
3.3. Junction Creation ..........................................9
4. Glossary ........................................................9
5. Proposed Requirements ..........................................11
5.1. Basic Assumptions .........................................11
5.2. Requirements ..............................................14
6. Non-Requirements ...............................................20
7. Security Considerations ........................................21
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
Appendix A. Acknowledgments ......................................25
1. Overview ........................................................3
1.1. Requirements Language ......................................4
2. Purpose .........................................................5
3. Examples and Discussion .........................................5
3.1. Create a Fileset and Its FSL(s) ............................5
3.1.1. Creating a Fileset and an FSN .......................6
3.1.2. Adding a Replica of a Fileset .......................6
3.2. Junction Resolution ........................................7
3.3. Junction Creation ..........................................9
4. Glossary ........................................................9
5. Proposed Requirements ..........................................11
5.1. Basic Assumptions .........................................11
5.2. Requirements ..............................................14
6. Non-Requirements ...............................................20
7. Security Considerations ........................................21
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
Appendix A. Acknowledgments ......................................25
This document describes and lists the functional requirements of a federated file system and defines related terms.
本文档描述并列出了联邦文件系统的功能需求，并定义了相关术语。
We do not describe the mechanisms that might be used to implement this functionality except in cases where specific mechanisms, in our opinion, follow inevitably from the requirements. Our focus is on the interfaces between the entities of the system, not on the protocols or their implementations.
我们不描述可能用于实现此功能的机制，除非我们认为特定机制不可避免地遵循需求。我们的重点是系统实体之间的接口，而不是协议或它们的实现。
Today, there are collections of fileservers that inter-operate to provide a single namespace comprised of filesystem resources provided by different members of the collection, joined together with inter-filesystem references. The namespace can either be assembled at the fileservers, the clients, or by an external namespace service, and is often not easy or uniform to manage. The requirements in this document are meant to lead to a uniform server-based namespace that is capable of spanning a whole enterprise and that is easy to manage.
今天，有一些文件服务器集合，它们相互操作以提供一个名称空间，该名称空间由集合的不同成员提供的文件系统资源组成，并与文件系统间引用结合在一起。名称空间可以在文件服务器、客户机上组装，也可以由外部名称空间服务组装，通常不容易管理或统一管理。本文档中的要求旨在形成一个统一的基于服务器的名称空间，该名称空间能够跨越整个企业，并且易于管理。
We define some terms to better describe the solution space. A "fileset" is the abstract view of a filesystem in a uniform namespace, and may be implemented behind that abstraction by one or more physical filesystems at any given time. Each fileset has a name called an "FSN" (fileset name), and each physical filesystem has a fileset location ("FSL"). A fileset is a directory tree containing files and directories, and it may also contain references to other filesets. These references are called "junctions". To provide location independence, a junction does not contain information about the location of the real resource(s), but instead contains an FSN that can be used to look up the location information. The service that can be used to map from the FSN to the FSL(s) is called a namespace database (NSDB) service. The NSDB provides a level of indirection from the virtual paths in the uniform namespace to the actual locations of files. By design, the NSDB does not store the junctions. This allows junction administration and NSDB administration to be separate roles.
我们定义了一些术语来更好地描述解空间。“文件集”是统一名称空间中文件系统的抽象视图，可以在任何给定时间由一个或多个物理文件系统在该抽象之后实现。每个文件集都有一个名为“FSN”（文件集名），每个物理文件系统都有一个文件集位置（“FSL”）。文件集是包含文件和目录的目录树，也可能包含对其他文件集的引用。这些引用称为“连接”。为了提供位置独立性，连接不包含有关实际资源位置的信息，而是包含可用于查找位置信息的FSN。可用于从FSN映射到FSL的服务称为命名空间数据库（NSDB）服务。NSDB提供了从统一名称空间中的虚拟路径到文件实际位置的间接级别。根据设计，NSDB不存储连接。这使得连接管理和NSDB管理成为独立的角色。
The servers direct clients to the proper locations by existing mechanisms (e.g., the referrals mechanism within [RFC3530] and [RFC5661]). Updates to the locations make it possible to support migration and replication of physical filesystems that comprise the namespace, in a way that is transparent to filesystem applications.
服务器通过现有机制（例如，[RFC3530]和[RFC5661]中的转介机制）将客户端定向到适当的位置。这些位置的更新使得能够以一种对文件系统应用程序透明的方式支持组成名称空间的物理文件系统的迁移和复制。
Figure 1 shows an example of a federation. This federation has two members, named ALPHA and BETA. Federation members may contain an arbitrary number of fileservers and NSDB nodes; in this illustration, ALPHA and BETA each have three servers, one NSDB node, and are administered separately.
图1显示了一个联合的示例。这个联盟有两个成员，分别是ALPHA和BETA。联盟成员可以包含任意数量的文件服务器和NSDB节点；在本图中，ALPHA和BETA各有三台服务器、一个NSDB节点，并分别进行管理。
+----------------------+ +----------------------+
| Federation Member | | Federation Member |
| ALPHA | | BETA |
| | | |
| | | |
| +------------+ | | +------------+ |
| | NSDB | | | | NSDB | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| | | |
| +----------+ | | +----------+ |
| | | | | | | |
| +-- | Servers | | | +-- | Servers | |
| | | | | | | | | |
| +-- | | | | | +-- | | | |
| | | +----------+ | | | | +----------+ |
| | | | | | | | | |
| | +----------+ | | | +----------+ |
| | | | | | | |
| +----------+ | | +----------+ |
+----------------------+ +----------------------+
+----------------------+ +----------------------+
| Federation Member | | Federation Member |
| ALPHA | | BETA |
| | | |
| | | |
| +------------+ | | +------------+ |
| | NSDB | | | | NSDB | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| | | |
| +----------+ | | +----------+ |
| | | | | | | |
| +-- | Servers | | | +-- | Servers | |
| | | | | | | | | |
| +-- | | | | | +-- | | | |
| | | +----------+ | | | | +----------+ |
| | | | | | | | | |
| | +----------+ | | | +----------+ |
| | | | | | | |
| +----------+ | | +----------+ |
+----------------------+ +----------------------+
Figure 1
图1
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Note that this is a requirements document, and in many instances where these words are used in this document they refer to qualities of a specification for a system that satisfies the document, or requirements of a system that matches that specification. These cases are distinguished when there is potential for ambiguity.
请注意，这是一份需求文件，在本文件中使用这些词的许多情况下，它们指的是满足该文件的系统规范的质量，或符合该规范的系统要求。当可能存在歧义时，可区分这些情况。
Our objective is to specify a set of protocols by which fileservers or collections of fileservers, with different administrators, can form a federation of fileservers and NSDB nodes that provides a namespace composed of the filesets hosted on the different fileservers and fileserver collections.
我们的目标是指定一组协议，通过这些协议，具有不同管理员的文件服务器或文件服务器集合可以形成文件服务器和NSDB节点的联盟，该联盟提供由托管在不同文件服务器和文件服务器集合上的文件集组成的命名空间。
It should be possible, using a system that implements the protocols, to share a common namespace across all the fileservers in the federation. It should also be possible for different fileservers in the federation to project different namespaces and enable clients to traverse them.
应该可以使用实现协议的系统在联合体中的所有文件服务器之间共享一个公共名称空间。联盟中的不同文件服务器也应该可以投影不同的名称空间，并使客户端能够遍历它们。
Such a federation may contain an arbitrary number of NSDB nodes, each belonging to a different administrative entity, and each providing the mappings that define a part of a namespace. Such a federation may also have an arbitrary number of administrative entities, each responsible for administering a subset of the fileservers and NSDB nodes. Acting in concert, the administrators should be able to build and administer this multi-fileserver, multi-collection namespace.
这样的联合可以包含任意数量的NSDB节点，每个节点属于不同的管理实体，并且每个节点提供定义命名空间一部分的映射。这样的联合还可以具有任意数量的管理实体，每个管理实体负责管理文件服务器和NSDB节点的子集。协同工作，管理员应该能够构建和管理这个多文件服务器、多集合名称空间。
It is not the intent of the federation to guarantee namespace consistency across all client views. Since different parts of the namespace may be administered by different entities, it is possible that a client could be accessing a stale area of the namespace managed by one entity because a part of the namespace above it, managed by another entity, has changed.
联合的目的不是保证所有客户端视图的命名空间一致性。由于名称空间的不同部分可能由不同的实体管理，因此客户机可能正在访问由一个实体管理的名称空间的过时区域，因为其上方由另一个实体管理的名称空间的一部分已更改。
In this section we provide examples and discussion of the basic operations facilitated by the federated file system protocol: creating a fileset, adding a replica of a fileset, resolving a junction, and creating a junction.
在本节中，我们提供了联邦文件系统协议促进的基本操作的示例和讨论：创建文件集、添加文件集副本、解析连接和创建连接。
A fileset is the abstraction of a set of files and the directory tree that contains them. The fileset abstraction is the fundamental unit of data management in the federation. This abstraction is implemented by an actual directory tree whose root location is specified by a fileset location (FSL).
文件集是一组文件和包含它们的目录树的抽象。文件集抽象是联邦中数据管理的基本单元。此抽象由实际目录树实现，其根位置由文件集位置（FSL）指定。
In this section, we describe the basic requirements for starting with a directory tree and creating a fileset that can be used in the federation protocols. Note that we do not assume that the process of creating a fileset requires any transformation of the files or the
在本节中，我们将描述从目录树开始并创建可在联合协议中使用的文件集的基本要求。注意，我们并不认为创建文件集的过程需要对文件或
directory hierarchy. The only thing that is required by this process is assigning the fileset a fileset name (FSN) and expressing the location(s) of the implementation of the fileset as FSL(s).
目录层次结构。这个过程唯一需要的是为文件集分配一个文件集名称（FSN），并将文件集实现的位置表示为FSL。
There are many possible variations to this procedure, depending on how the FSN that binds the FSL is created, and whether other replicas of the fileset exist, are known to the federation, and need to be bound to the same FSN.
此过程有许多可能的变体，具体取决于绑定FSL的FSN是如何创建的，以及文件集的其他副本是否存在，联邦是否知道，并且是否需要绑定到同一FSN。
It is easiest to describe this in terms of how to create the initial implementation of the fileset, and then describe how to add replicas.
最简单的描述是如何创建文件集的初始实现，然后描述如何添加副本。
1. Choose the NSDB node that will keep track of the FSL(s) and related information for the fileset.
1. 选择将跟踪文件集的FSL和相关信息的NSDB节点。
2. Request that the NSDB node register a new FSN for the fileset.
2. 请求NSDB节点为文件集注册新的FSN。
The FSN may either be chosen by the NSDB node or by the server. The latter case is used if the fileset is being restored, perhaps as part of disaster recovery, and the server wishes to specify the FSN in order to permit existing junctions that reference that FSN to work again.
FSN可以由NSDB节点选择，也可以由服务器选择。如果正在恢复文件集（可能是作为灾难恢复的一部分），并且服务器希望指定FSN以允许引用该FSN的现有连接再次工作，则使用后一种情况。
At this point, the FSN exists, but its location is unspecified.
此时，FSN存在，但其位置未指定。
3. Send the FSN, the local volume path, the export path, and the export options for the local implementation of the fileset to the NSDB node. Annotations about the FSN or the location may also be sent.
3. 将文件集本地实现的FSN、本地卷路径、导出路径和导出选项发送到NSDB节点。还可以发送关于FSN或位置的注释。
The NSDB node records this information and creates the initial FSL for the fileset.
NSDB节点记录此信息并为文件集创建初始FSL。
Adding a replica is straightforward: the NSDB node and the FSN are already known. The only remaining step is to add another FSL.
添加复制副本很简单：NSDB节点和FSN已经知道了。剩下的唯一步骤是添加另一个FSL。
Note that the federation protocols do not include methods for creating or managing replicas: this is assumed to be a platform-dependent operation (at least at this time). The only requirement is that these fileset replicas be registered and unregistered with the NSDB.
请注意，联合协议不包括用于创建或管理副本的方法：假定这是一个依赖于平台的操作（至少目前是这样）。唯一的要求是在NSDB中注册和注销这些文件集副本。
A fileset may contain references to other filesets. These references are represented by junctions. If a client requests access to a fileset object that is a junction, the server resolves the junction to discover the FSL(s) that implements the referenced fileset.
文件集可能包含对其他文件集的引用。这些参照由连接表示。如果客户端请求访问作为连接的文件集对象，服务器将解析该连接以发现实现所引用文件集的FSL。
There are many possible variations to this procedure, depending on how the junctions are represented and how the information necessary to perform resolution is represented by the server.
此过程有许多可能的变化，具体取决于如何表示连接以及服务器如何表示执行解析所需的信息。
Step 4 is the only step that interacts directly with the federation protocols. The rest of the steps may use platform-specific interfaces.
步骤4是与联合协议直接交互的唯一步骤。其余步骤可能使用特定于平台的接口。
1. The server determines that the object being accessed is a junction.
1. 服务器确定正在访问的对象是连接。
2. Using the junction, the server does a local lookup to find the FSN of the target fileset.
2. 服务器使用连接进行本地查找，以查找目标文件集的FSN。
3. Using the FSN, the server finds the NSDB node responsible for the target object.
3. 服务器使用FSN查找负责目标对象的NSDB节点。
4. The server contacts that NSDB node and asks for the set of FSLs that implement the target FSN. The NSDB node responds with a set of FSLs.
4. 服务器联系该NSDB节点并请求实现目标FSN的FSL集。NSDB节点使用一组FSL进行响应。
5. The server converts one or more of the FSLs to the location type used by the client (e.g., a Network File System (NFSv4) fs_location, as described in [RFC3530]).
5. 服务器将一个或多个FSL转换为客户端使用的位置类型（例如，网络文件系统（NFSv4）fs_位置，如[RFC3530]中所述）。
6. The server redirects (in whatever manner is appropriate for the client) the client to the location(s).
6. 服务器将客户端重定向（以适合客户端的任何方式）到该位置。
These steps are illustrated in Figure 2. The client sends request 1 to server X, in federation member ALPHA, in an attempt to reference an object (which appears to the client as a directory). Server X recognizes that the referenced object is actually a junction that refers to a directory in a different fileset. Server X finds, from the FSN in the junction, that the NSDB responsible for knowing the location of the target of the junction is the NSDB of federation member BETA. Server X sends request 2 to the NSDB of BETA, asking for the current location of the directory. The NSDB sends response 3 to server X, telling the server that the directory is located on server Y. Server X sends response 4 to the client, indicating that the directory is in a "new" location on server Y. The client then sends request 5 to server Y, repeating the initial request.
这些步骤如图2所示。客户端将请求1发送到服务器X（位于联盟成员ALPHA中），以尝试引用一个对象（在客户端看来是一个目录）。ServerX识别出被引用的对象实际上是一个连接，它引用了不同文件集中的目录。服务器X从连接中的FSN中发现，负责知道连接目标位置的NSDB是联盟成员BETA的NSDB。服务器X向测试版的NSDB发送请求2，询问目录的当前位置。NSDB向服务器X发送响应3，告知服务器该目录位于服务器Y上。服务器X向客户端发送响应4，指示该目录位于服务器Y上的“新”位置。然后，客户端向服务器Y发送请求5，重复初始请求。
Given the current requirements and definitions, this resolution method MUST work. However, there is no requirement that this is the only resolution method that can be used. This method may be used as the fallback when all else fails (or, for a simple implementation, it could be the only method). This is a degenerate implementation of the NSDB service as a simple composition of NSDB nodes; we expect that large federations will use more sophisticated methods to share the FSN and FSL information among multiple NSDB nodes.
鉴于当前的要求和定义，这种解决方法必须有效。但是，不要求这是唯一可以使用的分辨率方法。当所有其他方法都失败时，此方法可以用作回退（或者，对于简单的实现，它可能是唯一的方法）。这是NSDB服务的退化实现，作为NSDB节点的简单组合；我们预计，大型联合会将使用更复杂的方法在多个NSDB节点之间共享FSN和FSL信息。
+---------------+
| |
| Client | >--------------------------+
| | |
+---------------+ |
v ^ |
+-----+---+-------------+ +-----------------+-----+
| | | Federation| |Federation | |
| | | member | |member | |
| | | ALPHA | |BETA | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | +---------+ | |
| | | +---------+------+-> | | | |
| | | | | | | NSDB Y | | |
| | | | +-----+------+-< | | | |
| | | | | | | +---------+ | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| 1| 4| 2| 3| | | 5| |
| v ^ ^ v | | v |
| +---------------+ | | +---------------+ |
| | | | | | | |
| | Server X | | | | Server Y | |
| | | | | | | |
| +---------------+ | | +---------------+ |
| | | |
+-----------------------+ +-----------------------+
+---------------+
| |
| Client | >--------------------------+
| | |
+---------------+ |
v ^ |
+-----+---+-------------+ +-----------------+-----+
| | | Federation| |Federation | |
| | | member | |member | |
| | | ALPHA | |BETA | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | +---------+ | |
| | | +---------+------+-> | | | |
| | | | | | | NSDB Y | | |
| | | | +-----+------+-< | | | |
| | | | | | | +---------+ | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| 1| 4| 2| 3| | | 5| |
| v ^ ^ v | | v |
| +---------------+ | | +---------------+ |
| | | | | | | |
| | Server X | | | | Server Y | |
| | | | | | | |
| +---------------+ | | +---------------+ |
| | | |
+-----------------------+ +-----------------------+
Figure 2
图2
Given a local path and the FSN of a remote fileset, an administrator can create a junction from the local path to the remote fileset.
给定远程文件集的本地路径和FSN，管理员可以创建从本地路径到远程文件集的连接。
There are many possible variations to this procedure, depending on how the junctions are represented and how the information necessary to perform resolution is represented by the server.
此过程有许多可能的变化，具体取决于如何表示连接以及服务器如何表示执行解析所需的信息。
Step 1 is the only step that uses the federation interfaces. The remaining step may use platform-specific interfaces.
步骤1是使用联合接口的唯一步骤。其余步骤可能使用特定于平台的接口。
1. The administrator requests the server create a junction to the FSN of the remote fileset at the given path.
1. 管理员请求服务器在给定路径处创建到远程文件集的FSN的连接。
2. The server inserts the junction to the FSN, at the given path, into the local filesystem.
2. 服务器在给定的路径上将FSN的连接插入本地文件系统。
Administrator: user with the necessary authority to initiate administrative tasks on one or more servers.
管理员：具有在一台或多台服务器上启动管理任务所需权限的用户。
Admin Entity: A server or agent that administers a collection of fileservers and persistently stores the namespace information.
管理实体：管理文件服务器集合并持久存储名称空间信息的服务器或代理。
Client: Any client that accesses the fileserver data using a supported filesystem access protocol.
客户端：使用受支持的文件系统访问协议访问文件服务器数据的任何客户端。
Federation: A set of server collections and singleton servers that use a common set of interfaces and protocols in order to provide to their clients a federated namespace accessible through a filesystem access protocol.
联合：一组服务器集合和单例服务器，它们使用一组通用的接口和协议，以便向其客户机提供一个通过文件系统访问协议访问的联合命名空间。
Fileserver: A server exporting a filesystem via a network filesystem access protocol.
文件服务器：通过网络文件系统访问协议导出文件系统的服务器。
Fileset: The abstraction of a set of files and the directory tree that contains them. A fileset is the fundamental unit of data management in the federation.
文件集：一组文件和包含它们的目录树的抽象。文件集是联合体中数据管理的基本单元。
Note that all files within a fileset are descendants of one directory, and that filesets do not span filesystems.
请注意，文件集中的所有文件都是一个目录的后代，并且文件集不跨文件系统。
Filesystem: A self-contained unit of export for a fileserver, and the mechanism used to implement filesets. The fileset does not need to be rooted at the root of the filesystem, nor at the export point for the filesystem.
文件系统：文件服务器的自包含导出单元，以及用于实现文件集的机制。文件集不需要在文件系统的根目录下，也不需要在文件系统的导出点上。
A single filesystem MAY implement more than one fileset, if the client protocol and the fileserver permit this.
如果客户机协议和文件服务器允许，单个文件系统可以实现多个文件集。
Filesystem Access Protocol: A network filesystem access protocol such as NFSv2 [RFC1094], NFSv3 [RFC1813], NFSv4 [RFC3530], or CIFS (Common Internet File System) [MS-SMB] [MS-SMB2] [MS-CIFS].
文件系统访问协议：网络文件系统访问协议，如NFSv2[RFC1094]、NFSv3[RFC1813]、NFSv4[RFC3530]或CIFS（通用Internet文件系统）[MS-SMB][MS-SMB2][MS-CIFS]。
FSL (Fileset Location): The location of the implementation of a fileset at a particular moment in time. An FSL MUST be something that can be translated into a protocol-specific description of a resource that a client can access directly, such as an fs_location (for NFSv4), or share name (for CIFS). Note that not all FSLs need to be explicitly exported as long as they are contained within an exported path on the fileserver.
FSL（文件集位置）：文件集在特定时刻的实现位置。FSL必须能够转换为客户端可以直接访问的资源的特定于协议的描述，例如fs_位置（对于NFSv4）或共享名称（对于CIFS）。请注意，只要FSL包含在文件服务器上的导出路径中，就不需要显式导出所有FSL。
FSN (Fileset Name): A platform-independent and globally unique name for a fileset. Two FSLs that implement replicas of the same fileset MUST have the same FSN, and if a fileset is migrated from one location to another, the FSN of that fileset MUST remain the same.
FSN（文件集名称）：文件集的独立于平台且全局唯一的名称。实现相同文件集副本的两个FSL必须具有相同的FSN，如果文件集从一个位置迁移到另一个位置，则该文件集的FSN必须保持不变。
Junction: A filesystem object used to link a directory name in the current fileset with an object within another fileset. The server-side "link" from a leaf node in one fileset to the root of another fileset.
连接：一个文件系统对象，用于将当前文件集中的目录名与另一个文件集中的对象链接。从一个文件集中的叶节点到另一个文件集的根节点的服务器端“链接”。
Namespace: A filename/directory tree that a sufficiently authorized client can observe.
名称空间：一个文件名/目录树，一个经过充分授权的客户端可以观察到它。
NSDB (Namespace Database) Service: A service that maps FSNs to FSLs. The NSDB may also be used to store other information, such as annotations for these mappings and their components.
NSDB（名称空间数据库）服务：将FSN映射到FSL的服务。NSDB还可用于存储其他信息，例如这些映射及其组件的注释。
NSDB Node: The name or location of a server that implements part of the NSDB service and is responsible for keeping track of the FSLs (and related info) that implement a given partition of the FSNs.
NSDB节点：实现部分NSDB服务并负责跟踪实现FSN给定分区的FSL（及相关信息）的服务器的名称或位置。
Referral: A server response to a client access that directs the client to evaluate the current object as a reference to an object at a different location (specified by an FSL) in another fileset, and possibly hosted on another fileserver. The client re-attempts the access to the object at the new location.
引用：对客户端访问的服务器响应，指示客户端将当前对象作为对另一个文件集中不同位置（由FSL指定）的对象的引用进行评估，该位置可能位于另一个文件服务器上。客户端在新位置重新尝试访问对象。
Replica: A replica is a redundant implementation of a fileset. Each replica shares the same FSN, but has a different FSL.
副本：副本是文件集的冗余实现。每个复制副本共享相同的FSN，但具有不同的FSL。
Replicas may be used to increase availability or performance. Updates to replicas of the same fileset MUST appear to occur in the same order, and therefore each replica is self-consistent at any moment.
副本可用于提高可用性或性能。对同一文件集的副本的更新必须以相同的顺序进行，因此每个副本在任何时候都是自一致的。
We do not assume that updates to each replica occur simultaneously. If a replica is offline or unreachable, the other replicas may be updated.
我们不假设对每个复制副本的更新同时发生。如果某个复制副本脱机或无法访问，则可能会更新其他复制副本。
Server Collection: A set of fileservers administered as a unit. A server collection may be administered with vendor-specific software.
服务器集合：作为一个单元管理的一组文件服务器。可以使用特定于供应商的软件管理服务器集合。
The namespace provided by a server collection could be part of the federated namespace.
服务器集合提供的命名空间可以是联合命名空间的一部分。
Singleton Server: A server collection containing only one server; a stand-alone fileserver.
单例服务器：仅包含一台服务器的服务器集合；独立文件服务器。
The phrase "USING THE FEDERATION INTERFACES" implies that the subsequent requirement must be satisfied, in its entirety, via the federation interfaces.
短语“使用联合接口”意味着必须通过联合接口整体满足后续需求。
Note that the requirements are described in terms of correct behavior by all entities. We do not address the requirements of the system in the presence of faults.
请注意，需求是根据所有实体的正确行为来描述的。我们不满足存在故障时的系统要求。
Several of the requirements are so fundamental that we treat them as basic assumptions; if any of these assumptions are violated, the rest of the requirements must be reviewed in their entirety.
其中一些要求非常基本，我们将其视为基本假设；如果违反了这些假设中的任何一个，则必须对其余要求进行全面审查。
A1: The federation protocols do not require any changes to existing client-facing protocols, and MAY be extended to incorporate new client-facing protocols.
A1：联合协议不需要对现有的面向客户端协议进行任何更改，并且可以扩展以合并新的面向客户端协议。
A2: A client SHOULD NOT require any a priori knowledge of the general structure or composition of the federation.
A2：客户不应要求对联盟的总体结构或组成有任何先验知识。
The client may require some specific knowledge in order to find and access an instance of the fileset that defines the root of its view of the namespace. As the client traverses the namespace, the client discovers the information it needs in order to locate the filesets it accesses.
客户机可能需要一些特定的知识来查找和访问定义其命名空间视图根的文件集实例。当客户机遍历名称空间时，客户机会发现它需要的信息，以便找到它访问的文件集。
A3: All requirements MUST be satisfiable via the federation protocols and the standard protocols used by the fileservers (i.e., NFS, CIFS, DNS, etc.).
A3：必须通过联合协议和文件服务器使用的标准协议（即NFS、CIFS、DNS等）满足所有要求。
USING THE FEDERATION INTERFACES, a federation operation that requires an interaction between two (or more) entities that are members of the federation MUST be possible without requiring any proprietary protocols.
使用联合接口，需要作为联合成员的两个（或多个）实体之间交互的联合操作必须是可能的，而不需要任何专有协议。
A4: All the entities participating in a federation operation MUST be able to authenticate each other.
A4：参与联合操作的所有实体必须能够相互验证。
All principals (clients, users, administrator of a singleton or server collection, hosts, NSDB nodes, etc.) that can assume a role defined by the federation protocol can identify themselves to each other via an authentication mechanism. This mechanism is not defined or further described in this document.
可以承担联合协议定义的角色的所有主体（客户端、用户、单例或服务器集合的管理员、主机、NSDB节点等）都可以通过身份验证机制相互标识自己。本文件中未定义或进一步描述该机制。
The authority of a principal to request that a second principal perform a specific operation is ultimately determined by the second. Authorization may be partitioned by server collection or set of servers as well as by operation. For example, if a user has administrative privileges on one server in the federation, this does not imply that they have administrative privileges (or, for that matter, any privileges whatsoever) on any other server in the federation.
主体请求第二主体执行特定操作的权限最终由第二主体确定。授权可以通过服务器集合或服务器集以及操作进行分区。例如，如果用户在联合体中的一台服务器上拥有管理权限，这并不意味着他们在联合体中的任何其他服务器上拥有管理权限（或者，就此而言，任何权限）。
In order to access the functionality provided by the federation interfaces, it may be necessary to have elevated privileges or authorization. The authority required by different operations may be different. For example, the authority required to query the NSDB about the FSLs bound to an FSN may be different than the authority required to change the bindings of that FSN.
为了访问联合接口提供的功能，可能需要具有提升的特权或授权。不同操作所需的权限可能不同。例如，向NSDB查询绑定到FSN的FSL所需的权限可能不同于更改该FSN绑定所需的权限。
An operation attempted by an unauthorized entity MUST fail in a manner that indicates that the failure was due to insufficient authorization.
未经授权的实体尝试的操作失败的方式必须表明失败是由于授权不足造成的。
This document does not enumerate the authorization necessary for any operation.
本文件未列举任何操作所需的授权。
A5: The federation protocols MUST NOT require changes to existing authentication/authorization mechanisms in use at the fileservers for client-facing protocols.
A5：对于面向客户端的协议，联合协议不得要求更改文件服务器上使用的现有身份验证/授权机制。
A user's view of the namespace may be limited by the authentication and authorization privileges it has on the different fileservers in the federation. As such, users may only be able to traverse the parts of the namespace to which they have access.
用户对命名空间的查看可能受到其在联合体中不同文件服务器上拥有的身份验证和授权权限的限制。因此，用户可能只能遍历他们有权访问的命名空间部分。
The federation protocols do not impose any restrictions on how users are represented within the federation. For example, a single enterprise could employ a common identity for users across the federation. A grid environment could utilize user mapping or translations across different administrative domains.
联邦协议对如何在联邦中表示用户没有任何限制。例如，单个企业可以为整个联盟的用户使用一个公共标识。网格环境可以利用跨不同管理域的用户映射或转换。
A6: In a federated system, we assume that an FSN MUST express, or can be used to discover, the following two pieces of information:
A6：在联邦系统中，我们假设FSN必须表示或可用于发现以下两条信息：
1. The location of the NSDB node that is responsible for knowing the filesystem location(s) (FSLs) of the named fileset.
1. 负责了解命名文件集的文件系统位置（FSLs）的NSDB节点的位置。
The NSDB node must be specified because there may be many NSDB nodes in a federation. We do not assume that any single entity knows the location of all of the NSDB nodes, and therefore exhaustive search is not an option.
必须指定NSDB节点，因为联盟中可能有许多NSDB节点。我们不假设任何单个实体都知道所有NSDB节点的位置，因此无法进行穷举搜索。
There are several ways in which a fileserver can locate the NSDB node responsible for a given fileset. One approach, given a DNS infrastructure, is to specify the location of the NSDB node by the Fully-Qualified Domain Name (FQDN) of the server hosting the NSDB node. Another approach is to use a separate DNS-style hierarchy to resolve the location of the NSDB node.
文件服务器可以通过多种方式找到负责给定文件集的NSDB节点。给定DNS基础设施的一种方法是通过承载NSDB节点的服务器的完全限定域名（FQDN）指定NSDB节点的位置。另一种方法是使用单独的DNS样式层次结构来解析NSDB节点的位置。
2. The FSN identifier.
2. FSN标识符。
The FSN identifier is the index used by the NSDB node to identify the target fileset.
FSN标识符是NSDB节点用于标识目标文件集的索引。
There are several ways to represent FSN identifiers. One approach could use 128-bit Universally Unique IDentifiers (UUIDs) as described in [RFC4122].
有几种方法可以表示FSN标识符。一种方法可以使用[RFC4122]中描述的128位通用唯一标识符（UUID）。
As an example, an FSN could be represented by a URL of the form nsdb://nsdb.example.com/UUID where nsdb is the scheme name, nsdb.example.com is the FQDN of the server hosting the NSDB node, and UUID is the string representation of the identifier.
例如，一个FSN可以由以下形式的URL表示nsdb://nsdb.example.com/UUID 其中nsdb是方案名称，nsdb.example.com是承载nsdb节点的服务器的FQDN，UUID是标识符的字符串表示形式。
Note that it is not assumed that it is always required for a server to contact the NSDB node specified by the FSN in order to find the FSLs. The relevant information stored in that NSDB node may also be cached local to the server or on a proxy NSDB node "near" the server.
注意，并不是假定服务器总是需要联系FSN指定的NSDB节点才能找到FSL。存储在该NSDB节点中的相关信息也可以缓存在服务器本地或服务器“附近”的代理NSDB节点上。
A7: All federation servers and NSDB nodes are assumed to execute the federation protocols correctly. The behavior of the federation is undefined in the case of Byzantine behavior by any federation server or NSDB node.
A7：假设所有联合服务器和NSDB节点都正确执行联合协议。对于任何联合服务器或NSDB节点的拜占庭行为，联合的行为是未定义的。
A8: The locations of federation services (such as NSDBs and FSLs) can be specified in a manner such that they can be correctly interpreted by all members of the federation that will access them.
A8：可以指定联合体服务（如NSDB和FSL）的位置，以便访问它们的联合体的所有成员都能正确解释它们。
For example, if an NSDB node is specified by an FQDN, then this implies that every member of the federation that needs to access this NSDB node can resolve this FQDN to an IP address for that NSDB node. (It is not necessary that the FQDN always resolve to the same address; the same service may appear at different addresses on different networks.)
例如，如果NSDB节点由FQDN指定，则这意味着需要访问此NSDB节点的联合体的每个成员都可以将此FQDN解析为该NSDB节点的IP地址。（FQDN不一定总是解析为同一地址；同一服务可能出现在不同网络上的不同地址。）
It is the responsibility of each federation member to ensure that the resources it wishes to expose have accessible network locations and that the necessary resolution mechanisms (i.e., DNS) are given the necessary data to perform the resolution correctly.
每个联合会成员都有责任确保其希望公开的资源具有可访问的网络位置，并且为必要的解析机制（即DNS）提供正确执行解析所需的数据。
R1: Requirements of each FSN:
R1：每个FSN的要求：
a. Each FSN MUST be unique within the scope of its NSDB (so that the FSN is globally unique).
a. 每个FSN在其NSDB范围内必须是唯一的（因此FSN是全局唯一的）。
b. The FSN MUST be sufficiently descriptive to locate an instance of the fileset it names within the federation at any time.
b. FSN必须具有足够的描述性，以便随时在联合体中找到它命名的文件集的实例。
c. All FSNs MUST be invariant when their underlying filesystems move or are replicated; only mappings from FSN to FSL(s) change under these transformations.
c. 当底层文件系统移动或复制时，所有FSN必须保持不变；在这些转换下，只有从FSN到FSL的映射才会更改。
d. All files accessible from the global namespace MUST be part of a fileset that has an assigned FSN.
d. 从全局命名空间访问的所有文件都必须是具有指定FSN的文件集的一部分。
Not all filesets in the federation are required to have an FSN or be reachable by an FSL. Only those filesets that are the target of a junction (as described in R3) are required to have an FSN.
并非联合体中的所有文件集都需要有FSN或FSL可以访问。只有作为连接目标的文件集（如R3中所述）才需要具有FSN。
The FSN format MAY be of variable size. If the format is variable in size, fileserver implementations MAY have a maximum supported FSN size. By bounding the FSN size, some fileserver implementations might be able to efficiently organize FSNs in stable storage. For interoperability, the federation protocols SHOULD define an FSN size that all fileservers support.
FSN格式的大小可能不同。如果格式大小可变，则文件服务器实现可能具有支持的最大FSN大小。通过限制FSN的大小，一些文件服务器实现可能能够在稳定的存储中高效地组织FSN。为了实现互操作性，联合协议应该定义所有文件服务器都支持的FSN大小。
R2: USING THE FEDERATION INTERFACES, it MUST be possible to create an FSN for a fileset, and it must be possible to bind an FSL to that FSN. These operations are NSDB operations and do not require any action on the part of a file server.
R2：使用联合接口，必须能够为文件集创建FSN，并且必须能够将FSL绑定到该FSN。这些操作是NSDB操作，不需要文件服务器执行任何操作。
It is possible to create an FSN for a fileset that has not actually been created. It is also possible to bind a nonexistent FSL to an FSN. It is also possible to create a fileset without assigning it an FSN. The binding between an FSN and an FSL is defined entirely within the context of the NSDB; the servers do not "know" whether the filesets they host have been assigned FSNs (or, if so, what those FSNs are).
可以为尚未实际创建的文件集创建FSN。也可以将不存在的FSL绑定到FSN。也可以创建文件集而不为其分配FSN。FSN和FSL之间的绑定完全在NSDB的上下文中定义；服务器不“知道”它们承载的文件集是否已分配了FSN（或者，如果是，这些FSN是什么）。
The requirement that filesets can exist prior to being assigned an FSN and the requirement that FSNs can exist independent of filesets are intended to simplify the construction of the namespace in a convenient manner. For example, they permit an admin to assign FSNs to existing filesets and thereby incorporate existing filesets into the namespace. They also permit the structure of the namespace to be defined prior to creation of the component filesets. In either case, it is the responsibility of the entity updating the NSDB with FSNs and FSN-to-FSL mappings to ensure that the namespace is constructed in a consistent manner. (The simplest way to accomplish this is to ensure that the FSN and FSN-to-FSL mappings are always recorded in the NSDB prior to the creation of any junctions that refer to that FSN.)
文件集可以在分配FSN之前存在的要求以及FSN可以独立于文件集存在的要求旨在以方便的方式简化命名空间的构造。例如，它们允许管理员将FSN分配给现有文件集，从而将现有文件集合并到命名空间中。它们还允许在创建组件文件集之前定义名称空间的结构。在任何一种情况下，实体都有责任使用FSN和FSN到FSL映射更新NSDB，以确保命名空间以一致的方式构造。（实现这一点的最简单方法是确保在创建引用该FSN的任何连接之前，始终在NSDB中记录FSN和FSN到FSL的映射。）
a. An administrator MAY specify the entire FSN (including both the NSDB node location and the identifier) of the newly created FSL, or the administrator MAY specify only the NSDB node and have the system choose the identifier.
a. 管理员可以指定新创建的FSL的整个FSN（包括NSDB节点位置和标识符），或者管理员可以仅指定NSDB节点并让系统选择标识符。
The admin can choose to specify the FSN explicitly in order to recreate a lost fileset with a given FSN (for example, as part of disaster recovery). It is an error to assign an FSN that is already in use by an active fileset.
管理员可以选择显式指定FSN，以便使用给定的FSN重新创建丢失的文件集（例如，作为灾难恢复的一部分）。分配活动文件集已在使用的FSN是错误的。
Note that creating a replica of an existing filesystem is NOT accomplished by assigning the FSN of the filesystem you wish to replicate to a new filesystem.
请注意，创建现有文件系统的副本并不是通过将要复制的文件系统的FSN分配到新文件系统来完成的。
b. USING THE FEDERATION INTERFACES, it MUST be possible to create a federation FSL by specifying a specific local volume, path, export path, and export options.
b. 使用联合接口，必须能够通过指定特定的本地卷、路径、导出路径和导出选项来创建联合FSL。
R3: USING THE FEDERATION INTERFACES, and given the FSN of a target fileset, it MUST be possible to create a junction to that fileset at a named place in another fileset.
R3：使用联合接口，并给定目标文件集的FSN，必须能够在另一个文件集中的指定位置创建到该文件集的连接。
After a junction has been created, clients that access the junction transparently interpret it as a reference to the FSL(s) that implement the FSN associated with the junction.
创建连接后，访问连接的客户端将其透明地解释为对实现与连接关联的FSN的FSL的引用。
a. It SHOULD be possible to have more than one junction whose target is a given fileset. In other words, it SHOULD be possible to mount a fileset at multiple named places.
a. 应该可以有多个目标为给定文件集的连接。换句话说，应该可以在多个命名位置装载文件集。
b. If the fileset in which the junction is created is replicated, then the junction MUST eventually appear in all of its replicas.
b. 如果在其中创建连接的文件集已复制，则连接最终必须出现在其所有副本中。
The operation of creating a junction within a fileset is treated as an update to the fileset, and therefore obeys the general rules about updates to replicated filesets.
在文件集中创建连接的操作被视为对文件集的更新，因此遵守有关对复制文件集的更新的一般规则。
R4: USING THE FEDERATION INTERFACES, it MUST be possible to delete a specific junction from a fileset.
R4：使用联合接口，必须能够从文件集中删除特定的连接。
If a junction is deleted, clients who are already viewing the fileset referred to by the junction after traversing the junction MAY continue to view the old namespace. They might not discover that the junction no longer exists (or has been deleted and replaced with a new junction, possibly referring to a different FSN).
如果删除了连接，则在遍历连接后已在查看该连接引用的文件集的客户端可能会继续查看旧的命名空间。他们可能不会发现该连接已不存在（或已被删除并替换为新的连接，可能指的是不同的FSN）。
After a junction is deleted, another object with the same name (another junction, or an ordinary filesystem object) may be created.
删除连接后，可以创建另一个同名对象（另一个连接或普通文件系统对象）。
The operation of deleting a junction within a fileset is treated as an update to the fileset, and therefore obeys the general rules about updates to replicated filesets.
删除文件集中的连接的操作被视为对文件集的更新，因此遵守有关对已复制文件集的更新的一般规则。
R5: USING THE FEDERATION INTERFACES, it MUST be possible to invalidate an FSN.
R5：使用联合接口，必须能够使FSN无效。
a. If a junction refers to an FSN that is invalid, attempting to traverse the junction MUST fail.
a. 如果交叉点引用的FSN无效，则尝试穿越交叉点必须失败。
An FSN that has been invalidated MAY become valid again if the FSN is recreated (i.e., as part of a disaster recovery process).
如果重新创建已失效的FSN（即，作为灾难恢复过程的一部分），则该FSN可能再次变为有效。
If an FSN is invalidated, clients who are already viewing the fileset named by the FSN MAY continue to view the old namespace. They might not discover that the FSN is no longer valid until they try to traverse a junction that refers to it.
如果FSN无效，则已经在查看由FSN命名的文件集的客户端可以继续查看旧名称空间。他们可能不会发现FSN不再有效，直到他们尝试遍历引用它的连接。
R6: USING THE FEDERATION INTERFACES, it MUST be possible to invalidate an FSL.
R6：使用联合接口，必须能够使FSL无效。
a. An invalid FSL MUST NOT be returned as the result of resolving a junction.
a. 解析连接时，不能返回无效的FSL。
An FSL that has been invalidated MAY become valid again if the FSL is recreated (i.e., as part of a disaster recovery process).
如果重新创建已失效的FSL（即，作为灾难恢复过程的一部分），则该FSL可能再次变为有效。
If an FSL is invalidated, clients who are already viewing the fileset implemented by the FSL MAY continue to use that FSL. They might not discover that the FSL is no longer valid until they try to traverse a junction that refers to the fileset implemented by the FSL.
如果FSL无效，已经在查看由FSL实现的文件集的客户端可以继续使用该FSL。在尝试遍历引用FSL实现的文件集的连接之前，他们可能不会发现FSL不再有效。
Note that invalidating an FSL does not imply that the underlying export or share (depending on the file access protocol in use) is changed in any way -- it only changes the mappings from FSNs to FSLs on the NSDB.
请注意，使FSL无效并不意味着基础导出或共享（取决于所使用的文件访问协议）以任何方式发生更改——它只会更改NSDB上从FSN到FSL的映射。
R7: It MUST be possible for the federation of servers to provide multiple namespaces.
R7：服务器联盟必须能够提供多个名称空间。
R8: USING THE FEDERATION INTERFACES:
R8：使用联合接口：
a. It MUST be possible to query the fileserver named in an FSL to discover whether a junction exists at a given path within that FSL.
a. 必须能够查询FSL中命名的文件服务器，以发现该FSL中给定路径上是否存在连接。
b. It MAY be possible to query the fileserver named in an FSL to discover the junctions, if any, in that FSL. If this feature is implemented, the fileserver SHOULD report each junction's path within the FSL and the targeted FSN.
b. 可以查询FSL中命名的文件服务器，以发现该FSL中的连接（如果有）。如果实现了此功能，文件服务器应该报告FSL和目标FSN中每个连接的路径。
R9: The projected namespace (and the objects named by the namespace) MUST be accessible to clients via at least one of the following standard filesystem access protocols:
R9：客户端必须至少通过以下标准文件系统访问协议之一访问投影的命名空间（以及由命名空间命名的对象）：
a. The namespace SHOULD be accessible to clients via versions of the CIFS (Common Internet File System) protocol as described in [MS-SMB] [MS-SMB2] [MS-CIFS].
a. 客户端应可通过[MS-SMB][MS-SMB2][MS-CIFS]中所述的CIFS（通用Internet文件系统）协议版本访问命名空间。
b. The namespace SHOULD be accessible to clients via the NFSv4 protocol as described in [RFC3530].
b. 如[RFC3530]所述，客户端应可通过NFSv4协议访问该命名空间。
c. The namespace SHOULD be accessible to clients via the NFSv3 protocol as described in [RFC1813].
c. 如[RFC1813]中所述，客户端应该可以通过NFSv3协议访问该名称空间。
d. The namespace SHOULD be accessible to clients via the NFSv2 protocol as described in [RFC1094].
d. 如[RFC1094]所述，客户端应可通过NFSv2协议访问该命名空间。
It must be understood that some of these protocols, such as NFSv3 and NFSv2, have no innate ability to access a namespace of this kind. Where such protocols have been augmented with other protocols and mechanisms (such as autofs or amd for NFSv3) to provide an extended namespace, we propose that these protocols and mechanisms may be used, or extended, in order to satisfy the requirements given in this document, and different clients may use different mechanisms.
必须理解的是，其中一些协议，如NFSv3和NFSv2，没有访问此类名称空间的固有能力。如果此类协议已通过其他协议和机制（如autofs或amd for NFSv3）进行了扩展以提供扩展名称空间，我们建议可以使用或扩展这些协议和机制，以满足本文档中给出的要求，并且不同的客户机可以使用不同的机制。
R10: USING THE FEDERATION INTERFACES, it MUST be possible to modify the NSDB mapping from an FSN to a set of FSLs to reflect the migration from one FSL to another.
R10：使用联合接口，必须能够修改NSDB从一个FSN到一组FSL的映射，以反映从一个FSL到另一个FSL的迁移。
R11: FSL migration SHOULD have little or no impact on the clients, but this is not guaranteed across all federation members.
R11:FSL迁移对客户端的影响应该很小或没有影响，但不能保证所有联盟成员都能做到这一点。
Whether FSL migration is performed transparently depends on whether the source and destination servers are able to do so. It is the responsibility of the administrator to recognize whether or not the migration will be transparent, and advise the system accordingly. The federation, in turn, MUST advise the servers to notify their clients, if necessary.
FSL迁移是否透明地执行取决于源服务器和目标服务器是否能够这样做。管理员有责任确认迁移是否透明，并相应地通知系统。反过来，联盟必须建议服务器在必要时通知其客户端。
For example, on some systems, it may be possible to migrate a fileset from one system to another with minimal client impact because all client-visible metadata (inode numbers, etc.) are preserved during migration. On other systems, migration might be quite disruptive.
例如，在某些系统上，可以在对客户端影响最小的情况下将文件集从一个系统迁移到另一个系统，因为在迁移过程中保留了所有客户端可见的元数据（inode编号等）。在其他系统上，迁移可能具有相当大的破坏性。
R12: USING THE FEDERATION INTERFACES, it MUST be possible to modify the NSDB mapping from an FSN to a set of FSLs to reflect the addition/removal of a replica at a given FSL.
R12：使用联合接口，必须能够修改NSDB从FSN到一组FSL的映射，以反映在给定FSL添加/删除副本的情况。
R13: Replication SHOULD have little or no negative impact on the clients.
R13:复制对客户端的负面影响应该很小或没有负面影响。
Whether FSL replication is performed transparently depends on whether the source and destination servers are able to do so. It is the responsibility of the administrator initiating the replication to recognize whether or not the replication will be transparent, and advise the federation accordingly. The federation MUST advise the servers to notify their clients, if necessary.
FSL复制是否透明地执行取决于源服务器和目标服务器是否能够这样做。启动复制的管理员负责识别复制是否透明，并相应地通知联合。如有必要，联合会必须建议服务器通知其客户端。
For example, on some systems, it may be possible to mount any FSL of an FSN read/write, while on other systems, there may be any number of read-only replicas but only one FSL that can be mounted as read/write.
例如，在某些系统上，可以装载FSN读/写的任何FSL，而在其他系统上，可能有任意数量的只读副本，但只有一个FSL可以装载为读/写。
R14: USING THE FEDERATION INTERFACES, it SHOULD be possible to annotate the objects and relations managed by the federation protocol with arbitrary name/value pairs.
R14：使用联邦接口，应该可以使用任意名称/值对注释联邦协议管理的对象和关系。
These annotations are not used by the federation protocols -- they are intended for use by higher-level protocols. For example, an annotation that might be useful for a system administrator browsing the federation would be the "owner" of each FSN (i.e., "this FSN is for the home directory of Joe Smith"). As another example, the annotations may express hints used by the clients (such as priority information for NFSv4.1).
这些注释不是由联合协议使用的——它们是供更高级别的协议使用的。例如，对于浏览联盟的系统管理员可能有用的注释是每个FSN的“所有者”（即，“此FSN用于Joe Smith的主目录”）。作为另一个示例，注释可以表示客户端使用的提示（例如NFSv4.1的优先级信息）。
Both FSNs and FSLs may be annotated. For example, an FSN property might be "This is Joe Smith's home directory", and an FSL property might be "This instance of the FSN is at the remote backup site".
可对FSN和FSL进行注释。例如，FSN属性可能是“This is Joe Smith's home directory”，FSL属性可能是“This instance of the FSN is the remote backup site”。
a. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for a junction.
a. 使用联合接口，必须能够查询系统以查找连接的注释。
b. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for an FSN.
b. 使用联合接口，必须能够查询系统以查找FSN的注释。
c. USING THE FEDERATION INTERFACES, it MUST be possible to query the system to find the annotations for an FSL.
c. 使用联合接口，必须能够查询系统以查找FSL的注释。
R15: It MUST be possible for the federation to project a namespace with a common root.
R15:联合体必须能够投影具有公共根的命名空间。
a. It SHOULD be possible to define a root fileset that is exported by one or more fileservers in the federation as the top level of a namespace. (Corollary: There is one root fileset per namespace and it is possible to support multiple namespaces per federation.)
a. 应该可以将由联合体中的一个或多个文件服务器导出的根文件集定义为命名空间的顶级。（推论：每个名称空间有一个根文件集，并且每个联合体可以支持多个名称空间。）
b. It SHOULD be possible for a fileserver to locate an NSDB that stores the layout of a root fileset.
b. 文件服务器应该可以找到存储根文件集布局的NSDB。
c. It SHOULD be possible to access, store, and update information related to a root fileset using the federation protocols.
c. 应该可以使用联合协议访问、存储和更新与根文件集相关的信息。
d. It SHOULD be possible to replicate root fileset information across multiple repositories.
d. 应该可以跨多个存储库复制根文件集信息。
e. If a root fileset is defined, it SHOULD be possible to enable a fileserver to export that root fileset for client access.
e. 如果定义了根文件集，则应该可以使文件服务器导出该根文件集以供客户端访问。
f. If a root fileset is defined, it SHOULD be possible for multiple fileservers to project a common root with defined consistency semantics.
f. 如果定义了根文件集，则多个文件服务器应该可以使用定义的一致性语义投影公共根。
g. If a root fileset is defined, it SHOULD be stored using a compact representation that is compatible with heterogeneous fileserver implementations. The root fileset's internal format SHOULD contain enough information to generate any attributes, including referrals, required by the standard filesystem access protocols in R9.
g. 如果定义了根文件集，则应使用与异构文件服务器实现兼容的紧凑表示来存储它。根文件集的内部格式应该包含足够的信息来生成R9中标准文件系统访问协议所需的任何属性，包括引用。
N1: It is not necessary for the namespace to be known by any specific fileserver.
N1：任何特定的文件服务器都不需要知道名称空间。
In the same manner that clients do not need to have a priori knowledge of the structure of the namespace or its mapping onto federation members, the projected namespace can exist without individual fileservers knowing the entire organizational structure, or, indeed, without knowing exactly where in the projected namespace the filesets they host exist.
与客户端不需要事先知道名称空间的结构或其到联合体成员的映射相同，投影名称空间可以存在，而单个文件服务器不知道整个组织结构，或者，不知道它们所在的文件集在投影命名空间中的确切位置。
Fileservers do need to be able to handle referrals from other fileservers, but they do not need to know what path the client was accessing when the referral was generated.
文件服务器确实需要能够处理来自其他文件服务器的引用，但它们不需要知道生成引用时客户端正在访问的路径。
N2: It is not necessary for updates and accesses to the NSDB data to occur in transaction or transaction-like contexts.
N2：不需要在事务或类似事务的上下文中更新和访问NSDB数据。
One possible requirement that is omitted from our current list is that updates and accesses to the data stored in the NSDB (or individual NSDB nodes) occur within a transaction context. We were not able to agree whether the benefits of transactions are worth the complexity they add (both to the specification and its eventual implementation), but this topic is open for discussion.
我们当前列表中省略的一个可能要求是在事务上下文中更新和访问存储在NSDB（或单个NSDB节点）中的数据。我们无法就事务的好处是否值得它们所增加的复杂性（包括规范及其最终实现）达成一致，但这个话题值得讨论。
Below is the draft of a proposed requirement that provides transactional semantics:
以下是提供事务语义的拟议需求草案：
There MUST be a way to ensure that sequences of operations, including observations of the namespace (including finding the locations corresponding to a set of FSNs) and changes to the namespace or related data stored in the system (including the creation, renaming, or deletion of junctions, and the creation, altering, or deletion of mappings between FSN and filesystem locations), can be performed in a manner that provides predictable semantics for the relationship between the observed values and the effect of the changes.
必须有一种方法来确保操作序列，包括对命名空间的观察（包括查找与一组FSN相对应的位置）以及对系统中存储的命名空间或相关数据的更改（包括连接的创建、重命名或删除，以及FSN和文件系统位置之间映射的创建、更改或删除），可以通过为观察值和更改效果之间的关系提供可预测语义的方式执行。
It MUST be possible to protect sequences of operations by transactions with NSDB-wide or server-wide Atomicity, Consistency, Isolation, and Durability (ACID) semantics.
必须能够通过具有NSDB范围或服务器范围原子性、一致性、隔离性和持久性（ACID）语义的事务来保护操作序列。
Assuming the Internet threat model, the federated resolution mechanism described in this document MUST be implemented in such a way to prevent loss of CONFIDENTIALITY, DATA INTEGRITY, and PEER ENTITY AUTHENTICATION, as described in [RFC3552].
假设采用互联网威胁模型，本文档中描述的联邦解决机制必须以防止机密性、数据完整性和对等实体身份验证丢失的方式实施，如[RFC3552]所述。
CONFIDENTIALITY may be violated if an unauthorized party is able to eavesdrop on the communication between authorized servers and NSDB nodes and thereby learn the locations or other information about FSNs that they would not be authorized to discover via direct queries. DATA INTEGRITY may be compromised if a third party is able to undetectably alter the contents of the communication between servers and NSDB nodes. PEER ENTITY AUTHENTICATION is defeated if one server can masquerade as another server without proper authority, or if an arbitrary host can masquerade as a NSDB node.
如果未经授权的一方能够窃听授权服务器和NSDB节点之间的通信，从而了解其无权通过直接查询发现的有关FSN的位置或其他信息，则可能违反保密性。如果第三方能够不可检测地改变服务器和NSDB节点之间的通信内容，则数据完整性可能会受到损害。如果一台服务器可以在没有适当权限的情况下伪装成另一台服务器，或者如果任意主机可以伪装成NSDB节点，则对等实体身份验证将失败。
Well-established techniques for providing authenticated channels may be used to defeat these attacks, and the protocol MUST support at least one of them.
提供认证通道的成熟技术可用于抵御这些攻击，协议必须至少支持其中一种攻击。
For example, if Lightweight Directory Access Protocol (LDAP) is used to implement the query mechanism [RFC4510], then Transport Layer Security (TLS) may be used to provide both authentication and integrity [RFC5246] [RFC4513]. If the query protocol is implemented on top of Open Network Computing / Remote Procedure Call (ONC/RPC), then RPCSEC_GSS may be used to fill the same role [RFC2203] [RFC2743].
例如，如果使用轻型目录访问协议（LDAP）来实现查询机制[RFC4510]，则传输层安全性（TLS）可用于提供身份验证和完整性[RFC5246][RFC4513]。如果查询协议是在开放网络计算/远程过程调用（ONC/RPC）之上实现的，那么可以使用RPCSEC_GSS来填充相同的角色[RFC2203][RFC2743]。
A federation could contain multiple Public Key Infrastructure (PKI) trust anchors [RFC5280]. The federation protocols SHOULD define a mechanism for managing a fileserver's NSDB trust anchors [TA-MGMT-REQS]. A general purpose trust anchor management protocol [TAMP] would be appropriate, though it might be desirable for the federation protocols to facilitate trust anchor management by, for example, using trust anchor interchange formats [TA-FORMAT].
联合可以包含多个公钥基础设施（PKI）信任锚[RFC5280]。联合协议应该定义一种机制来管理文件服务器的NSDB信任锚[TA-MGMT-REQS]。通用信任锚管理协议[TAMP]将是合适的，尽管联邦协议可能希望通过例如使用信任锚交换格式[TA-FORMAT]来促进信任锚管理。
It is useful to note that the requirements described in this document lead naturally to a system with distributed authorization, which has scalability and manageability benefits.
值得注意的是，本文档中描述的需求自然会导致一个具有分布式授权的系统，它具有可伸缩性和可管理性的优点。
FSNs are likely to be long-lived resources. Therefore, the privilege to create FSNs SHOULD be carefully controlled. To assist in determining if an FSN is referenced by a junction somewhere in the federation, the NSDB records SHOULD include non-authoritative informational annotations recording the locations of any such junctions. These annotations are non-authoritative because a
FSN可能是长期存在的资源。因此，应谨慎控制创建FSN的权限。为了帮助确定FSN是否由联邦某处的连接引用，NSDB记录应包括记录任何此类连接位置的非权威信息注释。这些注释是非权威性的，因为
junction might be created, deleted, or modified by an individual that does not have permission to modify the NSDB records.
连接可能由无权修改NSDB记录的个人创建、删除或修改。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530]Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.，和D.Noveck，“网络文件系统（NFS）版本4协议”，RFC 3530，2003年4月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510]Zeilenga，K.，“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File System Version 4 Minor Version 1", RFC 5661, January 2010.
[RFC5661]Shepler，S.，Eisler，M.，和D.Noveck，“网络文件系统版本4次要版本1”，RFC 56612010年1月。
[MS-CIFS] Microsoft Corporation, "Common Internet File System (CIFS) Protocol Specification", MS-CIFS 2.0, November 2009.
[MS-CIFS]微软公司，“通用互联网文件系统（CIFS）协议规范”，MS-CIFS 2.0，2009年11月。
[MS-SMB] Microsoft Corporation, "Server Message Block (SMB) Protocol Specification", MS-SMB 17.0, November 2009.
[MS-SMB]微软公司，“服务器消息块（SMB）协议规范”，MS-SMB 17.012009年11月。
[MS-SMB2] Microsoft Corporation, "Server Message Block (SMB) Version 2 Protocol Specification", MS-SMB2 19.0, November 2009.
[MS-SMB2]微软公司，“服务器消息块（SMB）第2版协议规范”，MS-SMB2 19.012009年11月。
[RFC1094] Nowicki, B., "NFS: Network File System Protocol specification", RFC 1094, March 1989.
[RFC1094]Nowicki，B.，“NFS：网络文件系统协议规范”，RFC10941989年3月。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC1813]Callaghan，B.，Pawlowski，B.，和P.Staubach，“NFS版本3协议规范”，RFC 1813，1995年6月。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203]Eisler，M.，Chiu，A.，和L.Ling，“RPCSEC_GSS协议规范”，RFC 2203，1997年9月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]Harrison，R.，“轻量级目录访问协议（LDAP）：认证方法和安全机制”，RFC4513，2006年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[TA-FORMAT] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", Work in Progress, October 2009.
[TA-格式]Housley，R.，Ashmore，S.，和C.Wallace，“信任锚格式”，正在进行的工作，2009年10月。
[TA-MGMT-REQS] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", Work in Progress, September 2009.
[TA-MGMT-REQS]Reddy，R.和C.Wallace，“信托锚管理要求”，在建工程，2009年9月。
[TAMP] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", Work in Progress, December 2009.
[TAMP]Housley，R.，Ashmore，S.，和C.Wallace，“信任锚管理协议（TAMP）”，正在进行的工作，2009年12月。
We would like to thank Robert Thurlow of Sun Microsystems for helping to author this document.
我们要感谢Sun Microsystems的Robert Thurlow帮助编写本文档。
We would also like to thank Peter McCann and Nicolas Williams for their comments and suggestions.
我们还要感谢Peter McCann和Nicolas Williams的评论和建议。
Authors' Addresses
作者地址
James Lentini NetApp 1601 Trapelo Rd, Suite 16 Waltham, MA 02451 US
美国马萨诸塞州沃尔瑟姆市特拉佩罗路1601号16室詹姆斯·兰蒂尼·内塔普邮编02451
Phone: +1 781-768-5359
EMail: jlentini@netapp.com
Phone: +1 781-768-5359
EMail: jlentini@netapp.com
Craig Everhart NetApp 7301 Kit Creek Rd Research Triangle Park, NC 27709 US
美国北卡罗来纳州基特克里克路三角研究公园Craig Everhart NetApp 7301号，邮编27709
Phone: +1 919-476-5320
EMail: everhart@netapp.com
Phone: +1 919-476-5320
EMail: everhart@netapp.com
Daniel Ellard BBN Technologies 10 Moulton Street Cambridge, MA 02138 US
Daniel Ellard BBN Technologies美国马萨诸塞州剑桥莫尔顿街10号，邮编02138
Phone: +1 617-873-8000
EMail: dellard@bbn.com
Phone: +1 617-873-8000
EMail: dellard@bbn.com
Renu Tewari IBM Almaden 650 Harry Rd San Jose, CA 95120 US
美国加利福尼亚州圣何塞哈里路650号雷努·特瓦里IBM阿尔马登95120
EMail: tewarir@us.ibm.com
EMail: tewarir@us.ibm.com
Manoj Naik IBM Almaden 650 Harry Rd San Jose, CA 95120 US
美国加利福尼亚州圣何塞哈利路650号Manoj Naik IBM Almaden 95120
EMail: manoj@almaden.ibm.com
EMail: manoj@almaden.ibm.com