分布式文件系统（未完）

1.NFS（网络文件系统）

与其说NFS是一个文件系统，不如说他是共同为客户提供分布式文件系统模型的协议集合。NFS底层的模型是远程文件服务的模型，这个模型为客户提供对远程服务器所管理的文件系统的透明访问。客户通常不知道文件的实际位置，NFS为客户提供访问此文件系统的接口。

客户使用其本地操作系统提供的系统调用访问文件系统。VFS接口上的操作或者被传送到本地文件系统，或者被传送到一个成为NFS客户的单独组件，该组件负责处理对存储在远程服务器上的文件的访问（通过RPC实现）。

服务器端是类似的方式。RPC存根对请求进行解编，NFS服务器将它们转换成常规的VFS文件操作，随后这些操作被传送到VFS层。

命名：

客户能够在它自己的本地文件系统

当服务器允许其他客户使用一个目录及该目录的项目时，称该服务器输出（export）那个目录。一个输出目录的客户可以由客户装入其本地命名空间。

这种设计方法有一个重要的含义：用户基本不共享名称空间。比如上图客户A处名称为/remote/vu/mbox的文件在B处被命名为/work/me/mbox。这种方法的缺点是共享文件变得更困难。解决这一问题的最通用思路是为每个客户提供一个部分标准化的名称空间。比如，每个客户可以使用本地目录/usr/bin装入包含一些标准程序的文件系统，/local可用作装入位于客户主机上的本地文件系统的标准目录。

一台NFS服务器自身可以装入其他服务器输出的目录。但是，它不能再将这些目录输出给它自己的客户。

文件句柄：

文件句柄是对文件系统内的文件的引用。它与它所引用的文件的名称无关。文件句柄是由该文件系统所在的服务器创建的，并且它在该服务器输出的所有文件系统中是唯一的。

客户不知道文件句柄的真实内容，它是完全不透明的。只要文件是存在的，那么它就应该有一个不变的文件句柄。因为文件句柄可以被客户存储在本地，所以服务器不能重新使用被删除的文件的文件句柄。

自动装入：

各个用户对同一文件的命名不同，那么很可难以实现文件共享，一种解决方案是为每个用户提供一个部分标准化的本地命名空间，然后对每个用户以同样的方式装入远程文件系统。NFS命名模型的另外一个问题是应该何时装入远程文件系统。以一个具有成千上万个用户的大型系统为例，假设每个用户都有一个/home，该目录用于装入其他用户的目录，虽然alice的文件实际存储在远程服务器，但是它可以通过本地可用的/home/Alice访问自己的主目录，可能经由/home/Bob访问Bob的目录，从而访问Bob的公共文件。问题是Bob的目录什么时候装入呢？一种较好的方法是根据需要，也就是第一次需要时使用，透明的装入其他用户的主目录。

在NFS中，根据需要装入一个远程文件系统（或实际是一个目录输出）是由自动装入器实现的，它以一个单独的进程的形式运行于客户机器上，当客户端机器启动时，自动装入器开始装入这个目录，每当程序试图访问/home时，UNIX内核会把lookup操作转发给NFS客户，NFS客户将该请求转发给作用相当于NFS服务器的自动装入器。

这种方式的缺点是自动装入器要参与所有文件即便是已经装入的文件系统的读写请求，造成严重的性能问题。一个简单的方法是让自动装入器在特定的目录中装入目录，并为每个被装入的目录安装一个符号链接。

同步

分布式文件系统中的文件通常由多个客户共享。操作系统对操作都强加了一个绝对时间顺序，系统总是返回最新值。我们称这个模型为UNIX语义。分布式系统中，只有一个文件服务器而客户不缓存文件，实现UNIX语义十分容易，但这种将所有请求文件传送到一个单一的服务器的分布式性能通常是很差的。解决这个问题的方法是允许客户在它们似有（本地）高速缓存中保留频繁使用的文件的本地拷贝。但如果客户在本地修改被缓存的文件，而稍后很短的时间内另一客户从该服务器读取这个文件，那么第二个客户可能会得到过时的文件。

解决方法之一是立即将被缓存的文件的所有改动传播到服务器，但是这种方法并不有效。另一种可选择的方法是放宽文件共享的语义，制定一套新规则：“对打开文件的所做的改动最初只对修改这个文件的进程（或机器）可见，只有当文件关闭时，这些改动才对其他进程（或机器）可见。“这样做虽然不会改变图b所发生的情况，但是它确实将实际行为（B得到文件的原值）重新定义为正确的行为。当A关闭文件时，它向服务器发送一份拷贝以使得随后的读操作像我们要求的那样得到新值。这一规则被广泛的实现，这被成为会话语义。

另外一种完全不同的方法是使所有文件都不可改变，因而，系统无法为写操作打开文件。结果，文件上的操作仅有create和read。想要修改的话就用新的文件替换掉旧文件。

缓存和复制

容错性

由于NFS版本4放弃了无状态的设计方案，所以它需要处理容错和恢复问题，特别是一下两种情况会用到状态：文件锁定委派。另外还需要采取特殊的措施来处理位于NFS协议底层的RPC机制的不可靠性。

RPC故障

客户端和服务器端的RPC存根可能基于可靠的、面向连接的传输协议比如TCP，也可能是基于不可靠、无连接的传输协议比如UDP。因此当RPC响应丢失而客户端又成功地重传了原先的请求时，服务器最终会多次执行该请求。由服务器实现的重复请求高速缓存可以减轻这些问题。每个来自客户的RPC请求的头部都带有一个唯一的XID（transaction identifier 事物处理标识符），当RPC请求到来时，服务器缓存其标示符。只要服务器还没有发送响应，就说明服务器正在处理这个RPC请求。

出现故障时的文件锁定

为了锁定一个文件，客户向服务器提出锁请求，假设服务器批准这个请求，那么当客户崩溃时，我们可能陷入困境。为了解决这个问题服务器为它授予的每个锁一个租用，当租用到期时，服务器将删除对应的锁，客户应在其租用到期之前更新租用。服务器在崩溃并随后得到恢复时，它可能丢失它授予客户锁的信息，NFS版本4采用的方法是进入宽限期，在这个宽限期内，客户可以要求恢复曾授予它的锁。

使用租用引起了许多问题，比如租用要求客户和服务器的时钟同步，还有向服务器发送租用更新消息的可靠性问题，比较难解决。