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

Coda客户端

 

假设我们在一个Linux工作站上运行coda客户端，输入mount后我们将会看到一种类型为"coda"的文件系统被挂在 /coda 。这个目录下就是服务器向客户端提供的文件，所有的客户端看到的都是相同的文件名、相同的空间。客户端连接的是"coda"，并不是连接到了某个单独的服 务器，这一切都是对客户不可见的。这与挂载单独一个服务器上的网络文件系统是有很大的区别的。常见的Windows下的文件系统（Novell和微软的 CIFS）以及Macintosh使用的Appleshare 文件系统都是按照单一的卷来挂载。当然，全局共享空间并不是coda发明的。Coda的前身-Andrew文件系统(AFS)首先提出了存储所有的文件在 /afs 。类似的，OSF中的DFS/DCE分布式文件系统也是将所有的文件挂载在同一个目录下。微软新开发的分布式文件系统(DFS)支持所有的服务器共享同样 的一个文件树，就像是unix下auto-mount守护进程和yellow pages的组合。为什么说单一的挂载点更好？这主要是因为所有的客户端可以被相同的配置，所有的用户永远都是看到相同的文件树。对于客户端数量非常多的情况下，使用相同的配置是很重要的一点。假设使用NFS,客户端需要更新服务器的列表并且在/etc/fstab中存入相应的挂载点。使用coda的话， 客户端只需要知道coda的根目录是在/coda。当添加新的服务器或者添加新的共享目录时客户端会从/coda的目录树中自动获得信息。

 

了能理解在服务器连接在网络上的时候coda如何运作，我们首先分析一个简单的文件操作。假设我们通过输入"cat /coda/tmp/foo"来显示一个coda文件的内容。首先，cat程序将要进行一些和文件有关的系统调用。系统调用是程序要求内核进行某种服务的 操作。比如，当打开文件的时候，内核首先会去找i结点然后返回一个指向该文件的句柄给调用的程序。i结点中保存了可以让内核获取的如何调用文件的信息。文件句柄是为需要的程序准备的。外部的调用进入系统内核的虚拟文件系统(VFS)，他发现调用的是在/coda下面的一个文件后就通过内核中coda文件系 统的模块来处理。Coda是最低的最基本的文件系统模块，他保存最近的从虚拟文件系统中得到的回复,将请求送到Coda缓存管理系统。这个缓存管理系统被 命名为Venus。Venus首先检查客户端磁盘缓存中是否有tmp/foo,如果缓存没有命中，她将会连接服务器以便获取tmp/foo。当文件定位 后，Venus将向内核报告，并且最终从系统调用返回到应用程序。下图就是刚才提到的过程的图示。

 

Fig 3. Client/Venus/Vice

 

这张图表展示的就是应用程序通过系统调用来要求内核提供相应服务的过程。内核将请求送到Venus, Venus读取设备文件/dev/cfs0来获知请求。Venus通过读取cache、发送请求到服务器，或者按照离线模式来处理这些请求。离线模式是指无法连接到存放该文件的服务器的情况。一般情况是指使用没有和原有网络连接的笔记本，或者网络连接出现了问题才会进入离线模式。当服务器出现问题的时候也 会进入离线模式。

 

当内核第一次将外部请求送到Venus的时候，Venus将通过远程程序调用(RPC)方式从服务器端下载整个文件，然后将文件作为一个文件容器存放在缓存中（目前是/usr/coda/venus.cache/）。从这时起，文件就作为了一个本地的普通文件，所有的读写操作都不会涉及到 Venus，只会涉及到本地文件系统（比如在Linux下可能是ext2文件系统）。Coda的读写操作的速度是由本地文件系统响应操作的速度决定的。如果文件再一次被打开，文件不会从服务器中再次传送，而是使用本地保存的那一份。目录文件(需要注意的是目录也只是一个文件而已)以及属性（比如属主、权 限、大小）都会被Venus暂存。Venus允许本地缓存中有需要的文件的时候不连接服务器对文件进行操作。当文件被修改并且关闭后， Venus将向服务器发送一个修改之后的新文件。其他的修改文件系统的行为，比如建立目录、删除文件或目录、建立或删除连接（或符号连接）同样也会向服务器发送。

 

我们可以发现coda的缓存系统保存了客户需要的所有的信息，并且只在需要更新文件系统的时候才与服务器进行联系。研究表明，对文件的只读操作要比修改操作多很多。因此我们主要研究的是如何减少客户和服务器之间的通信。主动缓存已经在AFS和DFS上实现，但是大多数的其他的系统没有做这样的工作。 在下面我们会看到coda如何保持文件的一致性，但首先我们先来讲将如何支持离线操作。