顺序不分先后：
Lustre
Lustre is a scalable, secure, robust, highly-available cluster file system. It is designed, developed and maintained by Sun Microsystems, Inc.
Designed to meet the demands of the world’s largest high-performance compute clusters, the Lustre file system redefines scalability and provides groundbreaking I/O and metadata throughput. An object-based cluster, Lustre currently supports tens of thousands of nodes, petabytes of data, and billions of files — and development is underway to support one million nodes, trillions of files, and zetta to yotta bytes.
http://www.sun.com/software/products/lustre/
http://wiki.huihoo.com/index.php?title=Lustre
AFS
AFS Reference Page
OpenAFS
What is AFS?
AFS is a distributed filesystem product, pioneered at Carnegie Mellon University and supported and developed as a product by Transarc Corporation (now IBM Pittsburgh Labs). It offers a client-server architecture for file sharing, providing location independence, scalability and transparent migration capabilities for data. OpenAFS is the Transarc source code released as it looked like around AFS3.6 under IBM Public License IPL.
Arla
Arla is a free AFS implementation.
The main goal is to make a fully functional client with all capabilities of AFS as formerly sold by Transarc and today available as OpenAFS. Other stuff, such as servers and management tools are being developed, but currently not considered stable.
Coda
Coda分布式文件系统， Coda File System http://www.coda.cs.cmu.edu/
Coda is a forked of version of AFS that support disconnected and weakly connected mode better then AFS.
InterMezzo
InterMezzo is a new distributed file system with a focus on high availability. InterMezzo will be suitable for replication of servers, mobile computing, managing system software on large clusters, and for maintenance of high availability clusters.
xFS
xFS is a Serverless Network File Service.
CFS
Cluster File Systems, Inc. is the leading developer of next generation technology for scalable high-performance file systems. Our Lustre® file system redefines scalability and has been designed from the ground up to meet the demands of the world’s largest high-performance computer clusters.
GlusterFS
GlusterFS is a cluster file-system capable of scaling to several peta-bytes. It aggregates various storage bricks over Infiniband RDMA or TCP/IP interconnect into one large parallel network file system. GlusterFS is based on a stackable user space design without compromising performance.
Scalable File Share
HP StorageWorks Scalable File Share
A high-bandwidth, scalable storage appliance for Linux clusters
http://h20311.www2.hp.com/HPC/cache/276636-0-0-0-121.html
MogileFS
MogileFS is our open source distributed filesystem. Its properties and features include:
-1. Application level
-2. No single point of failure
-3. Autumaic file replication
-4. “Better than RAID”
-5. Flat Namespace
-6. Shared-Nothing
-7. No RAID required
-8. Local filesystem agnostic
Hadoop
The Apache Hadoop project develops open-source software for reliable, scalable, distributed computing, including:
* Hadoop Core, our flagship sub-project, provides a distributed filesystem (HDFS) and support for the MapReduce distributed computing metaphor.
* HBase builds on Hadoop Core to provide a scalable, distributed database.
* ZooKeeper is a highly available and reliable coordination system. Distributed applications use ZooKeeper to store and mediate updates for critical shared state.
PVFS
http://www.pvfs.org/
http://www.parl.clemson.edu/pvfs/
PVFS is designed to provide high performance for parallel applications, where concurrent, large IO and many file accesses are common. PVFS provides dynamic distribution of IO and metadata, avoiding single points of contention, and allowing for scaling to high-end terascale and petascale systems.
GFS
http://en.wikipedia.org/wiki/Global_File_System
http://www.redhat.com/docs/manuals/csgfs/
GFS (Global File System) is a cluster file system. It allows a cluster of computers to simultaneously use a block device that is shared between them (with FC, iSCSI, NBD, etc…). GFS reads and writes to the block device like a local filesystem, but also uses a lock module to allow the computers coordinate their I/O so filesystem consistency is maintained. One of the nifty features of GFS is perfect consistency — changes made to the filesystem on one machine show up immediately on all other machines in the cluster.
See also
————–
The first to work with a CFS is HP OpenVMS. Oracle Parallel Server and RAC always used
the OpenVMS filesystem (RMS) for its database.
2 HP Tru64
————
CFS is a layer on top of Advfs the filesystem of HP Tru64. Oracle uses
the Direct I/O feature available in CFS. Direct I/O enables Oracle to bypass
the buffer cache (no caching at filesystem level). Oracle manages the
concurrent access to the file itself; as it does on raw devices. On CFS,
without Direct I/O enabled on files – file access goes through a CFS server.
A CFS server runs on a cluster member and serves a file domain. A file
domain can be relocated from one cluster member to another cluster member
online. A file domain may contain one or more filesystems.
Direct I/O does not go through the CFS server, but file creation and resizing
is seen as metadata operation by advfs and this has to be done by the CFS
server. The consequence is to run file creations and resizing on the node
where the CFS server is located. File operations might take longer when the
CFS server is remote.
Oracle recommends not using the tempfile option, as tempfiles might not be
allocated until the tempfile blocks are accessed and so cause
‘remote metadata operations’ for advfs.
3 Veritas
———–
VERITAS Database EditionTM / Advanced Cluster for Oracle9i RAC enables Oracle
to use the CFS. The VERITAS Cluster File System is an extension of the VERITAS
File System (VxFS). Veritas CFS allows the same filesystem to be simultaneously
mounted on multiple nodes. Veritas CFS is designed with a master/slave
architecture. Any node can initiate a metadata operation (create, delete, or
resize data), the actual operation is carried out by the master node. All other
(non metadata) IO goes directly to the disk.
CFS is used in DBE/AC to manage a filesystem in a large database environment.
When used in DBE/AC for Oracle9i RAC, Oracle accesses data files stored on CFS
filesystems by bypassing the filesystem buffer and filesystem locking for data.
4 Oracle Cluster File System
——————————
Oracle Cluster File System (OCFS) is a shared filesystem designed specifically
for Oracle Real Application Clusters. OCFS eliminates the requirement for Oracle
database files to be linked to logical drives and enables all nodes to share a
single Oracle_Home (current capabilities are detailed in section 2.8) instead
of requiring each node to have its own local copy. OCFS volumes can span one
shared disk or multiple shared disks for redundancy and performance
enhancements.
5. Netapp(R) Filer
——————-
Netapp Filer offers CFS functionality via NFS to the server machines. These
filesystems are mounted using special mount options. For details please see
Netapp documentation.
Netapp certifications can be found at:
http://www.netapp.com/part…
To understand the architecture and Oracle installation please see these
documents:
Note 210889.1: RAC Installation with a NetApp Filer in Red Hat Linux Environment
and
Oracle9i RAC Installation with a NetApp Filer on Fujitsu-Siemens Primepower
(Solaris8 Operating System) at http://www.netapp.com/tech…
6 AIX
——-
IBM’s General Parallel File System (GPFS) allows users shared access to files
that may span multiple disk drives on multiple nodes. GPFS provides access to
all data from all nodes of the cluster. It can be configured with multiple
copies of metadata allowing continued operation should the paths to a disk or
the disk itself be broken. Metadata is the filesystem data that describes
the user data. GPFS allows the use of RAID or other hardware redundancy
capabilities to enhance reliability.
In Oracle9i GPFS is only supported with HACMP/ES in a RAC configuration.
When placing datafiles on GPFS no CRM (Concurrent Resource Manager) needs to be
installed. Starting with Oracle10g HACMP is no longer required to use GPFS.
Metalink contains certification information and information about required
patches for having a cluster database on a GPFS.
7 Sun GFS
———–
Global File Service (GFS or Cluster File System) is a filesystem that is
accessible from all nodes in the cluster. GFS is based on global devices and
has a client/server architecure. GFS provides transparent and concurrent file
access.
Note that Sun GFS is not supported for Oracle datafiles, see section 3.10.
8 Sun StorEdge QFS
——————–
QFS software is a file manager that provides a shared filesystem where mutiple
servers can read and write simultanuously to the same file in the same filesystem.
9 Other Linux Cluster Filesystems
———————————–
There are various third party cluster filesystems available on Linux.
Consult the Oracle Certify website for the policy regarding support for third party
cluster file systems on Linux. Also, consult the RAC Technology Compatibility Matrix (RTCM)
for Linux (http://www.oracle.com/tech… … generic_linux.html)
for the latest information on which third party cluster file systems are supported
by RAC release and platform.
10 Which Platforms support what?
———————————-
Platform and Storage for Storage for
[Cluster Software] Oracle installation datafiles
AIX [HACMP] LFS (1) or CFS (2) CFS and/or Raw devices
AIX [CRS] LFS or CFS CFS and/or Raw devices
HP/UX [MC/Service Guard] LFS or CFS (3) CFS (3) and/or Raw Devices
HP/UX PA-Risc [Veritas DBE/AC) LFS or CFS CFS and/or Raw Devices
Linux [oracm, CRS] LFS OCFS (4) and/or Raw
Devices, also NFS (5)
OpenVMS CFS CFS
Sun Solaris [Fujitsu Siemens LFS Raw Devices/NFS (5)
Primecluster]
Sun Solaris [Sun Cluster] LFS or CFS (6,7) CFS (7) Raw Devices/NFS (5)
Sun Solaris [Veritas DBE/AC] LFS or CFS CFS and/or Raw Devices
Tru64 Unix LFS or CFS CFS and/or Raw Devices
Windows NT/2000 [oracm, CRS] LFS or CFS OCFS and/or Raw Devices
Windows 2003 (32/64bit) [oracm, CRS] LFS or CFS OCFS and/or Raw Devices
(1) LFS is the abbreviation for local filesystem and is only accessible directly
by the node that mounted the disk
(2) CFS is the abbreviation for Cluster FileSystem. The implementation
depends on the operating software vendor or cluster software vendor.
(3) MC ServiceGuard 11.17 includes a CFS which is supported with Oracle 10gR2
(4) OCFS: Oracle Cluster FileSystem
(5) NFS is supported with Netapp(R) Filer, see Metalink certification
(6) Sun GFS can only be used for Oracle_Home and archivelogs.
(7) Sun StorEdge QFS
Local Filesystem means that the Oracle Universal Installer replicates the
RAC software installation automatically to every private filesystem of the
selected nodes in the cluster. The Oracle installation products
are cluster aware and will not install the Oracle software to over-write itself.
Oracm is the Oracle Cluster manager, which is available on Linux and Windows
NT/2000. No other cluster manager is needed to setup Real Application Cluster.
Cluster Ready Services (CRS) are new in Oracle10g and provide also clustermanager
functionality.
Oracle will validate cluster filesystems of other vendors when they become
available. Oracle will support the Oracle software when running on a validated
cluster filesystem.
11 Cluster File System names
——————————
PLatform or Cluster Vendor CFS name
AIX GPFS
HP/UX MC/ServiceGuard CFS
Linux [oracm, CRS] OCFS
OpenVMS RMS
Tru64 Unix CFS
SunCluster GFS, QFS
Veritas DBE/AC CFS
Windows NT/2000 OCFS
Windows 2003 (32/64bit) OCFS
For more information on certified configuration please see the certification
matrix available on Metalink. Instructions for accessing the certification
matrix can be found in the following note:
Note 184875.1
How To Check The Certification Matrix for Real Application Clusters
12 When to use CFS over raw?
——————————
This option is very dependent on the availability of a CFS on your platform.
A CFS offers:
- Simpler management
- Use of Oracle Managed Files with RAC
- Single Oracle Software installation
- Autoextend enabled on Oracle datafiles
- Uniform accessibility to archive logs in case of physical node failure
- With Oracle_Home on CFS, when you apply Oracle patches CFS guarantees that
the updated Oracle_Home is visible to all nodes in the cluster。
---------------------------------------------------------------------------------
Coda分布式文件系统
原著：Peter J. Braam
设计一个好的分布式文件系统需要处理很多的问题。由于网络本身的瓶颈和服务器的超负荷工作，在网络中传送大量的文件通常是效率很 低并且有延迟。数据的安全性也是另外的一个需要特别注意的方面，我们必须确认访问数据的客户端确实是经过我们认证的，并且数据在传送过程中没有泄漏。另外 还有两个和故障处理有关的方面。通常情况下客户端相对网络连接来说出故障的可能性更小。网络的故障会造成客户端不再使用的假象。同样，服务器的故障会令人 更加不悦，因为它会造成所有的客户端无法访问急需的信息。Coda作为一个分布式文件系统的研究原型将会一一处理上面提到的问题。
了 能理解在服务器连接在网络上的时候coda如何运作，我们首先分析一个简单的文件操作。假设我们通过输入"cat /coda/tmp/foo"来显示一个coda文件的内容。首先，cat程序将要进行一些和文件有关的系统调用。系统调用是程序要求内核进行某种服务的 操作。比如，当打开文件的时候，内核首先会去找i结点然后返回一个指向该文件的句柄给调用的程序。i结点中保存了可以让内核获取的如何调用文件的信息。文 件句柄是为需要的程序准备的。外部的调用进入系统内核的虚拟文件系统(VFS)，他发现调用的是在/coda下面的一个文件后就通过内核中coda文件系 统的模块来处理。Coda是最低的最基本的文件系统模块，他保存最近的从虚拟文件系统中得到的回复,将请求送到Coda缓存管理系统。这个缓存管理系统被 命名为Venus。Venus首先检查客户端磁盘缓存中是否有tmp/foo,如果缓存没有命中，她将会连接服务器以便获取tmp/foo。当文件定位 后，Venus将向内核报告，并且最终从系统调用返回到应用程序。下图就是刚才提到的过程的图示。
当内核第一次将外部请求送到Venus的时候，Venus将通过远程程序调用(RPC)方式从服务器端下载整个文件，然后 将文件作为一个文件容器存放在缓存中（目前是/usr/coda/venus.cache/）。从这时起，文件就作为了一个本地的普通文件，所有的读写操 作都不会涉及到Venus，只会涉及到本地文件系统（比如在Linux下可能是ext2文件系统）。Coda的读写操作的速度是由本地文件系统响应操作的 速度决定的。如果文件再一次被打开，文件不会从服务器中再次传送，而是使用本地保存的那一份。目录文件(需要注意的是目录也只是一个文件而已)以及属性 （比如属主、权限、大小）都会被Venus暂存。Venus允许本地缓存中有需要的文件的时候不连接服务器对文件进行操作。当文件被修改并且关闭 后，Venus将向服务器发送一个修改之后的新文件。其他的修改文件系统的行为，比如建立目录、删除文件或目录、建立或删除连接（或符号连接）同样也会向 服务器发送。
我们可以发现coda的缓存系统保存了客户需要的所有的信息，并且只在需要更新文件系统的时候才与服务器进行联系。研究表明， 对文件的只读操作要比修改操作多很多。因此我们主要研究的是如何减少客户和服务器之间的通信。主动缓存已经在AFS和DFS上实现，但是大多数的其他的系 统没有做这样的工作。在下面我们会看到coda如何保持文件的一致性，但首先我们先来讲将如何支持离线操作。
在前面的一段中，我们已经讲到coda缓存所有的访问需要的信息。当做出对文件系统的更新后，需要有消息传送到服务器端。 在通常的有网络连接的模式下，这样的更新消息是同步传送给服务器的，也就是说当客户端作了更新的时候服务器端同时也作更新。如果服务器暂时不可用，或者服 务器和客户端之间的网络连接出现了故障，这种更新操作会报告一个超时错误并且会失败。在网络连接失效的情况下，有些操作是不可能完成的。比如试图从服务器 上获取本地缓存中没有的文件。在这样的情况下，必须向调用的程序报告错误。然而，大多数的超时错误可以按照下面提到的办法处理。
为了支持离 线操作或者暂时的网络故障，Venus不会向用户报告更新超时错误。Venus会发现服务器出现了暂时不可用的问题，并且把这些更新在客户端暂时作记录。 在离线状态下，所有的更新都被记录在客户端修改日志（CML, client modification log）中。这个日志会经常地被写入到磁盘中。当coda切换到离线模式的时候，用户不会发觉任何的区别。当与服务器重新建立连接后，Venus将重建 CML。他将向服务器重新提交文件系统的更改，以便让服务器端的文件也保持最新。CML是经过优化处理的。他会自动取消类似建立一个文件然后又删除这样的 操作。
除上面提到的几点，另外还有两个与离线操作有关的问题。第一，离线操作是一个临时储存文件的概念。当缓存没有命中并且Venus无法 连接到服务器时，它需要尽可能的使关键文件保持最新，这就需要他不断的去要求服务器发送来最新的文件。这些关键文件就存放在用户的临时储存数据库中（这个 数据库通过跟踪用户的访问自动建立）。我们把更新临时储存文件的工作叫做"hoard walk"。在实际操作中，我们的笔记本储存了大量的系统软件，比如X11视窗系统的二进制文件和库，或者Wabi以及Microsoft Office。这些文件都像本地文件一样，储存的应用程序可以很好的运行。
假设我们在一个周五带着装满了源代码的笔记本离开了办公室去出差。在处理完堆积如山的工作之后，隔周的周一(也就是10天后)我们回到了办公室。当笔记本重新连接后，系统就会自动更新这些代码。这就是我们说所的移动办公。
Coda服务器上的文件并不是存放在通常的文件系统上的。对于这些文件的组织如下所示。Coda 服务器以及工作站的分区作为对文件服务器可用的部分。这些分区将存放按照卷的方式来管理的文件。每一个卷带有一个和文件系统一样的目录结构，也就是说一个 卷的根目录以及根目录下的目录树。相对于分区来说，卷要小，但是相对于单一个目录或者单一的文件的逻辑单位来说，卷要大。举例来说，某个用户的home目 录可能就是一个单独的coda卷，coda相关的资源就存放在这个卷里面。通常情况下一个单独的服务器可能包含数百个卷，每个卷的平均大小可能是10兆。 从系统管理员的角度来看，卷是一个易于管理的很灵活的普通的文件数据。
Coda将卷、目录、访问控制列表以及文件的属性保存在一个raw分 区中。通过一种基于日志的可恢复的虚拟内存系统 (log based recoverable virtual memory package, RVM)来实现快速并且确保一致性的访问。只有文件的数据保存在服务器的分区上。通过RVM可以实现对事务的支持，也就是说当服务器崩溃后，不用花费太多 的力气就可以恢复整个系统。
卷带有一个名称和他自己的编号，卷可以被挂载到/coda下的任何一个位置。比如要使一个叫做u.braam的 卷挂载到/coda/usr/braam，只需要执行"cfs makemount u.bramm /coda/usr/braam"。Coda不允许挂载点是一个已经存在的目录。他会把建立一个新的目录作为挂载的过程之一。这样做避免了将unix文件 系统挂载到已经存在的目录下。这个操作和Macintosh以及Windows的网络驱动器及共享很类似。但是最明显的区别是挂载点对于客户端是不可见 的。他看起来只是一个/coda下的很普通的目录。系统中有一个单独的卷具有作为根卷的权限，这个卷在启动的时候就被挂载。
Coda通过三 组32位的整数来标示一个文件。这组整数被称为Fid。Fid包含卷编号(VolumeID)、V结点编号(VnodeID)以及一个全局唯一标识符 (Uniquifier)。通过卷编号来确定文件存储的卷。V结点编号就是文件的i结点编号。全局唯一标识符来是为保持文件一致性处理准备的。Fid在 Coda服务器集群中是唯一的。
在coda服务器之间是有读写复制的。也就是说一组服务器向客户端发送文件数据，对文件的更新也会在这组服 务器中执行。这样做的好处是提高了数据的可用性，假如一个服务器出现了问题，其他的服务器会自动接替，客户端不会受到任何影响。卷可以存放在一组服务器 中，我们把这样的一组服务器叫做VSG(Volume Storage Group)。
这些复制的卷的卷编号也是被复制的。复制后的卷编号将本地的卷结合在一起成为VSG。
VSG是一个保存复制后卷的服务器列表。
每个服务器的本地卷定义了一个分区和本地的卷编号来保存文件和元数据。
当 Venus要访问服务器上的对象，他首先需要找到卷信息以便确定保存该文件的卷。这个卷信息包含服务器列表和存放该文件的服务器上的卷编号。在VSG中的 服务器之间关于文件的通信是读一次写多次的操作，即读取VSG中某一个服务器上的文件然后向所有的可用的VSG成员传播更新的消息。我们把可用的VSG成 员叫做AVSG(Available VSG members)。Coda可以使用多点传送RPC来向很多服务器提交更新操作，这样做不会对整体的性能有太大的影响。
前面讲到的必须首先 获得卷信息有时候会给人带来误解。一旦获取卷信息之后，接下来的文件访问因为路径遍历的减少而受益。这是因为卷的根相对通常的挂载了很大的目录来说要近很 多。（译者注：前文中提到每个卷都有自己根以及目录树，而卷可能会挂载在很深的目录中。直接从相应卷的根来找文件显然要比从/coda找文件要快。）
服 务器之间的复制就像是离线操作一样有两点需要介绍：决定是否复制以及如何修复错误。某些在VSG中的服务器可能因为服务器或者网络的故障和其他的服务器隔 离开了。在这样的情况下AVSG保存的对象一定会比VSG少。更新无法传递到所有的服务器上，只能传送到AVSG，从而会导致全局（服务器与服务器之间） 冲突。
服务期间的复制和解决不一致的情况看起来是不可思议的操作。我们的服务器经常出现磁盘故障。为了修复服务器所需做的工作只是替换新的磁盘然后告诉coda:去解决他吧。系统会自动向磁盘写入从别的服务器上获取的最新的数据。
我们已经使用这个系统很多年 了，从来没有发生过丢失用户数据的现象。有些时候服务器上的磁盘报废了，但当所有的卷都被复制后，我们将一个空的磁盘放入到服务器中并且让保持一致性的系 统来自动更新数据。所需要做的工作实际上只是在放入新磁盘后在受到影响的目录树下运行"ls -lR"。服务器会发现缺少的文件，负责保持一致性的进程会将文件从正常的服务器上传送到新修复好的服务器。
WWW服务器也可以作为coda客户端。很多ISP因为 WWW服务器短缺而很头痛。对于单一的http服务器来说，访问量实在是太大了。已经证明使用NFS来共享文件会造成效率上面的问题，手动的在某几个特定 的服务器之间复制文件是经常需要做的操作。Coda可以解决这样的问题。每个服务器作为一个coda客户端，将数据保存在自己的缓存中。访问的速度是由本 地磁盘的速度来决定的。ISP可以离线来更改他们网页的信息，我们也为移动客户端做了一个很好用的应用程序。
网络计算机可以通过使用coda作为缓存来大大的提高性能。当服务器可用的时候，网络计算机会自动去更新。大多数的操作是没有网络流量的，即使重新启动。
我 们现在要做的工作主要是提高Coda的质量。Coda的轮廓已经通过研究大体勾划出来了。回写式缓存将加入到Coda中以便能更高速的运转。离线操作是一 种很特殊的回写缓存操作。我们正在利用离线操作的代码来实现在线时的回写缓存。Kerberos的支持已经加入。网络协议对Coda的支持使这个很容易做 到。我们希望在未来能做到让Coda客户端同时连接多个Coda服务器集群，并且把Coda移植到尽可能多的操作系统上。
客户端在与服务器建立连接之后会在本地生成一个新的文件系统/coda，这个文件系统下的所有文件是与服务器上的一个用户数据目录保持 同步的，服务器上的用户数据目录是在安装服务器软件时指定专门用来存放用户数据的，即在客户端的/coda目录下保存的所有文件，实际上都是服务器上的一 个备份，只要服务器上的文件发生了变化，则/coda目录下的文件也会发生相应的变化，这就是说，只要有一个客户端操作了/coda下的某个文件，则所有 客户端/coda下的对应文件就都要发生变化，同时服务器之间也要保持同步。
安装实例：
一、SCM服务器安装
1.需要的分区/目录
/vice 存放配置文件
/vicepa 存放用户数据文件
/LOG RVM处理日志用，最大为50M，如果为分区，不要自动mount
/DATA RVM数据存储区，大小为/vicepa大小的4%左右，如果为分区，不要自动mount
以上都可以为分区或者是目录。
2.安装软件
lwp-release.i386.rpm
rvm-release.i386.rpm
rpc2-release.i386.rpm
coda-debug-server-release.i386.rpm
3.配置coda服务器
运行vice-setup
按照配置向导一步一步配置，需要注意的有：
作为SCM服务器安装；
设置用户；uid和用户名，在客户端登录服务器时要用到
设置root volume:后面创建root volume时用到
4.运行coda服务器
(1)在运行前需要修改一个配置文件，/etc/coda/server.conf，把文件中的ip地址和主机名参数设置好
(2)运行相关程序
auth2
rpc2portmap
updatesrv
updateclnt -h SCM_SERVER_NAME
startserver &
(3)检查服务运行是否正常
tail -f /vice/srv/SrvLog
5.关闭命令
volutil shutdown
然后查看日志(/vice/srv/SrvLog)检查是否完全关闭
6.创建root volume
createvol_rep codaroot E0000100 /vicepa
其中codaroot为配置SCM的时候(vice-setup)指定的，/vicepa为用户数据目录，也是配置的时候指定的。
二、non-SCM服务器安装
安装过程基本上都是一样，只是在配置时，需要指定服务器为non-SCM服务器，同时指定SCM服务器的主机名(需要在hosts文件中指定域名解析)。
在运行non-SCM服务器时有一点不一样：
auth2 -chk
rpc2portmap
updatesrv
updateclnt -h SCM_SERVER_NAME
startserver &
然后检查目录/vice/db，看是否从SCM服务器上把相关的配置文件拷贝了过来。
三、客户端的安装
1.安装软件包
lwp-release.i386.rpm
rvm-release.i386.rpm
rvm-tools-release.i386.rpm
rpc2-release.i386.rpm
coda-debug-client-release.i386.rpm
2.配置
运行 venus-setup coda-servers cach-size
例如：venus-setup sproxy,SWWW 4000(40M)
coda-servers表示该客户端可以与哪些coda服务器连接，cach-size表示/coda文件系统的大小，即用来保存所有需要保持同步的文件的容量。
3.运行
venus &
4.检查日志
tail -f /usr/coda/etc/console
5.停止
vutile shutdown
四、coda的使用
在服务器和客户端都安装好了之后，就可以开始使用coda文件系统了，coda文件系统的使用可以分为3个步骤：
1.在SCM上创建volume
volume实际上是这样一个概念，它是一个比文件分区小，比文件目录大的一种文件组织方式，即在一个volume中可以包含很多个文件目录或者文件。
2.在客户端（coda-client）上mount创建的volume
3.在客户端上使用coda文件系统，如，文件的创建、删除等
下面举例说明以上3个步骤：
1.在SCM上创建root volume
createvol_rep codaroot E0000100 /vicepa
其中codaroot是在配置SCM的时候指定的root volmue的名字，/vicepa为用户数据目录，也是在配置的时候指定的。
2.如果存在多个coda server，即存在non-SCM，则还可以修改两个文件，/vice/db/VSGDB和/vice/db/servers,
/vice/db/VSGDB:
E0000100 sproxy swww sproxy2
其中：sproxy为SCM,swww,sproxy2为non-SCM
/vice/db/servers:
sproxy 1
swww 2
sproxy2 3
sproxy，swww，sproxy2为各个主机的主机名，1,2,3为配置过程中指定的serverid。
3.创建其他的volume，如，创建一个名为apache的volume
首先在SCM的/vice/db/VSGDB文件中增加一行：
E0000100 sproxy swww sproxy2 (已有的root volume)
E0000101 sproxy swww sproxy2 (增加的)
然后在SCM上运行(sproxy为SCM)：
bldvldb.sh swww
bldvldb.sh sproxy2
最后创建volume:
createvol_rep apache E0000101 /vicepa
在服务器上创建了volume后，就可以在client上使用volume了。
4.用clog命令登录coda服务器
clog coda
password:changme
或者是：clog coda
首先要保证venus已经运行起来，coda用户是在配置服务器的时候指定的，也可以使用在服务器上用程序添加的用户，changme为默认口令，即没有修改过的口令。
5.mount服务器上存在的volume
cfs mkmount /coda/apache apache
把apache volume mount在/coda/apache目录
6.操作/coda/apache目录
Lustre
Lustre is a scalable, secure, robust, highly-available cluster file system. It is designed, developed and maintained by Sun Microsystems, Inc.
Designed to meet the demands of the world’s largest high-performance compute clusters, the Lustre file system redefines scalability and provides groundbreaking I/O and metadata throughput. An object-based cluster, Lustre currently supports tens of thousands of nodes, petabytes of data, and billions of files — and development is underway to support one million nodes, trillions of files, and zetta to yotta bytes.
http://www.sun.com/software/products/lustre/
http://wiki.huihoo.com/index.php?title=Lustre
AFS
AFS Reference Page
OpenAFS
What is AFS?
AFS is a distributed filesystem product, pioneered at Carnegie Mellon University and supported and developed as a product by Transarc Corporation (now IBM Pittsburgh Labs). It offers a client-server architecture for file sharing, providing location independence, scalability and transparent migration capabilities for data. OpenAFS is the Transarc source code released as it looked like around AFS3.6 under IBM Public License IPL.
Arla
Arla is a free AFS implementation.
The main goal is to make a fully functional client with all capabilities of AFS as formerly sold by Transarc and today available as OpenAFS. Other stuff, such as servers and management tools are being developed, but currently not considered stable.
Coda
Coda分布式文件系统， Coda File System http://www.coda.cs.cmu.edu/
Coda is a forked of version of AFS that support disconnected and weakly connected mode better then AFS.
InterMezzo
InterMezzo is a new distributed file system with a focus on high availability. InterMezzo will be suitable for replication of servers, mobile computing, managing system software on large clusters, and for maintenance of high availability clusters.
xFS
xFS is a Serverless Network File Service.
CFS
Cluster File Systems, Inc. is the leading developer of next generation technology for scalable high-performance file systems. Our Lustre® file system redefines scalability and has been designed from the ground up to meet the demands of the world’s largest high-performance computer clusters.
GlusterFS
GlusterFS is a cluster file-system capable of scaling to several peta-bytes. It aggregates various storage bricks over Infiniband RDMA or TCP/IP interconnect into one large parallel network file system. GlusterFS is based on a stackable user space design without compromising performance.
Scalable File Share
HP StorageWorks Scalable File Share
A high-bandwidth, scalable storage appliance for Linux clusters
http://h20311.www2.hp.com/HPC/cache/276636-0-0-0-121.html
MogileFS
MogileFS is our open source distributed filesystem. Its properties and features include:
-1. Application level
-2. No single point of failure
-3. Autumaic file replication
-4. “Better than RAID”
-5. Flat Namespace
-6. Shared-Nothing
-7. No RAID required
-8. Local filesystem agnostic
Hadoop
The Apache Hadoop project develops open-source software for reliable, scalable, distributed computing, including:
* Hadoop Core, our flagship sub-project, provides a distributed filesystem (HDFS) and support for the MapReduce distributed computing metaphor.
* HBase builds on Hadoop Core to provide a scalable, distributed database.
* ZooKeeper is a highly available and reliable coordination system. Distributed applications use ZooKeeper to store and mediate updates for critical shared state.
PVFS
http://www.pvfs.org/
http://www.parl.clemson.edu/pvfs/
PVFS is designed to provide high performance for parallel applications, where concurrent, large IO and many file accesses are common. PVFS provides dynamic distribution of IO and metadata, avoiding single points of contention, and allowing for scaling to high-end terascale and petascale systems.
GFS
http://en.wikipedia.org/wiki/Global_File_System
http://www.redhat.com/docs/manuals/csgfs/
GFS (Global File System) is a cluster file system. It allows a cluster of computers to simultaneously use a block device that is shared between them (with FC, iSCSI, NBD, etc…). GFS reads and writes to the block device like a local filesystem, but also uses a lock module to allow the computers coordinate their I/O so filesystem consistency is maintained. One of the nifty features of GFS is perfect consistency — changes made to the filesystem on one machine show up immediately on all other machines in the cluster.
See also
- Comparison of file systems
- GPFS, ZFS
- Lustre
- GlusterFS
- List of file systems
- Oracle cluster file system (OCFS)
- SAN file system
- Fencing
- Red Hat GFS Product Page
- Red Hat Cluster Suite and GFS Documentation Page
- GFS Project Page
- DataCore’s GFS Informations
- OpenGFS Project Page
- The GFS2 development git tree
————–
The first to work with a CFS is HP OpenVMS. Oracle Parallel Server and RAC always used
the OpenVMS filesystem (RMS) for its database.
2 HP Tru64
————
CFS is a layer on top of Advfs the filesystem of HP Tru64. Oracle uses
the Direct I/O feature available in CFS. Direct I/O enables Oracle to bypass
the buffer cache (no caching at filesystem level). Oracle manages the
concurrent access to the file itself; as it does on raw devices. On CFS,
without Direct I/O enabled on files – file access goes through a CFS server.
A CFS server runs on a cluster member and serves a file domain. A file
domain can be relocated from one cluster member to another cluster member
online. A file domain may contain one or more filesystems.
Direct I/O does not go through the CFS server, but file creation and resizing
is seen as metadata operation by advfs and this has to be done by the CFS
server. The consequence is to run file creations and resizing on the node
where the CFS server is located. File operations might take longer when the
CFS server is remote.
Oracle recommends not using the tempfile option, as tempfiles might not be
allocated until the tempfile blocks are accessed and so cause
‘remote metadata operations’ for advfs.
3 Veritas
———–
VERITAS Database EditionTM / Advanced Cluster for Oracle9i RAC enables Oracle
to use the CFS. The VERITAS Cluster File System is an extension of the VERITAS
File System (VxFS). Veritas CFS allows the same filesystem to be simultaneously
mounted on multiple nodes. Veritas CFS is designed with a master/slave
architecture. Any node can initiate a metadata operation (create, delete, or
resize data), the actual operation is carried out by the master node. All other
(non metadata) IO goes directly to the disk.
CFS is used in DBE/AC to manage a filesystem in a large database environment.
When used in DBE/AC for Oracle9i RAC, Oracle accesses data files stored on CFS
filesystems by bypassing the filesystem buffer and filesystem locking for data.
4 Oracle Cluster File System
——————————
Oracle Cluster File System (OCFS) is a shared filesystem designed specifically
for Oracle Real Application Clusters. OCFS eliminates the requirement for Oracle
database files to be linked to logical drives and enables all nodes to share a
single Oracle_Home (current capabilities are detailed in section 2.8) instead
of requiring each node to have its own local copy. OCFS volumes can span one
shared disk or multiple shared disks for redundancy and performance
enhancements.
5. Netapp(R) Filer
——————-
Netapp Filer offers CFS functionality via NFS to the server machines. These
filesystems are mounted using special mount options. For details please see
Netapp documentation.
Netapp certifications can be found at:
http://www.netapp.com/part…
To understand the architecture and Oracle installation please see these
documents:
Note 210889.1: RAC Installation with a NetApp Filer in Red Hat Linux Environment
and
Oracle9i RAC Installation with a NetApp Filer on Fujitsu-Siemens Primepower
(Solaris8 Operating System) at http://www.netapp.com/tech…
6 AIX
——-
IBM’s General Parallel File System (GPFS) allows users shared access to files
that may span multiple disk drives on multiple nodes. GPFS provides access to
all data from all nodes of the cluster. It can be configured with multiple
copies of metadata allowing continued operation should the paths to a disk or
the disk itself be broken. Metadata is the filesystem data that describes
the user data. GPFS allows the use of RAID or other hardware redundancy
capabilities to enhance reliability.
In Oracle9i GPFS is only supported with HACMP/ES in a RAC configuration.
When placing datafiles on GPFS no CRM (Concurrent Resource Manager) needs to be
installed. Starting with Oracle10g HACMP is no longer required to use GPFS.
Metalink contains certification information and information about required
patches for having a cluster database on a GPFS.
7 Sun GFS
———–
Global File Service (GFS or Cluster File System) is a filesystem that is
accessible from all nodes in the cluster. GFS is based on global devices and
has a client/server architecure. GFS provides transparent and concurrent file
access.
Note that Sun GFS is not supported for Oracle datafiles, see section 3.10.
8 Sun StorEdge QFS
——————–
QFS software is a file manager that provides a shared filesystem where mutiple
servers can read and write simultanuously to the same file in the same filesystem.
9 Other Linux Cluster Filesystems
———————————–
There are various third party cluster filesystems available on Linux.
Consult the Oracle Certify website for the policy regarding support for third party
cluster file systems on Linux. Also, consult the RAC Technology Compatibility Matrix (RTCM)
for Linux (http://www.oracle.com/tech… … generic_linux.html)
for the latest information on which third party cluster file systems are supported
by RAC release and platform.
10 Which Platforms support what?
———————————-
Platform and Storage for Storage for
[Cluster Software] Oracle installation datafiles
AIX [HACMP] LFS (1) or CFS (2) CFS and/or Raw devices
AIX [CRS] LFS or CFS CFS and/or Raw devices
HP/UX [MC/Service Guard] LFS or CFS (3) CFS (3) and/or Raw Devices
HP/UX PA-Risc [Veritas DBE/AC) LFS or CFS CFS and/or Raw Devices
Linux [oracm, CRS] LFS OCFS (4) and/or Raw
Devices, also NFS (5)
OpenVMS CFS CFS
Sun Solaris [Fujitsu Siemens LFS Raw Devices/NFS (5)
Primecluster]
Sun Solaris [Sun Cluster] LFS or CFS (6,7) CFS (7) Raw Devices/NFS (5)
Sun Solaris [Veritas DBE/AC] LFS or CFS CFS and/or Raw Devices
Tru64 Unix LFS or CFS CFS and/or Raw Devices
Windows NT/2000 [oracm, CRS] LFS or CFS OCFS and/or Raw Devices
Windows 2003 (32/64bit) [oracm, CRS] LFS or CFS OCFS and/or Raw Devices
(1) LFS is the abbreviation for local filesystem and is only accessible directly
by the node that mounted the disk
(2) CFS is the abbreviation for Cluster FileSystem. The implementation
depends on the operating software vendor or cluster software vendor.
(3) MC ServiceGuard 11.17 includes a CFS which is supported with Oracle 10gR2
(4) OCFS: Oracle Cluster FileSystem
(5) NFS is supported with Netapp(R) Filer, see Metalink certification
(6) Sun GFS can only be used for Oracle_Home and archivelogs.
(7) Sun StorEdge QFS
Local Filesystem means that the Oracle Universal Installer replicates the
RAC software installation automatically to every private filesystem of the
selected nodes in the cluster. The Oracle installation products
are cluster aware and will not install the Oracle software to over-write itself.
Oracm is the Oracle Cluster manager, which is available on Linux and Windows
NT/2000. No other cluster manager is needed to setup Real Application Cluster.
Cluster Ready Services (CRS) are new in Oracle10g and provide also clustermanager
functionality.
Oracle will validate cluster filesystems of other vendors when they become
available. Oracle will support the Oracle software when running on a validated
cluster filesystem.
11 Cluster File System names
——————————
PLatform or Cluster Vendor CFS name
AIX GPFS
HP/UX MC/ServiceGuard CFS
Linux [oracm, CRS] OCFS
OpenVMS RMS
Tru64 Unix CFS
SunCluster GFS, QFS
Veritas DBE/AC CFS
Windows NT/2000 OCFS
Windows 2003 (32/64bit) OCFS
For more information on certified configuration please see the certification
matrix available on Metalink. Instructions for accessing the certification
matrix can be found in the following note:
Note 184875.1
How To Check The Certification Matrix for Real Application Clusters
12 When to use CFS over raw?
——————————
This option is very dependent on the availability of a CFS on your platform.
A CFS offers:
- Simpler management
- Use of Oracle Managed Files with RAC
- Single Oracle Software installation
- Autoextend enabled on Oracle datafiles
- Uniform accessibility to archive logs in case of physical node failure
- With Oracle_Home on CFS, when you apply Oracle patches CFS guarantees that
the updated Oracle_Home is visible to all nodes in the cluster。
---------------------------------------------------------------------------------
Coda分布式文件系统
原著：Peter J. Braam
简介
coda分布式文件系统是由卡耐基·梅隆大学开发的一个实验中的分布式文件系统。Coda在移动计算处理上具有很多别的系统没有的先进的特性，很多的开发者为此做出了很大的贡献。他具有以下特性：- 离线状态下移动客户端仍可操作
- 保持离线状态客户端的数据一致性
- 带宽自适应
- 错误恢复
- 服务器之间的读写复制
- 解决服务器之间的冲突
- 处理服务器之间的网络故障
- 处理断开的客户端
- 性能和可靠性
- 客户端可高性能、持久的保存文件、目录以及属性。
- 回写式缓存
- 安全性
- Kerberos方式身份验证
- 访问控制列表
- 对共享的完美诠释
- 可以免费获取源代码
Fig 1: Coda 的标志 (原图例作者：Gaich Muramatsu)
你可能会对某些专业术语感到困惑，下面我们先把可能遇到的术语加以介绍。分布式文件系统
一 个分布的文件系统将文件存储在一个或更多的叫做服务器的计算机上,并且可以让客户机像访问普通文件一样访问。使用文件服务器有很多的好处。文件可以尽可能 广泛的被能访问服务器的计算机使用，在同一个地点存储并且共享某文件比把这个文件分散到许多客户机上单独存储要好。对于保证信息的安全而作的备份处理相对 更加容易，因为只有存储文件的服务器需要做备份。服务器可以提供很大的存储空间，如果每个客户端都单独准备一个这样大的空间的成本会很大，显然是不现实 的。当某一部分人需要共享文档的时候，分布式文件系统的有效性就体现出来了。更进一步的说，共享应用软件也是一个很好的选择。共享之后系统的管理将会变得 相对简单。设计一个好的分布式文件系统需要处理很多的问题。由于网络本身的瓶颈和服务器的超负荷工作，在网络中传送大量的文件通常是效率很 低并且有延迟。数据的安全性也是另外的一个需要特别注意的方面，我们必须确认访问数据的客户端确实是经过我们认证的，并且数据在传送过程中没有泄漏。另外 还有两个和故障处理有关的方面。通常情况下客户端相对网络连接来说出故障的可能性更小。网络的故障会造成客户端不再使用的假象。同样，服务器的故障会令人 更加不悦，因为它会造成所有的客户端无法访问急需的信息。Coda作为一个分布式文件系统的研究原型将会一一处理上面提到的问题。
Fig. 2 服务器的安全控制 (原图例作者： Gaich Muramatsu)
Coda
最初是在Mach 2.6上实现的，并且最近已经移植到了Linux、NetBSD、FreeBSD。 Michael Callahan
已经将coda的一部分移植到了Windows 95上，我们正在研究将Coda移植到Windows
NT上的可行性。现在我们主要在为coda向不同系统移植做努力。同时我们加入了一部分的新特性（例如：回写缓存、基本存储单元）并且重新编写了coda
代码的一部分。很多使用者通过互联网给我们发送了大量有用的回馈信息。在未来，coda很可能会成为一个受到大家欢迎的、广泛使用的、可免费获取的分布式
文件系统。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如何保持文件的一致性，但首先我们先来讲将如何支持离线操作。
通过缓存来处理离线操作
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 错误恢复的方法
卷，服务器，服务器间的复制
大 多数的网络文件系统是在服务器上的一个可以被远程调用的本地文件结构。这种可以被远程客户端挂载的文件系统，在windows上称作网络共享 (network share)，在unix上称作网络文件系统(network file system)。大多数这样的系统都是远程挂载一个已经在分布的服务器上的挂载好的卷。这样的系统关心的是服务器的分区、目录以及相应的共享。Coda和 AFS文件系统从本质上与这些是不一样的。Coda服务器上的文件并不是存放在通常的文件系统上的。对于这些文件的组织如下所示。Coda 服务器以及工作站的分区作为对文件服务器可用的部分。这些分区将存放按照卷的方式来管理的文件。每一个卷带有一个和文件系统一样的目录结构，也就是说一个 卷的根目录以及根目录下的目录树。相对于分区来说，卷要小，但是相对于单一个目录或者单一的文件的逻辑单位来说，卷要大。举例来说，某个用户的home目 录可能就是一个单独的coda卷，coda相关的资源就存放在这个卷里面。通常情况下一个单独的服务器可能包含数百个卷，每个卷的平均大小可能是10兆。 从系统管理员的角度来看，卷是一个易于管理的很灵活的普通的文件数据。
Coda将卷、目录、访问控制列表以及文件的属性保存在一个raw分 区中。通过一种基于日志的可恢复的虚拟内存系统 (log based recoverable virtual memory package, RVM)来实现快速并且确保一致性的访问。只有文件的数据保存在服务器的分区上。通过RVM可以实现对事务的支持，也就是说当服务器崩溃后，不用花费太多 的力气就可以恢复整个系统。
卷带有一个名称和他自己的编号，卷可以被挂载到/coda下的任何一个位置。比如要使一个叫做u.braam的 卷挂载到/coda/usr/braam，只需要执行"cfs makemount u.bramm /coda/usr/braam"。Coda不允许挂载点是一个已经存在的目录。他会把建立一个新的目录作为挂载的过程之一。这样做避免了将unix文件 系统挂载到已经存在的目录下。这个操作和Macintosh以及Windows的网络驱动器及共享很类似。但是最明显的区别是挂载点对于客户端是不可见 的。他看起来只是一个/coda下的很普通的目录。系统中有一个单独的卷具有作为根卷的权限，这个卷在启动的时候就被挂载。
Coda通过三 组32位的整数来标示一个文件。这组整数被称为Fid。Fid包含卷编号(VolumeID)、V结点编号(VnodeID)以及一个全局唯一标识符 (Uniquifier)。通过卷编号来确定文件存储的卷。V结点编号就是文件的i结点编号。全局唯一标识符来是为保持文件一致性处理准备的。Fid在 Coda服务器集群中是唯一的。
在coda服务器之间是有读写复制的。也就是说一组服务器向客户端发送文件数据，对文件的更新也会在这组服 务器中执行。这样做的好处是提高了数据的可用性，假如一个服务器出现了问题，其他的服务器会自动接替，客户端不会受到任何影响。卷可以存放在一组服务器 中，我们把这样的一组服务器叫做VSG(Volume Storage Group)。
这些复制的卷的卷编号也是被复制的。复制后的卷编号将本地的卷结合在一起成为VSG。
VSG是一个保存复制后卷的服务器列表。
每个服务器的本地卷定义了一个分区和本地的卷编号来保存文件和元数据。
当 Venus要访问服务器上的对象，他首先需要找到卷信息以便确定保存该文件的卷。这个卷信息包含服务器列表和存放该文件的服务器上的卷编号。在VSG中的 服务器之间关于文件的通信是读一次写多次的操作，即读取VSG中某一个服务器上的文件然后向所有的可用的VSG成员传播更新的消息。我们把可用的VSG成 员叫做AVSG(Available VSG members)。Coda可以使用多点传送RPC来向很多服务器提交更新操作，这样做不会对整体的性能有太大的影响。
前面讲到的必须首先 获得卷信息有时候会给人带来误解。一旦获取卷信息之后，接下来的文件访问因为路径遍历的减少而受益。这是因为卷的根相对通常的挂载了很大的目录来说要近很 多。（译者注：前文中提到每个卷都有自己根以及目录树，而卷可能会挂载在很深的目录中。直接从相应卷的根来找文件显然要比从/coda找文件要快。）
服 务器之间的复制就像是离线操作一样有两点需要介绍：决定是否复制以及如何修复错误。某些在VSG中的服务器可能因为服务器或者网络的故障和其他的服务器隔 离开了。在这样的情况下AVSG保存的对象一定会比VSG少。更新无法传递到所有的服务器上，只能传送到AVSG，从而会导致全局（服务器与服务器之间） 冲突。
Fig 6: AVSG vs. VSG (原图例作者： Gaich Muramatsu)
在
获取某个对象或者某个对象的属性之前，Venus首先从所有可用的服务器上获取该对象的版本戳。如果她发现某些服务器没有这个文件的最新版，她就会启动一
个处理进程来自动解决不一致的情况。如果无法解决，就需要用户手动来进行修复。这个进程由客户端发起，然后完全由服务器来执行。服务期间的复制和解决不一致的情况看起来是不可思议的操作。我们的服务器经常出现磁盘故障。为了修复服务器所需做的工作只是替换新的磁盘然后告诉coda:去解决他吧。系统会自动向磁盘写入从别的服务器上获取的最新的数据。
Coda的应用
Coda 一直在卡耐基·梅隆大学使用。约有数十个客户端使用它来做coda的开发工作，并且它作为一个完全的可以离线使用文件系统来运行特定的应用程序。下面的两 点可以说明coda的特性非常的成功。我们购买了一些Wabi以及相关的一些Windows软件的授权。Wabi可以让用户执行微软的 Powerpoint。我们把Wabi、Windows 3.1还有微软的Office程序存放在Coda上，并且与客户端进行共享。当然客户端的存放自己参数的.ini文件是每个用户单独使用的，大多数的库和 应用程序是共享的。通过临时暂存的文件我们仍然可以在离线的笔记本上进行展示。这种操作在会议上是经常遇到的。我们已经使用这个系统很多年 了，从来没有发生过丢失用户数据的现象。有些时候服务器上的磁盘报废了，但当所有的卷都被复制后，我们将一个空的磁盘放入到服务器中并且让保持一致性的系 统来自动更新数据。所需要做的工作实际上只是在放入新磁盘后在受到影响的目录树下运行"ls -lR"。服务器会发现缺少的文件，负责保持一致性的进程会将文件从正常的服务器上传送到新修复好的服务器。
有很多的应用程序都会因为Coda而受益。
FTP 的镜像站点可以是一个Coda客户端。我们用拥有众多镜像站点的ftp.redhat.com来做一个例子。每个镜像站点都是使用一个Perl脚本来遍历 Redhat的目录树以便知道是否有任何更新并且获取更新的文件，不论在镜像上是否需要这样。假如Redhat使用coda来作为他们的ftp空间，镜像 站点相当于coda客户端，只是Redhat自己有写入的权限。当Redhat更新文件的时候，Coda服务器会自动告知镜像站点有文件改变了。当某人试 图从镜像站点下载更新过的文件的时候，镜像站点才会从服务器上下载最新的文件。WWW服务器也可以作为coda客户端。很多ISP因为 WWW服务器短缺而很头痛。对于单一的http服务器来说，访问量实在是太大了。已经证明使用NFS来共享文件会造成效率上面的问题，手动的在某几个特定 的服务器之间复制文件是经常需要做的操作。Coda可以解决这样的问题。每个服务器作为一个coda客户端，将数据保存在自己的缓存中。访问的速度是由本 地磁盘的速度来决定的。ISP可以离线来更改他们网页的信息，我们也为移动客户端做了一个很好用的应用程序。
网络计算机可以通过使用coda作为缓存来大大的提高性能。当服务器可用的时候，网络计算机会自动去更新。大多数的操作是没有网络流量的，即使重新启动。
我 们现在要做的工作主要是提高Coda的质量。Coda的轮廓已经通过研究大体勾划出来了。回写式缓存将加入到Coda中以便能更高速的运转。离线操作是一 种很特殊的回写缓存操作。我们正在利用离线操作的代码来实现在线时的回写缓存。Kerberos的支持已经加入。网络协议对Coda的支持使这个很容易做 到。我们希望在未来能做到让Coda客户端同时连接多个Coda服务器集群，并且把Coda移植到尽可能多的操作系统上。
获取Coda
Coda可以通过 ftp.coda.cs.cmu.edu 来下载。 在这个服务器上你可以找到为 Linux 准备的 RPM 包以及 tar 打包的源代码。 Linux 2.2及以后的内核可以支持 Coda。 在我们的 www 站点
www.coda.cs.cmu.edu 上你可以找到更多的资源，比如邮件列表、手册以及研究论文等等。
-----------------------------------------------------------------------------------------
coda分布式文件系统的安装和配置
coda分布式文件系统分为服务器和客户端，服务器又分为SCM(System Control Machine) server和non-SCM server,SCM服务器负责与其它服务器同步，SCM服务器只有一个，而non-SCM服务器可以有多个。客户端在与服务器建立连接之后会在本地生成一个新的文件系统/coda，这个文件系统下的所有文件是与服务器上的一个用户数据目录保持 同步的，服务器上的用户数据目录是在安装服务器软件时指定专门用来存放用户数据的，即在客户端的/coda目录下保存的所有文件，实际上都是服务器上的一 个备份，只要服务器上的文件发生了变化，则/coda目录下的文件也会发生相应的变化，这就是说，只要有一个客户端操作了/coda下的某个文件，则所有 客户端/coda下的对应文件就都要发生变化，同时服务器之间也要保持同步。
安装实例：
一、SCM服务器安装
1.需要的分区/目录
/vice 存放配置文件
/vicepa 存放用户数据文件
/LOG RVM处理日志用，最大为50M，如果为分区，不要自动mount
/DATA RVM数据存储区，大小为/vicepa大小的4%左右，如果为分区，不要自动mount
以上都可以为分区或者是目录。
2.安装软件
lwp-release.i386.rpm
rvm-release.i386.rpm
rpc2-release.i386.rpm
coda-debug-server-release.i386.rpm
3.配置coda服务器
运行vice-setup
按照配置向导一步一步配置，需要注意的有：
作为SCM服务器安装；
设置用户；uid和用户名，在客户端登录服务器时要用到
设置root volume:后面创建root volume时用到
4.运行coda服务器
(1)在运行前需要修改一个配置文件，/etc/coda/server.conf，把文件中的ip地址和主机名参数设置好
(2)运行相关程序
auth2
rpc2portmap
updatesrv
updateclnt -h SCM_SERVER_NAME
startserver &
(3)检查服务运行是否正常
tail -f /vice/srv/SrvLog
5.关闭命令
volutil shutdown
然后查看日志(/vice/srv/SrvLog)检查是否完全关闭
6.创建root volume
createvol_rep codaroot E0000100 /vicepa
其中codaroot为配置SCM的时候(vice-setup)指定的，/vicepa为用户数据目录，也是配置的时候指定的。
二、non-SCM服务器安装
安装过程基本上都是一样，只是在配置时，需要指定服务器为non-SCM服务器，同时指定SCM服务器的主机名(需要在hosts文件中指定域名解析)。
在运行non-SCM服务器时有一点不一样：
auth2 -chk
rpc2portmap
updatesrv
updateclnt -h SCM_SERVER_NAME
startserver &
然后检查目录/vice/db，看是否从SCM服务器上把相关的配置文件拷贝了过来。
三、客户端的安装
1.安装软件包
lwp-release.i386.rpm
rvm-release.i386.rpm
rvm-tools-release.i386.rpm
rpc2-release.i386.rpm
coda-debug-client-release.i386.rpm
2.配置
运行 venus-setup coda-servers cach-size
例如：venus-setup sproxy,SWWW 4000(40M)
coda-servers表示该客户端可以与哪些coda服务器连接，cach-size表示/coda文件系统的大小，即用来保存所有需要保持同步的文件的容量。
3.运行
venus &
4.检查日志
tail -f /usr/coda/etc/console
5.停止
vutile shutdown
四、coda的使用
在服务器和客户端都安装好了之后，就可以开始使用coda文件系统了，coda文件系统的使用可以分为3个步骤：
1.在SCM上创建volume
volume实际上是这样一个概念，它是一个比文件分区小，比文件目录大的一种文件组织方式，即在一个volume中可以包含很多个文件目录或者文件。
2.在客户端（coda-client）上mount创建的volume
3.在客户端上使用coda文件系统，如，文件的创建、删除等
下面举例说明以上3个步骤：
1.在SCM上创建root volume
createvol_rep codaroot E0000100 /vicepa
其中codaroot是在配置SCM的时候指定的root volmue的名字，/vicepa为用户数据目录，也是在配置的时候指定的。
2.如果存在多个coda server，即存在non-SCM，则还可以修改两个文件，/vice/db/VSGDB和/vice/db/servers,
/vice/db/VSGDB:
E0000100 sproxy swww sproxy2
其中：sproxy为SCM,swww,sproxy2为non-SCM
/vice/db/servers:
sproxy 1
swww 2
sproxy2 3
sproxy，swww，sproxy2为各个主机的主机名，1,2,3为配置过程中指定的serverid。
3.创建其他的volume，如，创建一个名为apache的volume
首先在SCM的/vice/db/VSGDB文件中增加一行：
E0000100 sproxy swww sproxy2 (已有的root volume)
E0000101 sproxy swww sproxy2 (增加的)
然后在SCM上运行(sproxy为SCM)：
bldvldb.sh swww
bldvldb.sh sproxy2
最后创建volume:
createvol_rep apache E0000101 /vicepa
在服务器上创建了volume后，就可以在client上使用volume了。
4.用clog命令登录coda服务器
clog coda
password:changme
或者是：clog coda
首先要保证venus已经运行起来，coda用户是在配置服务器的时候指定的，也可以使用在服务器上用程序添加的用户，changme为默认口令，即没有修改过的口令。
5.mount服务器上存在的volume
cfs mkmount /coda/apache apache
把apache volume mount在/coda/apache目录
6.操作/coda/apache目录
------------------------------------------------------------
2005 年 6 月 01 日
分布式文件系统近来没有什么新闻，因为使用它们的主要是公司和教育网络，总共只有几千个用户。从概念上来说，对于这样的系统如何适合开放源码文件系统这个 领域，还并非总是很清楚。Open Andrew File System (OpenAFS) 是对 Network File System (NFS) 的成熟的替代方案，它能适应大量的用户，并能减轻管理的痛苦。
关于作者
Frank Pohlmann 以前研究的是中东宗教历史，后来各基金会认为研究宗教辩证历史与当今世界相去甚远，从此他便专攻自己热爱的领域 —— 免费软件。他获准成为英国的LinuxUser and Developer 的技术编辑。您可通过 frank@linuxuser.co.uk 与他联系.
OpenAFS 帮助聚集分布式数据
下一代类 NFS 文件系统可能解决令人头疼的数据问题
原文链接：http://www-128.ibm.com/developerworks/cn/opensource/os-openafs/2005 年 6 月 01 日
分布式文件系统近来没有什么新闻，因为使用它们的主要是公司和教育网络，总共只有几千个用户。从概念上来说，对于这样的系统如何适合开放源码文件系统这个 领域，还并非总是很清楚。Open Andrew File System (OpenAFS) 是对 Network File System (NFS) 的成熟的替代方案，它能适应大量的用户，并能减轻管理的痛苦。
用户对文件系统的概念有两种理解。第一种是组织文件的方式、包含文件的目录，以及保存目录结构的分区。第二种认为文件系统是文件组织和映射到原始材料的方
式。当然，在这两者之间还存在很多层，如虚拟文件系统 (VFS)
层和实际存储管理例程，但是就管理用户可用的结构化信息而言，超级用户看一下系统内部，并对内核的最深处有一些了解是很有意义的。
原始材料可能由 RAM
或硬盘组成，但是不管是哪种情况，文件系统数据结构都是组织由硬件制造商格式化了的扇区和字节。尽管这种划分相当粗糙，用户在他们的工作生活中还是能够十
分愉快地接受这种划分。提高 —— 比如说，用户访问比特定容量大的文件的速度 ——
的工具是可用的。帮助重新组织目录和文件的工具也是可用的，但是这些工具使我们远离比特、字节和扇区。
文件系统元概念
这种总体区分的一个经典例子就是 FreeBSD —— 回溯到 BSD UNIX时代 —— 用 UNIX File System V2
(UFS2) 来组织磁盘上的数据而用 Flash File System (FFS)
来把文件组织成目录并最优化目录访问的方式。Linux系统有些不同，因为 Linux 本来就容许有不限于一个或两个的文件系统。因此，VFS 层使
Linux 用户可以添加新的文件系统支持而不必过于担心 Linux 管理存储器的方式。
当我谈到进一步的区分，如静态和日志文件系统时，我要强调一致性以及某种程度上的文件系统内容的安全性。同样，用 BSD UNIX
时代用来看问题的术语来说, 静态和日志文件系统与 UNIX File System (UFS) 组织文件并确保其安全的方式有关。虽然 Linux
文件系统从 Journal File System (JFS) 开始就包含了日志文件系统，但是下一代文件系统 (XFS) 和早期的
ReiserFS 也被改造成对其可用，还有一个不管是技术媒体还是公司宣传都没有过多提及的领域就是分布式文件系统。
从 NFS 所学到的
这种情况与这样的现实有关：如今，使网络范围内的文件系统层变成对相当多的用户来说通过 TCP 或 User Datagram Protocol (UDP) 就可用，这种做法是非常轻率的。围绕 NFS V3 之前版本的恐怖场景使许多管理人员不愿管理哪怕只有几十个用户的网络。此外，由极快的主板架构支持的多处理器架构的出现，似乎使得分布式文件系统问题变得 不太重要。速度似乎是由硬件保证的，而不是由智能实现的分布式系统保证的。由于分布式文件系统往往要依赖于底层的文件系统实现——例如，已有的 ext2、ext3 和 ReiserFS 文件系统驱动程序 —— 分布式文件系统好像仅限于大的大学网络和临时的科研和公司网络这些领域。
这种情况与这样的现实有关：如今，使网络范围内的文件系统层变成对相当多的用户来说通过 TCP 或 User Datagram Protocol (UDP) 就可用，这种做法是非常轻率的。围绕 NFS V3 之前版本的恐怖场景使许多管理人员不愿管理哪怕只有几十个用户的网络。此外，由极快的主板架构支持的多处理器架构的出现，似乎使得分布式文件系统问题变得 不太重要。速度似乎是由硬件保证的，而不是由智能实现的分布式系统保证的。由于分布式文件系统往往要依赖于底层的文件系统实现——例如，已有的 ext2、ext3 和 ReiserFS 文件系统驱动程序 —— 分布式文件系统好像仅限于大的大学网络和临时的科研和公司网络这些领域。
那么，分布式文件系统是否是我们所提及的两层之上的第三层呢？如今联网过程中的一个重要问题就是使异构的网络合作（Samba
是一个很好的例子）。但是您要明白，今天在文件系统领域有三家主要制造商：Microsoft Windows文件系统系列（FAT16、FAT32 和
NTFS 文件系统）；Apple Mac OS X (HFS+)；以及本机 Linux 日志文件系统（主要是 ReiserFS 和
ext3）。Samba 帮助使 Windows 和 Linux
文件系统合作，但是它并没有使管理人员对所有主要文件系统上的访问都同样地快速和容易。
有人可能会引用 NFS V4 作为解决该问题的一次尝试，但是由于处理 NFS V4 的 Request for Comments (RFC)
3530 才发布两年，而且针对内核 V2.6 的 NFS4 还相当新，我暂不推荐使用它做生产服务器。Fedora 核心 2 和 3 提供了
NFS4 补丁和 NFS4 实用程序，这些实用程序演示了开发人员完成的一些印象非常深刻的过程，因为 NFS
强制可怜的网络管理人员，打开更多的端口并为导出到用户的每个名称空间配置各自的客户机。RFC 3530 解决了大部分的安全问题。还有，NFS
目录必须单独安装。您可以用统一的 sign-on 和 Kerbero 来保证安全，但是那也需要做很多工作。
OpenAFS 基本原理
OpenAFS 试图免除安装和管理用于使不同文件系统合作的软件时的痛苦。OpenAFS 也能使不同文件系统更有效地合作。尽管 UNIX 及其引人注目的后继者 Plan 9 的最初目标是文件，但是商业现实指出，与其彻底重构现代的网络文件系统，不如添加另一个分布式文件系统层。
OpenAFS 试图免除安装和管理用于使不同文件系统合作的软件时的痛苦。OpenAFS 也能使不同文件系统更有效地合作。尽管 UNIX 及其引人注目的后继者 Plan 9 的最初目标是文件，但是商业现实指出，与其彻底重构现代的网络文件系统，不如添加另一个分布式文件系统层。
1983 年 Carnegie Mellon University 的编程人员开发了 AFS。此后不久，该大学成立了一家叫做 Transarc
的公司来出售基于 AFS 的服务。1998 年 IBM 收购了 Transarc，并使 AFS 成为一个开放源码产品，叫做
OpenAFS。但是，故事并未就此结束，因为 OpenAFS 衍生了其他的分布式文件系统，如 Coda 和
Arla，这些我将在后面谈到。存在针对所有主要操作系统的各种客户机，及大量的过时文档资料。Gentoo.org 为使 OpenAFS 对
Linux 用户可用做出了特别贡献，即使其他机构在需要分布式文件系统时似乎仍然是指 NFS。
OpenAFS 架构
OpenAFS 是围绕一组叫做 cell 的文件服务器组织的。每个服务器的标识通常是隐藏在文件系统中的。从 AFS 客户机登录的用户将分辨不出他们在哪个服务器上运行，因为从用户的观点来看，他们想在有可识别的 UNIX 文件系统语义的单个系统上运行。文件系统内容通常都是跨 cell 复制，以便一个硬盘的失效不会损害 OpenAFS 客户机上的运行。OpenAFS 需要高达 1 GB 的大容量客户机缓存，以允许访问经常使用的文件。它还是一个十分安全的基于 Kerbero 的系统，它使用访问控制列表 (ACL) 以便可以进行细粒度的访问，这不是基于通常的 Linux 和 UNIX 安全模型。
OpenAFS 是围绕一组叫做 cell 的文件服务器组织的。每个服务器的标识通常是隐藏在文件系统中的。从 AFS 客户机登录的用户将分辨不出他们在哪个服务器上运行，因为从用户的观点来看，他们想在有可识别的 UNIX 文件系统语义的单个系统上运行。文件系统内容通常都是跨 cell 复制，以便一个硬盘的失效不会损害 OpenAFS 客户机上的运行。OpenAFS 需要高达 1 GB 的大容量客户机缓存，以允许访问经常使用的文件。它还是一个十分安全的基于 Kerbero 的系统，它使用访问控制列表 (ACL) 以便可以进行细粒度的访问，这不是基于通常的 Linux 和 UNIX 安全模型。
缓存管理器碰巧是 OpenAFS 的一部分，很奇怪，它只作为底层文件系统与 ext2 一起运行。除缓存管理器之外，OpenAFS
表层的基本结构很像现代的 NFS 实现。但是，基本架构却一点都不像，而且必须慎重看待它的任何并行。对那些仍喜欢使用 NFS，但是又想利用
OpenAFS 程序的人来说，可以使用所谓的 NFS/AFS 翻译器。只要 OpenAFS 客户机被配置为 NFS
服务器机器，您就应该能够享受这两种文件系统的优点。
OpenAFS 如何进行管理
NFS 是位置无关的，它把本地目录映射到远程文件系统位置。OpenAFS 对用户隐藏了文件位置。因为可能所有的源文件都以读写副本的形式保存在复制到的不同文件服务器位置上，必须保持复制的副本同步。为此要使用一项称作 Ubik 的技术，它源于单词“ubiquitous（无所不在）”，是东欧拼写法。Ubik 过程使 AFS 文件系统上的文件、目录和卷 (volume) 保持同步，但是通常运行三个以上文件服务器进程的系统获益最多。系统管理人员可以将一个 AFS 站点的几个 AFS cell 分组 —— 这个以前的缩写词 AFS 已经被保留在 OpenAFS 文件系统的语义中了。管理人员将决定 AFS cell 的数目，以及 cell 使存储器和文件对站点内的其他 AFS cell 可用的程度。
NFS 是位置无关的，它把本地目录映射到远程文件系统位置。OpenAFS 对用户隐藏了文件位置。因为可能所有的源文件都以读写副本的形式保存在复制到的不同文件服务器位置上，必须保持复制的副本同步。为此要使用一项称作 Ubik 的技术，它源于单词“ubiquitous（无所不在）”，是东欧拼写法。Ubik 过程使 AFS 文件系统上的文件、目录和卷 (volume) 保持同步，但是通常运行三个以上文件服务器进程的系统获益最多。系统管理人员可以将一个 AFS 站点的几个 AFS cell 分组 —— 这个以前的缩写词 AFS 已经被保留在 OpenAFS 文件系统的语义中了。管理人员将决定 AFS cell 的数目，以及 cell 使存储器和文件对站点内的其他 AFS cell 可用的程度。
分区、卷和目录
AFS 管理人员把 cell 划分为所谓的卷。虽然卷可以随硬盘分区协同扩展 (co-extensive)，但大多数管理人员都不会将整个分区只分为一个卷。AFS 卷实际上是由一个单独的、称作 Volume Manager 的 UNIX 类型的进程管理的。您可以以一种常见的方式从 UNIX 文件系统目录安装卷。但是，您可以将 AFS 卷从一个文件服务器移动到另一个文件服务器 —— 同样是由一个 UNIX 类型的进程来管理的 —— 但是 UNIX 目录不能从一个分区实际地移动到另一个分区上。AFS 通过 Volume Location Manager 自动跟踪卷和目录的位置，并留意复制的卷和目录。因此，每当文件服务器非预期地停止操作，用户根本无需担心，因为 AFS 会把用户切换到另一个文件服务器机器上的复制卷，而用户可能都不会注意到。
AFS 管理人员把 cell 划分为所谓的卷。虽然卷可以随硬盘分区协同扩展 (co-extensive)，但大多数管理人员都不会将整个分区只分为一个卷。AFS 卷实际上是由一个单独的、称作 Volume Manager 的 UNIX 类型的进程管理的。您可以以一种常见的方式从 UNIX 文件系统目录安装卷。但是，您可以将 AFS 卷从一个文件服务器移动到另一个文件服务器 —— 同样是由一个 UNIX 类型的进程来管理的 —— 但是 UNIX 目录不能从一个分区实际地移动到另一个分区上。AFS 通过 Volume Location Manager 自动跟踪卷和目录的位置，并留意复制的卷和目录。因此，每当文件服务器非预期地停止操作，用户根本无需担心，因为 AFS 会把用户切换到另一个文件服务器机器上的复制卷，而用户可能都不会注意到。
用户从来不对 AFS 服务器上的文件进行操作。他们操作已经由客户端缓存管理器从文件服务器中取出的文件。Cache Manager 是居留在客户机操作系统内核中的一只非常有趣的猛兽。（您可以在 2.4 版本以上的任何内核中运行 Cache Manager）。
Cache Manager
Cache Manager 可以响应本地应用程序的请求，来跨 AFS 文件系统取出文件。当然，如果该文件是经常更改的源文件，那么文件存在于几个复制版本中可能不太好。因为用户很可能要频繁地更改经常被请求的源文件，所以 您会遇到两个问题：首先，文件很可能被保存在客户机缓存内，而同时还保存在几个文件服务器机器上的几个复制卷内；然后，Cache Manager 不得不更新所有的卷。文件服务器进程把文件发送到客户机缓存内并随其附带一个回调，以便系统可以处理发生在其他地方的任何更改。如果用户更改了缓存在其他 地方的复制文件，原始文件服务器将会激活回调，并提醒原始缓存版本它需要更新。
Cache Manager 可以响应本地应用程序的请求，来跨 AFS 文件系统取出文件。当然，如果该文件是经常更改的源文件，那么文件存在于几个复制版本中可能不太好。因为用户很可能要频繁地更改经常被请求的源文件，所以 您会遇到两个问题：首先，文件很可能被保存在客户机缓存内，而同时还保存在几个文件服务器机器上的几个复制卷内；然后，Cache Manager 不得不更新所有的卷。文件服务器进程把文件发送到客户机缓存内并随其附带一个回调，以便系统可以处理发生在其他地方的任何更改。如果用户更改了缓存在其他 地方的复制文件，原始文件服务器将会激活回调，并提醒原始缓存版本它需要更新。
分布式版本控制系统也面临这个经典问题，但是有一点重要的区别：分布式版本控制系统在断开时可以运行得很好，而 AFS
文件系统的任一部分都不能断开。断开的 AFS 部分无法再次与原来的文件系统连接。失效的文件服务器进程必须与仍在运行的 AFS
文件服务器重新同步，但是不能添加可能在它断开后保存在本地的新更改。
AFS 的后代
由于一些对新文件系统的尝试，AFS 已经明显要退出了。两个这样的结合了开发人员从原始分布式文件系统架构中学到的经验的系统就是：Coda 和瑞典开放源码志愿者的成果 Arla。
由于一些对新文件系统的尝试，AFS 已经明显要退出了。两个这样的结合了开发人员从原始分布式文件系统架构中学到的经验的系统就是：Coda 和瑞典开放源码志愿者的成果 Arla。
Coda 文件系统是改进原始的 AFS 系统的第一次尝试。1987 年在 Carnegie Mellon University，开发人员想要使
Coda 成为对 AFS 的一次自觉的改进，当时 AFS 达到了 V2.0 版本。在上个世纪 80 年代末 90 年代初，Coda
文件系统首次发布了一个不同的缓存管理器：Venus。虽然 Coda 的基本功能集与 AFS 的类似，但是 Venus 支持支持 Coda
的客户机的连续操作，即使客户机已经从分布式文件系统断开了。Venus 具有与 AFS Cache Manager
完全相同的功能，即把文件系统任务从内核内部的 VFS 层取出。
Coda 服务器和 Venus 缓存管理器之间的连接故障并不总损害网络功能：膝上型客户机必须能离开中央服务器工作。因此，Venus
把所有的更新存储在客户机修改日志内。当缓存管理器与中央服务器重新连接时，系统重建客户机修改日志，使所有的文件系统更新对客户机都可用。
断开操作可能引起其他问题，但是 Venus 缓存管理器说明了分布式文件系统可以被扩展，以包含比总是以连接方式运行的网络复杂得多的网络。
从 1993 年起，编程人员就开始开发 Arla，这是一个提供 OpenAFS 的 GPL 实现的瑞典项目，但是大部分的开发和端口都发生在
1997 年以后。Arla 模仿 OpenAFS 模仿得非常好，只是 XFS 文件系统必须运行在所有运行 Arla 的操作系统上。Arla
已经达到 V0.39 版本了，而且，就像 OpenAFS 一样，运行在所有的 BSD 流派、内核 V2.0x 版本以上的许多 Linux
内核以及 Sun Solaris 之上。Arla 确实为 AFS 实现了一个原本不在 AFS
代码中的功能：断开操作。但是具体情况可能会不同，开发人员也还没有完成测试。
还有其他的 AFS 类型的文件系统，如 GPLed InterMezzo，但是它们没有照搬 AFS 的命令行语义或它的架构。开放源码分布式文件系统领域是非常活跃的，其他分布式文件系统在移动计算领域得到了应用。
参考资料
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- 查看 OpenAFS，找到源代码、二进制代码和文档。
- NFS 已经改进了，您可以在 NFS Version 4 Web 站点 找到 RFC 和其他文档。
- 寻找关于早期的 Andrew File System 的信息，虽然它的很多命令与 OpenAFS 版本是一样的。
- Carnegie Mellon University 仍然维护着 Coda 文件系统。
- 寻找 Coda 文件系统文档，虽然该版本有些过时了。
- Arla 提供了一个入口点。那里的文档要么非常简短，要么就不存在。
- InterMezzo 分布式文件系统 是一个相当流行的新的分布式文件系统。
- Gentoo 提供了这个从零开始编译的 Linux 版本的相关下载、文档和新闻。
- 访问 developerWorks 开放源码专区，获得广泛的 how-to 信息、工具和项目更新，以帮助您利用开放源码技术进行开发，并将它们与 IBM 产品一起使用。
- 利用 IBM 试用版软件 革新您的下一个开放源码开发项目，可以下载或从 DVD 上得到试用版软件。
- 在 Developer Bookstore 的开放源码专区中找到数百本 开放源码主题的打折书籍，包括许多 Linux 书籍。
- 通过参与 developerWorks blogs 加入 developerWorks 社区。
关于作者
Frank Pohlmann 以前研究的是中东宗教历史，后来各基金会认为研究宗教辩证历史与当今世界相去甚远，从此他便专攻自己热爱的领域 —— 免费软件。他获准成为英国的LinuxUser and Developer 的技术编辑。您可通过 frank@linuxuser.co.uk 与他联系.