NFS文件系统协议及解析概要

图 2 RPC 调用过程示意图 2 RPC 调用过程示意 1.2 外部数据表示 外部数据表示（XDR）标准提供了一种在网络上表示一组数据类型的通 用方法。NFS 协议规范是使用 RPC 数据描述语言编写的。有关更多信 息，请参阅 RFC 1014，《XDR:外部数据表示标准》。虽然存在自动的
rpc/xdr 编译器来生成服务器和客户机的“存根”，但是 NFS 不需要它 们的使用。可以使用提供等效功能的任何软件，如果编码完全相同，则 可以与其他 NFS 实现进行互操作。
如果响应状态为 NFS_OK，这时响应的属性中包含通过输入 fhandle 所指定的文件的属性信息。
2.2.3 设置文件属性
struct sattrargs { fhandle file;sattr attributes; }; attrstat NFSPROC_SETATTR (sattrargs) = 2;
attrstat NFSPROC_GETATTR(fhandle) = 1;
attrstat NFSPROC_SETATTR(sattrargs) = 2; void NFSPROC_ROOT(void) = 3;
diropres NFSPROC_LOOKUP(diropargs) = 4;
readlinkres NFSPROC_READLINK(fhandle) = 5;
虽然文件和目录在许多方面都是相似的对象，但读取目录和文件时使用 了不同的过程。这为表示目录提供了一种网络标准格式。可以使用与上 面相同的参数来对每个调用只返回一个目录条目的过程进行证明。问题 在于效率。目录可以包含多个条目，远程调用返回每个条目的速度太慢。
2.2 服务例程
协议定义通过一组例程进行定义，这些例程的参数和结果是使用 RPC 语言定义的（使用程序、版本和过程声明扩展的 XDR 语言）。对每个 例程功能的简要描述应提供足够的信息，以便于实施。第 2.3 节更详细 地描述了基本数据类型。
NFS 假定文件系统是基于目录进行分层的，目录为除底层文件之外的所 有内容。目录（文件、目录、设备等）中的每个条目都有一个字符串名 称。不同的操作系统可能对树的深度或使用的名称有限制，并且使用不 同的语法来表示“路径名”，这是名称中所有“组件”（目录和文件名） 的串联。“文件系统”是具有指定“根”的单个服务器（通常是单个磁
译者注： 从字面意义上可以看出，RPC 是一个跨越不同计算节点的过程调用，可 以理解为跨越不同计算机的函数调用。也就是说通过 RPC，你可以在一 台计算机上调用另外一台计算机上进程中的函数实现。如图 2 是一个简
答的调用示意图，客户端发起 RPC 调用，经过网络传输给服务端，服 务端进行处理后将结果返回给客户端。虽然经过了复杂的网络传输等过 程，但在客户端看来，就是进行了一次函数调用。
盘或物理分区）上的树。一些操作系统提供了一个“挂载”操作，使所 有文件系统显示为一棵树，而其他操作系统则维护一个文件系统的“森 林”。文件是未解释字节的非结构化流。NFS 的版本 3 使用了稍微更通 用的文件系统模型。
NFS 一次查找路径名的一个组件。这可能并不明显，为什么它不只是获 取整个路径名，沿着目录移动，并在完成后返回一个文件句柄。有几个 好理由不这么做。首先，路径名需要在目录组件之间使用分隔符，不同 的操作系统使用不同的分隔符。我们可以定义一个网络标准的路径名表 示，但是每个路径名都必须在每一端进行解析和转换。其他问题在第 3 节，NFS 实现问题中讨论。
假定 NFS 协议中的所有过程都是同步的。当一个过程返回到客户机时，
客户机可以假定操作已经完成，并且与请求相关联的任何数据现在都在
稳定存储中。例如，客户机写请求可能会导致服务器更新数据块、文件
系统信息块（如间接块）和文件属性信息（大小和修改时间）。当写操
作返回到客户机时，它可以假定写操作是安全的，即使在服务器崩溃的
void
NFSPROC_ROOT(void) = 3;
过时的。由于查找一个文件系统的根文件句柄需要在客户端和服务端移 动路径名称，因此本例程不在使用。要正确执行此操作，我们必须定义 路径名的网络标准表示。我们用 MNTPROC_MNT 例程代替了查找根 文件句柄的功能。（细节请参考附录 A，“挂载协议的定义”）
2.2.5 查找文件名
diropres NFSPROC_LOOKUP(diropargs) = 4;
如果回复的状态为 NFS_OK，这时应答的"file"和"attributes"分别是参 数中给定目录"dir"的文件句柄和文件“name”的属性。
2.2.6 从符号链接读取数据
union readlinkres witch (stat status) { case NFS_OK:path data;default:void; }; readlinkres NFSPROC_READLINK(fhandle) = 5;
readres NFSPROC_READ(readargs) = 6;
void NFSPROC_WRITECACHE(void) = 7;
attrstat
NFSPROC_WRITE(writeargs) = 8;
diropres NFSPROC_CREATE(createargs) = 9;
stat NFSPROC_REMOVE(diropargs) = 10; stat NFSPROC_RENAME(renameargs) = 11;
如果回复的状态为 NFS_OK，这时响应中的“data”是通过 fhandle 参数指定的文件的数据。
注意： 由于 NFS 仅仅在客户端解析路径名，符号链接的路径名在不同 的客户端意义是不同的（或者是无意义的）。
情况下，它也可以丢弃所写的数据。这是服务器无状态的一个非常重要
的部分。如果服务器等待从远程请求中刷新数据，客户机必须保存这些
请求，以便在服务器崩溃时重新发送它们。
/* Remote file service routines */ program NFS_PROGRAM {
version NFS_VERSION { void NFSPROC_NULL(void) = 0;
stat NFSPROC_LINK(linkargs) = 12;
stat NFSPROC_SYMLINK(symlinkargs) = 13;
diropres NFSPROC_MKDIR(createargs) = 14;
stat NFSPROC_RMDIR(diropargs) = 15;
readdirres NFSPROC_READDIR(readdirargs) = 16;
客户端服务端示意
图1
1.1 远程过程调用
Sun 的远程过程调用规范为远程服务提供了一个面向过程的接口。每台 服务器都提供一个“程序”，这是一组过程。NFS 就是这样一个程序。 主机地址、程序号和过程号的组合指定一个远程过程。NFS 的目标是不 需要低级别的任何特定可靠性级别，因此它可能用于许多底层传输协议， 甚至其他远程过程调用实现。为了便于讨论，本文的其余部分将假定 NFS 是在 Sun RPC 之上实现的，如 RFC 1057《RPC:远程过程调用协 议规范》中所述。
1.3 无状态服务
NFS 协议旨在尽可能无状态。也就是说，为了正常工作，服务器不需要 维护任何客户机的协议状态信息。无状态服务器在发生故障时比有状态 服务器有明显的优势。
对于无状态服务器，客户机只需要重试一个请求，直到服务器响应；它 甚至不需要知道服务器已经崩溃，或者网络暂时中断。另一方面，有状 态服务器的客户机需要检测服务器故障并在服务器恢复时重建服务器 状态，或者导致客户机操作失败。
statfsres NFSPROC_STATFS(fhandle) = 17; } = 2; } = 100003;
2.2.1 什么都不做
void
NFSPROC_NULL(void) = 0;
这个例程什么都不做，它在所有的 RPC 服务中都可用，以允许服务响
应测试和计时。
2.2.2 获取文件属性
attrstat NFSPROC_GETATTR (fhandle) = 1;
本备忘录的状态
本 RFC 描述了一个在太阳微系统公司（译者注：这里是指 SUN，当前 已经被 Oracle 收购）和其它正在使用的协议。新版本的协议正在开发 中，但其他人仍然可以从当前协议的描述中及设计问题的讨论中受益。 本备忘录的分发不受任何限制。
1. INTRODUCTION（引言）
Sun 网络文件系统（NFS）协议提供了透明的通过网络远程访问共享文 件的方式。NFS 协议被设计于可以很轻松的跨不同的机器、操作系统、 网络架构和传输协议。这种可移植性是通过使用建立在外部数据表示 （XDR）之上的远程过程调用（RPC）原语实现的。实现已经存在于从 个人计算机到超级计算机的各种机器上。
这听起来可能不是一个重要的问题，但它以一些意想不到的方式影响了 协议。我们认为，在协议中，能够编写不需要特殊崩溃恢复的非常简单 的服务器可能需要一些额外的复杂性。请注意，即使使用了所谓的“可 靠”传输协议（如 TCP），客户端仍必须能够通过在连接超时时重新打 开连接来处理服务中断。因此，无状态协议实际上可以简化实现。
NFS 文件系统协议及解析概要
本文是对 RFC1094 的翻译，它是 NFS 的第 2 版，之所以翻译这个版本 是因为它比较简单。后面会陆续完成第 3 版和第 4 版的翻译，并且完成 Linux 操作系统下 NFS 文件系统和其服务端的代码解析。作者为 SunnyZhang，翻译本文章出于如下几个目的： 1）练习英语，提升自身英语水平；2）进一步熟悉 NFS 协议；3）传播 存储相关知识。 另外，协议本身是纯文本格式，没有配图，因此理解起来可能有一定的 难度，因此译者在翻译的时候加入了一些译者注和插图，以方便大家理 解。不妥之处还请大家多批评指正。 更多存储相关技术文章可以关注本作者微信公众号或者头条号，名称为： itworld123