分布式文件系统Nutch和coda(5)

通过缓存来处理离线操作

 

coda 对离线操作处理的支持实际上使它变成了一个可以自动适应网络故障的文件系统。在80年代，卡耐基·梅隆大学的校园里使用AFS来连接约1000个客户端。 在这样大的规模下，网络和服务器的故障几乎是每天都会出现的。当大量的移动客户（比如笔记本）出现后，coda这样支持网络暂时失效的分布式文件系统被及 时的发明出来了。

 

在前面的一段中，我们已经讲到coda缓存所有的访问需要的信息。当做出对文件系统的更新后，需要有消息传送到服务器端。在通常的有网络连接的模式下，这样的更新消息是同步传送给服务器的，也就是说当客户端作了更新的时候服务器端同时也作更新。如果服务器暂时不可用，或者服务器和客户端之间的网络连 接出现了故障，这种更新操作会报告一个超时错误并且会失败。在网络连接失效的情况下，有些操作是不可能完成的。比如试图从服务器上获取本地缓存中没有的文件。在这样的情况下，必须向调用的程序报告错误。然而，大多数的超时错误可以按照下面提到的办法处理。

 

为了支持离线操作或者暂时的网络故障，Venus不会向用户报告更新超时错误。Venus会发现服务器出现了暂时不可用的问题，并且把这些更新在客 户端暂时作记录。在离线状态下，所有的更新都被记录在客户端修改日志（CML, client modification log）中。这个日志会经常地被写入到磁盘中。当coda切换到离线模式的时候，用户不会发觉任何的区别。当与服务器重新建立连接后，Venus将重建 CML。他将向服务器重新提交文件系统的更改，以便让服务器端的文件也保持最新。CML是经过优化处理的。他会自动取消类似建立一个文件然后又删除这样的操作。

 

除上面提到的几点，另外还有两个与离线操作有关的问题。第一，离线操作是一个临时储存文件的概念。当缓存没有命中并且Venus无法连接到服务器 时，它需要尽可能的使关键文件保持最新，这就需要他不断的去要求服务器发送来最新的文件。这些关键文件就存放在用户的临时储存数据库中（这个数据库通过跟踪用户的访问自动建立）。我们把更新临时储存文件的工作叫做"hoard walk"。在实际操作中，我们的笔记本储存了大量的系统软件，比如X11视窗系统的二进制文件和库，或者Wabi以及Microsoft Office。这些文件都像本地文件一样，储存的应用程序可以很好的运行。

 

Fig 4: 临时文件被"粘"在缓存中 (原图作者: Gaich Muramatsu)

 

第二个问题是在恢复连接之后重新处理修改过的文件时会遇到的。假如有多个客户端对同一个文件作了修改，并且都传送到了服务器，那么就会出现冲突。我们把这样的冲突叫做局部/全局冲突（local/global）或者叫做客户端/服务器冲突（client/server）。这样的冲突有时候可以通过专 门的解决方法来自动修复（比如一个客户端向日历文件中写入周一的安排另一个客户端插入了一个周三的安排。这样的情况就是可以解决的冲突）。当然，有些时候冲突是不能自动解决的，这就需要受人工的干预来进行处理。

 

假设我们在一个周五带着装满了源代码的笔记本离开了办公室去出差。在处理完堆积如山的工作之后，隔周的周一(也就是10天后)我们回到了办公室。当笔记本重新连接后，系统就会自动更新这些代码。这就是我们说所的移动办公。

 

Fig. 5 错误恢复的方法