GPFS：面向大规模计算集群的共享磁盘文件系统（中文翻译）
GPFS：面向大规模计算集群的共享磁盘文件系统
Frank Schmuck 与 Roger Haskin
IBM Almaden 研究中心，加利福尼亚州圣何塞
摘要
GPFS（General Parallel File System，通用并行文件系统）是 IBM 面向集群计算机推出的并行共享磁盘文件系统，支持 RS/6000 SP 并行超级计算机和 Linux 集群平台。GPFS 已应用于世界上众多最强大的超级计算机。GPFS 的构建吸收了学术界近年来发展出的诸多思想，尤其是分布式锁（distributed locking）与恢复技术（recovery technology）。迄今为止，这些思想的扩展性如何，仍是业界猜测的问题。我们有幸在现存最大规模系统的产品环境中，对这些技术的极限进行了检验。尽管在许多情况下已有方案具备良好的扩展性，但在若干关键领域仍需探索新的方法。本文描述了 GPFS 的整体架构，并讨论了分布式锁与恢复技术如何被扩展以适应大规模集群。
1 引言
自计算机诞生以来，始终存在规模超出当时最强机器处理能力的问题。即便是当今强大的 CPU 和共享内存多处理器，这一现象依然存在。通信技术的进步使大量机器能够被组织成计算集群，从而在处理能力和存储容量上实现事实上的无上限扩展，能够求解单台机器无法胜任的更大规模问题。由于集群由相互独立且具有冗余特性的计算机组成，其潜在的容错能力使其适用于可靠性至关重要的另一类问题。因此，近年来集群技术受到了极大的关注。
集群的一个根本缺陷在于：程序必须被分割到多台机器上运行，而这些分布式程序之间的协作与资源共享较为困难。其中最重要的共享资源当属文件系统。若没有集群文件系统，分布式程序的各个组成部分就必须以临时、特设的方式共享集群存储，这通常会使编程复杂化、限制性能并降低可靠性。
GPFS 是面向集群计算机的并行文件系统，它尽可能地提供与单机通用 POSIX 文件系统相同的行为语义。GPFS 由 Tiger Shark 多媒体文件系统演化而来 [1]。GPFS 能够扩展至目前已建成的最大规模集群，已应用于全球前十大超级计算机中的六台，包括规模最大的 Lawrence Livermore 国家实验室的 ASCI White。GPFS 成功满足了最大规模、最苛刻计算任务对吞吐量、存储容量和可靠性的需求。
传统的超级计算应用在集群上运行时，需要多个节点对集群中共享文件内的数据进行并行访问（文件内并行访问，intrafile parallel access）。另一类应用——包括可扩展文件/Web 服务器和大型数字图书馆——其特征是文件间并行访问（interfile parallel access）：单个文件内的数据不一定被并行访问，但由于文件存于公共目录且共享磁盘空间，文件系统的数据结构（元数据，metadata）仍会被并行访问。GPFS 完全支持对文件数据和元数据的并行访问。在真正大规模的系统中，即便是管理性操作——如向文件系统中添加或移除磁盘、在磁盘间重新平衡文件——也涉及大量工作，GPFS 的管理功能同样以并行方式执行。
GPFS 通过其共享磁盘架构（shared-disk architecture）[2] 实现了极致的可扩展性。
GPFS 系统由集群节点组成，运行 GPFS 文件系统及使用它的应用程序，通过交换结构（switching fabric）连接到磁盘或磁盘子系统。集群中所有节点对所有磁盘享有同等访问权。文件跨文件系统中所有磁盘进行条带化（striping）——在最大规模的 GPFS 安装中可达数千块磁盘。条带化不仅实现了磁盘间的负载均衡，还能充分发挥磁盘子系统的全部带宽。
连接文件系统节点与磁盘的交换结构可以是存储区域网络（SAN，Storage Area Network），例如光纤通道（Fibre Channel）或 iSCSI；也可以通过某些 I/O 服务器节点，经由运行在通用通信网络之上的软件层（如 IBM 的虚拟共享磁盘 VSD，运行于 SP 交换机之上）访问磁盘。无论共享磁盘以何种方式实现，GPFS 仅假设一个标准块 I/O 接口，不要求磁盘端具备特定智能。
多节点并行读写共享磁盘必须进行适当同步，否则用户数据和文件系统元数据均会损坏。GPFS 使用分布式锁来同步对共享磁盘的访问。GPFS 的分布式锁协议确保无论多少节点同时读写文件系统，文件系统一致性始终得以维护，同时允许实现最大吞吐量所必需的并行性。
本文描述了 GPFS 的整体架构，详细介绍了若干有助于提升性能和可扩展性的特性，阐述了其在集群环境中实现并行性和数据一致性的方法，描述了其容错设计，并给出了性能数据。
2 大文件系统的通用问题
GPFS 的磁盘数据结构支持最多 4096 块磁盘、每块最大 1TB 的文件系统，单个文件系统最大容量达 4 拍字节（petabytes）。迄今为止投入生产使用的最大单个 GPFS 文件系统为 75TB（ASCI White [3,4,5]）。GPFS 支持 64 位文件大小接口，允许最大文件大小为 2⁶³-1 字节。尽管对大文件系统的支持并非集群独有的需求，但使 GPFS 实现这一目标的数据结构和算法仍值得专门介绍。
2.1 数据条带化与分配、预取和后台写回
要实现对单个大文件的高吞吐量访问，需要将数据跨多块磁盘和多个磁盘控制器进行条带化。GPFS 没有依赖独立的逻辑卷管理器（LVM，Logical Volume Manager）层，而是在文件系统内部实现条带化。自主管理条带化赋予了 GPFS 实现容错和跨适配器、存储控制器及磁盘进行负载均衡所需的控制能力。尽管部分 LVM 能提供类似功能，但它们可能不具备足够的拓扑知识来实现合理的负载均衡。此外，许多 LVM 将逻辑卷以逻辑单元号（LUN，Logical Unit Number）的形式暴露，由于寻址限制（如 32 位逻辑块地址）而存在容量上限。
GPFS 中的大文件被划分为等大小的块（block），相邻块以轮询（round-robin）方式存放在不同磁盘上。为将寻道开销降至最低，块大小较大（通常为 256KB，可配置范围为 16KB 至 1MB）。大块与 Veritas [15] 等文件系统中的盘区（extent）具有相同的优势：每次磁盘 I/O 可检索大量数据。GPFS 将小文件（以及大文件的末尾部分）以更小的单元——子块（subblock）——存储，子块大小最小可为整块的 1/32。
为在单线程应用读取大文件时利用磁盘并行性，GPFS 会将数据预取（prefetch）至缓冲池，向尽可能多的磁盘并行发送 I/O 请求，以充分利用交换结构所能提供的带宽。类似地，不再被访问的脏数据缓冲区会被并行地后台写回（write-behind）磁盘。这一方式使得读写单个文件的速率可达底层磁盘子系统和互连结构所支持的聚合数据速率。GPFS 能识别顺序、逆序以及各种步进（strided）访问模式。对于不符合上述模式的应用，GPFS 提供了可向文件系统传递预取提示的接口 [13]。
非均匀磁盘配置下，条带化需要在吞吐量与空间利用率之间进行权衡：最大化空间利用率意味着在更大的磁盘上存放更多数据，但这会降低总吞吐量，因为较大的磁盘将承担比例上更高的 I/O 请求，而较小的磁盘利用率不足。GPFS 允许管理员通过指定以吞吐量还是空间利用率为目标来进行此权衡。
2.2 大目录支持
为支持在超大目录（包含数百万个文件）中高效进行文件名查找，GPFS 使用可扩展哈希（extensible hashing）[6] 来组织目录中的目录项。对于占用超过一个磁盘块的目录，可通过对文件名进行哈希，并将哈希值的 n 个低位比特用作块号，快速定位包含该名称目录项的磁盘块，其中 n 由目录大小决定。
随着目录增长，可扩展哈希每次增加一个新的目录块。当一次创建操作发现哈希值对应的目录块没有剩余空间时，该块会被一分为二。新目录块的逻辑块号通过在旧块号的第 n+1 位加'1'得出，哈希值第 n+1 位为'1'的目录项被迁移至新块，其余目录块保持不变。因此，大目录通常以稀疏文件（sparse file）的形式表示，文件中的空洞对应尚未分裂的目录块。通过检查目录文件中的稀疏区域，GPFS 可以确定一个目录块被分裂的次数，进而确定定位给定名称所在目录块需要使用哈希值的多少个比特位。因此，无论目录文件的大小和结构如何，一次查找始终只需访问一个目录块 [7]。
2.3 日志与恢复
在大型文件系统中，每次挂载文件系统或集群中某节点宕机时都运行文件系统检查（fsck）来验证/恢复文件系统一致性是不可行的。为此，GPFS 将所有影响文件系统一致性的元数据更新记录到日志（journal）或写前日志（write-ahead log）[8] 中。用户数据不记录日志。
每个节点对其挂载的每个文件系统都维护一个独立的日志，该日志存储于对应文件系统中。由于所有其他节点均可读取此日志，任何节点均可代替故障节点执行恢复操作——无需等待故障节点重新上线。发生故障后，只需重新应用故障节点日志中记录的所有更新，即可迅速恢复文件系统一致性。
例如，创建新文件需要同时更新目录块和新文件的 inode。在获取目录块和 inode 的锁之后，两者均在缓冲缓存（buffer cache）中被更新，描述这两个更新的日志记录被写入日志队列。在被修改的 inode 或目录块被允许写回磁盘之前，对应的日志记录必须先强制刷入磁盘。这样，例如若节点在写完目录块但尚未将 inode 写入磁盘时发生故障，该节点的日志中必然包含重做（redo）缺失 inode 更新所需的日志记录。
一旦日志记录描述的更新已被写回磁盘，该日志记录便不再需要，可被丢弃。因此，日志可以是固定大小的，因为可通过在后台将脏元数据刷写到磁盘来随时释放日志空间。
3 在集群中管理并行性与一致性
3.1 分布式锁与集中式管理
集群文件系统允许将 I/O 吞吐量扩展至超过单节点所能达到的水平。要充分利用这一能力，需要集群中所有节点并行进行读写。另一方面，维护文件系统一致性和 POSIX 语义需要同步多节点对数据和元数据的访问，这可能限制并行性。GPFS 保证在整个集群范围内实现与单节点等效的 POSIX 文件系统语义。例如，若两个进程分别运行在不同节点上访问同一文件，一个节点上的读操作将看到另一节点并发写操作写入的全部或全无数据（读写原子性，read/write atomicity）。唯一的例外是访问时间（atime）更新——其不会立即在所有节点上可见。¹
实现上述同步有两种方案：
-
分布式锁（Distributed Locking）：每个文件系统操作在读取或更新任何文件系统数据或元数据之前，均需获取适当的读锁或写锁，以与其他节点上的冲突操作进行同步。
-
集中式管理（Centralized Management）：所有冲突操作被转发到一个指定节点，由该节点执行请求的读取或更新。
GPFS 架构从根本上基于分布式锁。在不同节点操作不同数据/元数据的情况下，分布式锁比集中式管理允许更大的并行性。另一方面，对于频繁从不同节点访问和更新的数据或元数据，更集中化的管理方式可能更合适：当锁冲突频繁时，分布式锁的开销可能超过将请求转发至中央节点的代价。锁粒度同样影响性能：粒度越小意味着更频繁的锁请求带来更大的开销，而粒度越大则可能导致更频繁的锁冲突。
为了高效支持各类应用，单一方案并不足够。访问特征随工作负载而变化，对不同类型的数据也不同——例如用户数据、文件元数据（如修改时间 mtime）与文件系统元数据（如分配图）。因此，GPFS 针对不同类型的数据采用多种技术：对用户数据更新使用字节范围锁（byte-range locking）；对文件元数据使用动态选举的"元数据节点（metanode）"进行集中管理；对磁盘空间分配使用带集中式提示的分布式锁；对配置变更使用中央协调器。
在以下各节中，我们首先介绍 GPFS 分布式锁管理器，然后讨论上述每种技术如何通过优化甚至在某些情况下避免使用分布式锁来提升可扩展性。
¹ 由于读-读共享极为常见，在多节点间同步 atime 代价过高。鉴于几乎没有应用对精确的 atime 有严格要求，我们选择仅周期性地传播 atime 更新。
3.2 GPFS 分布式锁管理器
GPFS 分布式锁管理器与许多其他系统 [2,9] 类似，采用运行在集群某节点上的集中式全局锁管理器，配合每个文件系统节点上的本地锁管理器。全局锁管理器通过分发锁令牌（lock token）[9] 在各本地锁管理器之间协调锁，锁令牌赋予节点无需每次加锁或释放锁时都进行独立消息交换即可自主授予分布式锁的权利。同一节点对同一磁盘对象的重复访问，只需发送一条消息来获取该对象的加锁权（即锁令牌）。一旦节点从全局锁管理器（也称为令牌管理器或令牌服务器，token manager/token server）获得令牌，该节点后续对同一对象发起的操作无需额外消息即可获取锁。只有当另一节点需要对同一对象申请冲突锁时，才需要额外的消息来撤销（revoke）第一个节点的令牌并将其授予另一节点。
锁令牌在维护节点间缓存一致性方面也发挥着作用。令牌允许节点缓存从磁盘读取的数据，因为在令牌被撤销之前，数据不能在其他地方被修改。
3.3 并行数据访问
某些类别的超级计算应用需要从多个节点向同一文件写入数据。GPFS 使用字节范围锁来同步对文件数据的读写。这种方式允许并行应用并发地向同一文件的不同部分写入，同时维护 POSIX 的读写原子性语义。然而，若字节范围锁以朴素方式实现——在 read/write 系统调用期间获取某字节范围的令牌并在调用结束后释放——锁开销将是不可接受的。因此，GPFS 使用了一种更为精妙的字节范围锁协议，能够从根本上减少众多常见访问模式下的锁流量。
字节范围令牌的协商机制如下：第一个向文件写入的节点将获取涵盖整个文件（从零到无穷）的字节范围令牌。只要没有其他节点访问同一文件，所有读写操作均可在本地完成，无需节点间的进一步交互。当第二个节点开始向同一文件写入时，需要撤销第一个节点持有的字节范围令牌的至少一部分。当第一个节点收到撤销请求时，会检查该文件是否仍在使用中。若文件此时已被关闭，第一个节点将放弃整个令牌，第二个节点即可获取涵盖整个文件的令牌。因此，在无并发写入共享的情况下，GPFS 的字节范围锁表现与全文件锁完全相同且效率相当，因为只需一次令牌交换即可访问整个文件。
反之，若第二个节点在第一个节点关闭文件之前开始写入，第一个节点将仅放弃其字节范围令牌的一部分。若第一个节点正在偏移量 o₁ 处顺序写入，第二个节点在偏移量 o₂ 处写入，则第一个节点将放弃从 o₂ 到无穷（若 o₂ > o₁）或从零到 o₁（若 o₂ < o₁）的令牌范围。这将允许两个节点继续从各自当前写入偏移量向前写入而不产生进一步的令牌冲突。一般而言，当多个节点向同一文件的非重叠区域顺序写入时，每个节点只需在其第一次写操作时进行一次令牌交换即可获得所需令牌。
令牌协商期间，写入偏移量信息通过指定必需范围（required range，对应当前正在处理的 write() 系统调用的偏移量和长度）和期望范围（desired range，对应可能的未来访问）来传递。对于顺序访问，期望范围将从当前写入偏移量延伸至无穷。令牌协议将仅撤销与必需范围冲突的节点的令牌；令牌服务器随后将授予在不与其他节点仍持有范围冲突的前提下尽可能大的期望范围子范围。
图 2 的测量结果展示了随着文件系统节点和磁盘数量的增加，GPFS I/O 吞吐量如何扩展。测量在一台配备 480 块磁盘（配置为 96 个 4+P RAID-5 设备，通过两个 I/O 服务器节点连接至 SP 交换机）的 32 节点 IBM RS/6000 SP 系统上进行。图中对比了多节点并行读写单个大文件与每个节点读写不同文件的情况。在单文件测试中，文件被划分为 n 个大的连续区段（每节点一个），每个节点顺序读写其对应的区段，写入为对已有文件的原地更新。图中从左侧单个文件系统节点使用四个 RAID 开始，每增加一个节点增加四个 RAID，直至右侧 24 个文件系统节点使用全部 96 个 RAID。结果显示，所有测试配置下读性能均呈近线性扩展。在测试系统中，数据吞吐量的瓶颈并非磁盘本身，而是 RAID 控制器。GPFS 实现的读吞吐量与通过 I/O 子系统进行原始磁盘读取的吞吐量相匹配。写吞吐量也呈现类似的扩展性。在 18 个节点时，写吞吐量趋于平稳，原因是交换机适配器微码存在一个缺陷。² 图中另一值得关注的点是：在 GPFS 中，多节点写同一文件与每个节点写不同文件的速度相当，这证明了上述字节范围令牌协议的有效性。
只要访问模式能够预测特定节点在近期将要访问的文件区域，令牌协商协议便能相应地在节点间划分字节范围令牌，从而最大限度地减少冲突。这不仅适用于简单的顺序访问，也适用于逆序和前向/后向步进访问模式，前提是每个节点在文件中操作不同的、相对较大的区域（粗粒度共享，coarse-grain sharing）。
随着共享粒度变细（每个节点向多个较小区域写入），令牌状态和相应的消息流量将会增大。需要注意的是，字节范围令牌不仅保证了 POSIX 语义，还同步了对文件数据块的 I/O。由于最小 I/O 单元为一个扇区（sector），字节范围令牌的粒度不得小于一个扇区，否则两个节点可能同时向同一扇区写入，导致更新丢失。事实上，GPFS 还使用字节范围令牌来同步数据块分配（见下一节），因此将字节范围令牌舍入到块边界。这意味着多个节点向同一数据块写入时，即使各自的写操作在字节级别并不重叠，也会产生令牌冲突（"伪共享"，false sharing）。
为了针对不要求 POSIX 语义的应用优化细粒度共享，GPFS 允许通过切换到数据转发模式（data shipping mode）来禁用常规字节范围锁。文件访问模式切换为一种可称为分区集中管理的方式：文件块以轮询方式分配给各节点，使得每个数据块仅由一个特定节点读写。GPFS 将源自其他节点的读写操作转发给负责该数据块的节点。对于细粒度共享，这比分布式锁更高效，因为它所需的消息数少于令牌交换，并且避免了撤销令牌时将脏数据刷写到磁盘的开销。数据块最终写入磁盘的操作仍然以并行方式完成，因为文件的数据块分散在多个节点上。
图 3 展示了共享粒度对写吞吐量的影响，分别对比了数据转发模式和常规字节范围锁的情况。这些测量在一台较小的 SP 系统上进行，该系统有八个文件系统节点和两个 I/O 服务器，每个 I/O 服务器连接八块磁盘。到每个 I/O 服务器的总吞吐量受交换机限制。³ 我们测量了八个节点对同一文件中固定大小记录进行更新时的吞吐量。测试采用步进访问模式，第一个节点写入记录 0、8、16……，第二个节点写入记录 1、9、17……，以此类推。较大的记录大小（图右半部分）是文件系统块大小的整数倍。图 3 显示，字节范围锁在这些大小下实现了接近满载的 I/O 吞吐量，因为它们与字节范围令牌的粒度相匹配。记录大小小于一个块的更新（图左半部分）需要双倍 I/O，因为涉及读-改-写（read-modify-write）操作。然而，字节范围锁的吞吐量远低于预期的二分之一，原因是多个节点向同一数据块写入时产生了令牌冲突，导致每个数据块被多次读写。标有"BR 令牌活动"的曲线绘制了在字节范围锁吞吐量测试期间令牌服务器测量到的令牌活动量，表明吞吐量下降确实是由额外的 I/O 活动造成，而非令牌服务器过载。图 3 中数据转发模式的吞吐量曲线显示，数据转发同样承受了读-改-写惩罚加上节点间数据传输的额外开销，但对于细粒度共享对应的小记录大小，其性能大幅优于字节范围锁。数据转发实现旨在支持细粒度访问，因此对于大于块大小的记录并不试图避免读-改-写操作，这解释了数据转发吞吐量在较大记录大小时保持平稳的原因。
数据转发模式主要由 MPI/IO 库使用
。MPI/IO 不要求 POSIX 语义，并提供了一种自然机制来定义将块分配给节点的集合操作（collective）。然而，MPI/IO 用于控制数据转发的编程接口同样对其他希望使用此类文件访问方式的应用程序开放 [13]。
² 测试机器使用了预发布版本的 RS/6000 SP Switch2 适配器。在该早期版本的适配器微码中，从多个节点向单个 I/O 服务器节点发送数据的效率不如从 I/O 服务器节点向多个节点发送数据。
³ 此处使用较旧的 RS/6000 SP 交换机，标称吞吐量 150 MB/s，软件开销将其降至约 125 MB/s。
3.4 文件元数据访问的同步
与其他文件系统一样，GPFS 使用 inode 和间接块（indirect block）来存储文件属性和数据块地址。多个节点向同一文件写入时，会并发更新文件的 inode 和间接块，以记录文件大小和修改时间（mtime）的变化，以及新分配数据块的地址。若通过对 inode 加独占写锁来同步磁盘上的元数据更新，将在每次写操作时产生锁冲突。
为此，GPFS 中的写操作对 inode 使用共享写锁（shared write lock），允许多个节点并发写入同一文件。该共享写锁仅与需要精确文件大小和/或 mtime 的操作冲突（如 stat() 系统调用，或尝试读取到文件末尾之后的读操作）。访问文件的其中一个节点被指定为该文件的元数据节点（metanode）；只有 metanode 才会从磁盘读写 inode。每个写入节点在本地维护 inode 的缓存副本，并周期性地或在共享写令牌被其他节点的 stat() 或 read() 操作撤销时，将其 inode 更新转发给 metanode。metanode 通过保留所收到的最大文件大小和最新 mtime 值来合并来自多个节点的 inode 更新。非单调地更新文件大小或 mtime 的操作（如 trunc() 或 utimes()）需要获取独占 inode 锁。
间接块的更新以类似方式进行同步。向新文件写入时，每个节点独立地为其写入的数据块分配磁盘空间。字节范围令牌提供的同步保证了只有一个节点会为任何特定数据块分配存储空间——这正是 GPFS 将字节范围令牌舍入到块边界的原因。周期性地或在字节范围令牌被撤销时，新的数据块地址被发送给 metanode，由其相应地更新缓存中的间接块。
因此，GPFS 使用分布式锁来保证 POSIX 语义（例如，stat() 系统调用能看到最近一次完成写操作的文件大小和 mtime），但磁盘上 inode 和间接块的 I/O 通过集中式方式（将 inode 更新转发给 metanode）进行同步。这使得多个节点能够在不产生元数据更新锁冲突且无需每次写操作都向 metanode 发送消息的情况下写入同一文件。
某个文件的 metanode 在令牌服务器的帮助下动态选举产生。当一个节点首次访问某文件时，它会尝试获取该文件的 metanode 令牌。令牌被授予第一个提出请求的节点，其他节点则获知 metanode 的身份。因此，在没有并发文件共享的传统工作负载中，每个节点成为其使用文件的 metanode，并在本地处理所有元数据更新。
当文件在 metanode 上不再被访问且从该节点的缓存中老化淘汰时，该节点放弃其 metanode 令牌并停止担任 metanode 角色。当它随后收到来自其他节点的元数据请求时，发送一个否定回复；另一节点将随即尝试通过获取 metanode 令牌来接替 metanode 角色。因此，一个文件的 metanode 倾向于保持在活跃访问该文件的节点集合之内。
3.5 分配图
分配图（allocation map）记录了文件系统中所有磁盘块的分配状态（空闲或已使用）。由于每个磁盘块最多可被划分为 32 个子块以存储小文件数据，分配图对每个磁盘块包含 32 位信息，以及用于高效查找空闲磁盘块或特定大小子块的链表。
分配磁盘空间需要更新分配图，而这必须在节点间进行同步。为保证正确的条带化，写操作必须在特定磁盘上为特定数据块分配空间，但鉴于 GPFS 使用的块大小较大，该数据块写在该磁盘的具体位置并不那么重要。这一特点允许以下列方式组织分配图，从而最大程度地减少节点间冲突：通过在分配图中交错存放不同磁盘的空闲空间信息，将分配图划分为数量固定的 n 个可独立加锁区域，每个区域包含文件系统中所有磁盘上 1/n 磁盘块的分配状态。这种分配图布局使 GPFS 能够通过每次仅访问一个分配区域来完成跨所有磁盘的正确条带化磁盘空间分配。该方法能最大程度地减少锁冲突，因为不同节点可以从不同区域分配空间。区域总数在文件系统创建时根据集群预期节点数量确定。
对于每个 GPFS 文件系统，集群中有一个节点负责维护所有分配区域的空闲空间统计信息，称为分配管理器（allocation manager）节点。该节点在文件系统挂载时通过读取分配图来初始化空闲空间统计信息。统计信息通过周期性消息保持大致最新，每个节点在消息中报告其在上一周期内净分配或释放的磁盘空间量。当一个节点在当前使用的区域中耗尽磁盘空间时，不必所有节点都各自搜索仍有空闲空间的区域，而是向分配管理器请求下一个可用区域。分配管理器尽量通过将不同节点引导至不同区域来防止节点间的锁冲突。
删除文件时同样需要更新分配图。由运行在数百个节点上的并行程序创建的文件，其分配块可能遍及数百个区域。删除文件需要锁定并更新每个这些区域，可能需要从当前正在使用这些区域进行分配的节点手中"抢夺"，这可能对性能产生灾难性影响。
因此，GPFS 并不在执行删除操作的节点上处理所有分配图更新，而是将更新已知正被其他节点使用的区域的那些操作发送给这些节点执行。分配管理器周期性地分发关于哪些节点正在使用哪些区域的提示，以便将释放（deallocation）请求路由到合适的节点。
图 4 展示了分配管理器提示以及上一节中描述的 metanode 算法的有效性。我们对比测量了对已有文件进行原地更新写入与创建新文件时的写吞吐量。与图 2 相同，我们测量了所有节点写同一文件（与图 2 使用相同的访问模式）以及每个节点写不同文件的情况。测量在与图 2 相同的硬件上进行，写吞吐量数据点实际上与前图中展示的相同。由于分配磁盘存储所需的额外工作，文件创建的吞吐量略低于原地更新。然而，图 4 显示，创建吞吐量仍随节点数量近线性扩展，且多节点创建单个文件与每个节点创建不同文件的速度相当。
3.6 其他文件系统元数据
GPFS 文件系统还包含其他全局元数据，包括文件系统配置数据、磁盘空间配额（quota）、访问控制列表（ACL）和扩展属性（extended attributes）。篇幅所限，不对每类元数据的管理方式作详细描述，但有必要略作说明。与前述章节中的案例类似，GPFS 使用分布式锁保护磁盘上元数据的一致性，但在大多数情况下采用更集中化的管理方式来协调或收集来自不同节点的元数据更新。例如，配额管理器（quota manager）向写文件的各节点发放相对较大的磁盘空间增量，使得配额检查在本地完成，仅偶尔与配额管理器交互。
3.7 令牌管理器的扩展性
令牌管理器追踪授予集群所有节点的所有锁令牌。获取、放弃、升级或降级一个令牌都需要向令牌管理器发送消息。人们可能合理地预期，令牌管理器在大型集群中可能成为瓶颈，或令牌状态的体积可能超过令牌管理器的内存容量。
解决这些问题的一种方式是对令牌空间进行分区，将令牌状态分散到集群中的多个节点。然而我们发现，这并非解决令牌管理器扩展性问题最好的——或至少不是最重要的——方式，原因如下。
分布令牌状态的一种直接方法是对文件 inode 号进行哈希。遗憾的是，这无法解决单文件并行访问引发的扩展性问题。在最坏情况下，多节点并发更新一个文件会为该文件的每个数据块生成一个字节范围令牌。由于文件大小事实上没有上限，单个文件的字节范围令牌状态规模也是无界的。理论上可以将单个文件的字节范围令牌管理分散到多个节点，但这会使单节点获取整个文件令牌的常见情形代价高昂。因此，令牌管理器通过监控自身内存使用情况，并在必要时主动撤销令牌来压缩令牌状态，防止其无限增长。⁴
令牌管理器节点高负载的最可能原因是导致令牌撤销的锁冲突。当一个节点降级或放弃令牌时，该令牌所涵盖的脏数据或元数据必须被刷写到磁盘和/或从缓存中清除。如前所述（见图 3），令牌冲突引起的磁盘 I/O 代价远超令牌管理器消息本身的代价。因此，从源头避免锁冲突是降低令牌管理器负载、提升整体性能远比分布令牌状态更有效的途径。第 3.5 节中描述的分配管理器提示就是避免锁冲突的一个例子。
此外，GPFS 在令牌协议中采用了若干优化措施，显著降低了令牌管理的代价并改善了响应时间。当需要撤销令牌时，由发起撤销的节点负责向所有以冲突模式持有该令牌的节点发送撤销消息，收集这些节点的回复，并将其作为单条消息转发给令牌管理器。无论有多少节点以冲突模式持有令牌，获取一个令牌所需的令牌管理器消息不超过两条。
该协议还支持令牌预取（token prefetch）和令牌请求批处理（token request batching），允许通过一条消息向令牌管理器批量获取多个令牌。例如，首次访问一个文件时，读写该文件所需的 inode 令牌、metanode 令牌和字节范围令牌可以通过单次令牌管理器请求一并获取。
当一个文件在某节点上被删除时，该节点不会立即放弃与该文件关联的令牌。该节点创建的下一个文件可以复用旧的 inode，而无需获取任何新令牌。在不同节点上的用户各自在其主目录下创建和删除文件的工作负载，将产生极少甚至为零的令牌流量。
图 5 展示了这一优化的有效性，显示了在多个节点上运行多用户文件服务器工作负载时的令牌活动情况。工作负载由 dbench 程序 [10] 生成，该程序模拟 NetBench [11] 文件服务器基准测试的文件系统活动。测试在八个文件系统节点上运行，每个节点模拟 10 个 NetBench 客户端的工作负载，每个客户端运行于不同的子目录中。图中显示了基准测试在所有节点上启动时的初始令牌活动峰值——每个节点为其客户端访问的文件获取令牌。尽管基准测试全程持续创建和删除文件，但每个节点只复用了有限数量的 inode。一旦所有节点获得了足够数量的 inode，令牌活动便迅速降至接近零。对令牌服务器 CPU 负载的测量表明，其每秒可处理 4000 到 5000 个令牌请求，因此图 5 中的峰值请求速率仅占令牌服务器容量的极小部分。峰值高度本身也只是由于基准测试在所有节点上同时启动的人为因素造成，在实际多用户工作负载下不太可能出现。
⁴ 当然，不要求 POSIX 语义的应用可以使用数据转发模式来绕过字节范围锁，从而避免令牌状态问题。
4 容错
随着集群规模扩大到大量节点和磁盘，所有组件在任何时候都正常工作的可能性越来越低。这意味着需要优雅地处理组件故障，并在故障存在的情况下继续运行。
4.1 节点故障
当节点发生故障时，GPFS 必须将该故障节点正在更新的元数据恢复到一致状态，释放故障节点持有的资源（锁令牌），并为故障节点所扮演的任何特殊角色（如 metanode、分配管理器或令牌管理器）指定替代者。
由于 GPFS 将恢复日志存储在共享磁盘上，由节点故障导致的元数据不一致可以通过在某个存活节点上运行故障节点日志的日志恢复来迅速修复。日志恢复完成后，令牌管理器释放故障节点持有的令牌。分布式锁协议确保故障节点在故障时刻必定持有其在缓存中已更新但尚未写回磁盘的所有元数据的令牌。由于这些令牌只有在日志恢复完成后才会被释放，故障节点修改的元数据在确认其处于一致状态之前不会被其他节点访问。即使在 GPFS 采用更集中化方式同步元数据更新的情况下（例如由 metanode 收集的文件大小和 mtime 更新），这一点同样成立。尽管导致这些更新的写操作并未通过分布式锁同步，但磁盘上元数据的更新仍受到分布式锁协议的保护——在此情况下，通过 metanode 令牌实现。
日志恢复完成后，其他节点可以获取故障节点曾持有的 metanode 令牌，从而接管 metanode 角色。如果另一节点曾向旧 metanode 发送元数据更新，但在故障发生时尚未收到更新已提交到磁盘的确认，它将把更新重新发送给新 metanode。这些更新具有幂等性（idempotent），因此新 metanode 可以直接重新应用它们。
若令牌管理器发生故障，另一节点将接管这一职责，并通过向所有存活节点查询其当前持有的令牌来重建令牌管理器状态。由于新令牌管理器不知道故障节点持有哪些令牌，在日志恢复完成之前它不会授予任何新令牌。存活节点当前持有的令牌不受此影响。
类似地，故障节点承担的其他特殊功能（如分配管理器）也会被分配给另一节点，由其通过读取磁盘信息和/或查询其他节点来重建必要的状态。
4.2 通信故障
为检测节点故障，GPFS 依赖一个组服务层（group services layer），该层通过周期性心跳消息监控节点和通信链路，并实现进程组成员协议 [12]。当节点故障时，组服务层通知其余节点组成员资格发生变化，从而触发上一节中描述的恢复操作。
网络适配器故障或网线松动等通信故障可能导致某节点与其他节点隔离，交换结构故障则可能引起网络分区（network partition）。这种分区与不可达节点故障在外部表现上无法区分。处于不同分区的节点可能仍能访问共享磁盘，若允许它们相互独立地继续运行，将导致文件系统损坏。为此，GPFS 仅允许包含集群中多数节点的组（多数组，majority group）访问文件系统；少数组中的节点将停止访问任何 GPFS 磁盘，直至重新加入多数组。
遗憾的是，成员协议无法保证每个节点接收和处理故障通知所需的时间。当网络分区发生时，不再属于多数组的节点何时会被通知并停止访问共享磁盘，并不确定。因此，在多数组开始日志恢复之前，GPFS 通过调用磁盘子系统提供的原语，将不再是组成员的节点从共享磁盘上隔离（fence），即阻止磁盘接受来自这些节点的 I/O 请求，称为磁盘隔离（disk fencing）。
为支持容错的双节点配置，此类配置中的通信分区完全通过磁盘隔离解决，而不使用多数规则：收到另一节点故障通知时，每个节点将按预定顺序尝试对另一节点隔离所有磁盘。在网络分区情况下，只有其中一个节点会成功，并能继续访问 GPFS 文件系统。
4.3 磁盘故障
由于 GPFS 将数据和元数据条带化到文件系统中的所有磁盘，单块磁盘的丢失将不成比例地影响大量文件。因此，典型的 GPFS 配置使用双连接（dual-attached）RAID 控制器，能够屏蔽物理磁盘故障或磁盘访问路径丢失的影响。大型 GPFS 文件系统跨多个 RAID 设备进行条带化。在此类配置中，将文件系统块大小和对齐方式与 RAID 条带（stripe）匹配非常重要，以避免数据块写入时因奇偶校验更新产生写惩罚（write penalty）。
作为 RAID 的替代方案或补充，GPFS 支持在文件系统层实现的复制（replication）。启用后，GPFS 为每个数据或元数据块在两块不同磁盘上分配空间并同时写入两个副本。当磁盘不可用时，GPFS 追踪哪些文件在不可用磁盘上的块有更新。当磁盘重新可用时，GPFS 通过从其他副本复制数据，将磁盘上的陈旧数据更新至最新状态。若磁盘永久故障，GPFS 可以在其他磁盘上为所有受影响的块重新分配新副本。
复制可分别针对数据和元数据启用。在磁盘部分区域变得不可读（坏块）的情况下，文件系统中的元数据复制确保只有少量数据块受到影响，而不会导致一整批文件无法访问。
5 可扩展的在线系统工具
可扩展性不仅对正常文件系统操作至关重要，对文件系统工具（utilities）同样如此。这些工具需要处理文件系统中大量的数据和元数据，因此与并行应用一样能从并行化中受益。
例如，GPFS 允许通过在现有文件系统中添加、删除或替换磁盘来扩展、缩减或重组文件系统。添加新磁盘后，GPFS 允许通过将部分现有数据迁移到新磁盘来重新平衡（rebalance）文件系统。为从文件系统中移除或替换一块或多块磁盘，GPFS 必须将所有数据和元数据从受影响的磁盘迁移走。所有这些操作都需要读取所有 inode 和间接块以找到必须移动的数据。其他同样需要读取所有 inode 和间接块的工具包括碎片整理（defragmentation）、配额检查（quota-check）和 fsck⁵ [13]。此外，当复制启用且一组曾经下线的磁盘重新上线时，GPFS 必须执行元数据扫描以找到需要应用到这些磁盘的缺失更新的文件。
在合理时间内完成此类操作需要充分利用系统中可用的并行性。为此，GPFS 为每个文件系统指定一个节点作为文件系统管理器（file system manager），负责协调此类管理活动。文件系统管理器向集群中的每个节点分发一小段 inode 编号范围，每个节点处理其分配范围内的文件，处理完成后向文件系统管理器发送消息请求更多工作。这样，所有节点并行处理不同的文件子集，直至所有文件处理完毕。在此过程中，节点间可能会交换额外的消息以汇总全局文件系统状态。例如，在运行 fsck 时，每个节点收集分配图不同区段的块引用信息，从而能够检测跨文件的不一致性（如同一块被分配给两个不同文件）。
即使在最大并行度下，这些操作在大型文件系统上也可能耗费大量时间。例如，一个多太字节文件系统的完全重平衡可能需要数小时。由于文件系统长时间不可用是不可接受的，GPFS 允许所有文件系统工具在线（on-line）运行，即在文件系统已挂载且应用程序可访问的状态下运行。唯一例外是用于诊断目的的完整文件系统检查（fsck），该操作要求文件系统处于未挂载状态。文件系统工具使用正常的分布式锁与其他文件活动进行同步。仅在重组高层元数据（分配图和 inode 文件）时需要特殊同步。例如，当需要将一批 inode 从一块磁盘迁移到另一块时，执行迁移的节点在 inode 文件上获取一个特殊的范围锁，这比对批次内所有 inode 分别加锁更高效、破坏性更小。
⁵ 用于诊断目的，验证文件系统一致性，而非正常挂载流程的一部分。
6 实践经验
GPFS 安装于数百个客户站点，集群规模从数个节点、不足一太字节的磁盘，到 512 节点的 ASCI White 系统（配备两个文件系统，合计 140 太字节磁盘空间）不等。随着 GPFS 持续演进，积累了大量影响其设计的经验教训。这些经验本身足以构成一篇独立的论文，但其中有几点极具价值，值得在此分享。
节点内并行与负载均衡的重要性
我们的若干经验揭示了节点内并行性以及正确的集群节点负载均衡的重要性。在系统管理命令的初始设计中，我们假设在集群的每个节点上各启动一个线程来分发工作，就足以充分利用所有可用的磁盘带宽。例如，在重平衡文件系统时，按第 5 节所述，将 inode 范围分发给每个节点的一个线程的策略，能够产生足够的 I/O 请求以使所有磁盘保持繁忙。然而我们发现，严重低估了该策略所会遭遇的工作量倾斜（skew）程度。频繁地，一个节点会被分配到包含明显更多文件或更大文件的 inode 范围。在其他节点早已完成工作后很久，该节点仍在以单线程方式工作，每次只发出一个 I/O 请求。
显而易见的教训是，分发的工作粒度必须足够小且大致均匀（应是文件中的块范围，而非整个文件）。另一个不那么显而易见的教训是：即使在大型集群上，节点内并行性（intra-node parallelism）往往比节点间并行性（inter-node parallelism）更有效地提升性能。在通常是高度 SMP 系统且具有高 I/O 带宽的现代系统中，相对较少的节点就能使磁盘系统饱和。⁶ 例如，每个节点运行多个线程可以充分利用可用带宽，并大大减少工作负载倾斜的影响。
集中式管理功能对并行应用的影响
另一个重要教训是：尽管
GPFS 集中式管理功能（如令牌管理器）消耗的 CPU 通常不会影响应用性能，但它对高度并行的应用程序可能产生显著影响。此类应用通常以带有屏障同步点（barrier synchronization point）的阶段（phase）方式运行。如第 5 节所述，集中式服务由动态选出的文件系统管理器节点提供。若该节点同时运行并行应用的一部分，管理开销将导致其更晚到达屏障，使其他节点空等。若开销使应用性能下降仅 1%，在 512 节点的 ASCI White 上其他节点因此浪费的等待时间相当于 5 个节点闲置！为避免此问题，GPFS 允许将管理功能限制在一组指定的管理节点（administrative nodes）上。大型集群可以专门划出一两个管理节点，避免在其上运行对负载敏感的并行应用，实际上还增加了可用计算资源。
"ls -l"与增量备份的性能问题
早期版本的 GPFS 在运行"ls -l"和增量备份等程序时存在严重性能问题，这类程序会对目录中每个文件调用 stat()。stat() 调用需要读取文件的 inode，这需要一个读令牌。若另一节点持有该令牌，释放令牌可能需要将脏数据写回磁盘，因此获取令牌代价高昂。我们通过充分利用并行性解决了这一问题：当 GPFS 检测到对同一目录中多个 inode 的连续访问时，使用多线程为该目录中其他文件的 inode 进行预取。inode 预取（inode prefetch）将目录扫描速度提升了近 10 倍。
大规模系统中罕见故障的处理
我们在大型系统上学到的另一个教训是：即使是极为罕见的故障（如 RAID 中的数据丢失）也会发生。某个特别大的 GPFS 系统经历了 RAID 控制器的微码故障，该故障由更换磁盘期间的间歇性问题引起，导致分配图的三个扇区无法使用。不幸的是，尝试从这些扇区之一进行分配时产生了 I/O 错误，导致文件系统将自身下线。运行日志恢复时重复了写入该扇区的尝试，同样触发了 I/O 错误。幸运的是没有用户数据丢失，且客户在其他文件系统中有足够的空闲空间，允许将损坏的 14TB 文件系统以只读模式挂载并将数据复制到别处。尽管如此，现在许多大型文件系统在 RAID 之外还使用 GPFS 元数据复制，以对抗双重故障提供额外的安全保障。
系统性故障的应对
比罕见的随机故障更为险恶的是系统性故障。某客户不幸收到了来自一批劣质磁盘的数百块故障率异常高的驱动器，客户希望在不停机的情况下更换这些坏驱动器。人们可能认为可以通过依次更换每块驱动器并让 RAID 重建来实现，但这将大大增加双重故障（即 RAID 奇偶校验组在重建时另一块驱动器也故障）的可能性，进而导致文件系统的灾难性损毁。客户选择的解决方案是：从文件系统中删除少量磁盘（此处为 RAID 奇偶校验组），GPFS 将被删除磁盘上的数据重平衡到其余磁盘；然后用新驱动器创建新的奇偶校验组并加回文件系统（再次进行重平衡）。这一繁琐的过程重复进行，直至所有磁盘更换完毕，全程无需停机，也未损害文件系统可靠性。这一经验的启示包括：系统设计中不应假设故障相互独立，以及在线系统管理和并行重平衡的重要性。
7 相关工作
一类文件系统通过允许文件服务器客户端经由 SAN 直接从磁盘访问数据，将传统文件服务器架构扩展到存储区域网络（SAN）环境。此类 SAN 文件系统的例子包括 IBM/Tivoli SANergy [14] 和 Veritas SANPoint Direct [15]。这些文件系统能为大文件提供高效的数据访问，但与 GPFS 不同，所有元数据更新仍由集中式元数据服务器处理，这使该类架构在本质上具有较弱的可扩展性。SAN 文件系统通常不支持并发写入共享，或为支持它而牺牲 POSIX 语义。例如，SANergy 允许多个客户端通过 SAN 读写同一文件，但除非应用程序中明确添加 fcntl 锁调用，否则无法保证数据的一致视图。
SGI 的 XFS 文件系统 [16] 为 GPFS 所擅长的大规模、高吞吐量应用而设计。它以大型可变长度盘区（extent）存储文件数据，并依赖底层逻辑卷管理器将数据条带化到多块磁盘。但与 GPFS 不同，XFS 不是集群文件系统，它运行于大型 SMP 系统上。CXFS [17] 是 XFS 的集群版本，允许多个节点访问 XFS 文件系统共享磁盘上的数据。然而，与上述 SAN 文件系统类似，只有一个节点处理所有元数据更新。
Frangipani [18] 是一个在原理上与 GPFS 相似的共享磁盘集群文件系统。它基于相同的对称架构，使用基于写前日志的类似日志记录、锁定和恢复算法，且每个节点在共享磁盘上有独立的日志。与 GPFS 一样，Frangipani 使用基于令牌的分布式锁管理器。Frangipani 文件系统驻留于由 Petal [19] 提供的单一大型（2⁶⁴ 字节）虚拟磁盘上，Petal 将 I/O 请求重定向至一组 Petal 服务器，并处理物理存储分配和条带化。这种分层架构在一定程度上简化了文件系统中的元数据管理。然而，Petal 中磁盘空间分配的粒度（64KB）过大，且其虚拟地址空间过小，无法为 Frangipani 文件系统中的每个文件简单地预留一块固定的连续虚拟磁盘区域（如 1TB）。因此，Frangipani 仍需维护自己的分配图来管理 Petal 提供的虚拟磁盘空间。与 GPFS 不同，Frangipani 主要"针对具有程序开发和工程工作负载的环境"。它只实现了全文件锁，因此不支持从多个节点并发写入同一文件。
全局文件系统（GFS）[20] 是另一个共享磁盘集群文件系统的例子，它起源于面向 Linux 的开源文件系统。最新版本（GFS-4）实现了日志记录，并使用与 GPFS 和 Frangipani 类似的日志、锁定和恢复算法。GFS 中的锁定与物理存储紧密耦合。早期版本的 GFS [21] 要求通过 SCSI 协议扩展在磁盘设备层面实现锁定。较新版本允许使用外部分布式锁管理器，但仍以 4KB 或 8KB 的单个磁盘块为单位加锁。因此，在 GFS 中访问大文件所产生的锁开销远高于 GPFS 使用的字节范围锁。与 Frangipani/Petal 类似，GFS 中的条带化由"网络存储池"（Network Storage Pool）层处理；但一旦创建，条带宽度无法更改（可以添加新的"子池"，但条带化被限制在子池内，即 GFS 不会跨子池进行条带化）。与 Frangipani 类似，GFS 更面向文件内共享较少的应用。
8 总结与结论
GPFS 建立在学术界近年来发展出的诸多思想之上，尤其是分布式锁与恢复技术。迄今为止，这些思想的可扩展性如何，仍是业界猜测的问题。我们有幸在现存最大规模系统的产品环境中，对这些技术的极限进行了检验。
人们可能质疑分布式锁的可扩展性，尤其是对共享元数据的锁竞争是否会成为限制并行性和可扩展性的瓶颈。令我们颇为惊讶的是，分布式锁的扩展性相当好。尽管如此，对传统文件系统数据结构和锁定算法的若干重要改进，在对单个大文件的并行访问和对大量小文件的并行访问两种场景中均取得了显著的性能提升。我们描述了一系列使分布式锁在大型集群中有效运作的技术：字节范围令牌优化、动态选举文件的元数据节点来管理文件元数据、分段分配图以及分配提示。
人们同样可能质疑传统可用性技术的可扩展性。显然，大型系统中有更多组件可能故障。使问题更复杂的是，大型集群价格极为昂贵，其拥有者对高可用性有强烈需求。再加上数十太字节的文件系统规模大得根本无法备份和恢复。我们再次发现，基础技术是可靠的。令人惊讶的是，为提供数据完整性和可用性所必须采取的措施。GPFS 复制功能最初是因为彼时 RAID 比复制的普通磁盘更为昂贵而实现的。随着 RAID 价格下降，它已取代复制成为主流方案，但即使 RAID 的高级别完整性保障，对于防止百太字节文件系统的损毁也是不够的。
现有 GPFS 安装表明，我们的设计能够扩展至世界上最大的超级计算机，并提供管理如此大规模系统所必需的容错和系统管理功能。尽管如此，我们预期技术的持续演进将对可扩展性提出更高要求。Linux 集群和廉价 PC 节点的近期兴起进一步推高了组件数量。存储价格的下降已使客户认真考虑拍字节（petabyte）级文件系统。这一趋势使文件系统可扩展性在可预见的将来仍将是一个持续受到关注的研究方向。
9 致谢
多年来，IBM 多个部门的众多人员为 GPFS 的设计与实现做出了贡献。虽然篇幅所限无法在此一一列名，但以下人员对本文所报告的工作有重要贡献：Jim Wyllie、Dan McNabb、Tom Engelsiepen、Marc Eshel、Carol Hartman、Mike Roberts、Wayne Sawdon、Dave Craft、Brian Dixon、Eugene Johnson、Scott Porter、Bob Curran、Radha Kandadai、Lyle Gayne、Mike Schouten、Dave Shapiro、Kuei-Yu Wang Knop、Irit Loy、Benny Mandler、John Marberg、Itai Nahshon、Sybille Schaller、Boaz Shmueli、Roman Talyanski 以及 Zvi Yehudai。
参考文献
[1] Roger L. Haskin: Tiger Shark - a scalable file system for multimedia, IBM Journal of Research and Development, Volume 42, Number 2, March 1998, pp. 185-197.
[2] C. Mohan, Inderpal Narang: Recovery and Coherency-Control Protocols for Fast Intersystem Page Transfer and Fine-Granularity Locking in a Shared Disks Transaction Environment. VLDB 1991: 193-207.
[3] IBM builds world's fastest supercomputer to simulate nuclear testing for U.S. Energy Department. IBM Press Release, Poughkeepsie, N.Y., June 29, 2000.
[4] ASCI White. http://www.rs6000.ibm.com/hardware/largescale/supercomputers/asciwhite/
[5] ASCI White. http://www.llnl.gov/asci/platforms/white/home/
[6] Ronald Fagin, Jürg Nievergelt, Nicholas Pippenger, H. Raymond Strong, Extendible hashing - a fast access method for dynamic files, ACM Transactions on Database Systems, New York, NY, Volume 4 Number 3, 1979, pages 315-344.
[7] Frank B. Schmuck, James Christopher Wyllie, and Thomas E. Engelsiepen. Parallel file system and method with extensible hashing. US Patent No. 05893086.
[8] J. N. Gray, Notes on database operating systems, in Operating systems, an advanced course, edited by R. Bayer et. al., Springer-Verlag, Berlin, Germany, 1979, pages 393-400.
[9] Ajay Mohindra and Murthy Devarakonda, Distributed token management in the Calypso file system, Proceedings of the IEEE Symposium on Parallel and Distributed Processing, New York, 1994.
[10] Dbench benchmark. Available from ftp://samba.org/pub/tridge/dbench/
[11] NetBench benchmark. http://etestinglabs.com/benchmarks/netbench/netbench.asp
[12] Group Services Programming Guide and Reference, RS/6000 Cluster Technology, Document Number SA22-7355-01, Second Edition (April 2000), International Business Machines Corporation.
[13] IBM General Parallel File System for AIX: Administration and Programming Reference. Document Number SA22-7452-02, Second Edition (December 2000), International Business Machines Corporation.
[14] Charlotte Brooks, Ron Henkhaus, Udo Rauch, Daniel Thompson. A Practical Guide to Tivoli SANergy. IBM Redbook SG246146, June 2001.
[15] VERITAS SANPoint Direct File Access. Whitepaper, August 2000. VERITAS Software Corporation.
[16] A. Sweeney, D. Doucette, W. Hu, C. Anderson, M. Nishimoto, and G. Peck. Scalability in the XFS File System, Proceedings of the USENIX 1996 Technical Conference, pages 1-14, San Diego, CA, USA, 1996.
[17] SGI CXFS Clustered File System, Datasheet, Silicon Graphics, Inc.
[18] Chandramohan A. Thekkath, Timothy Mann, and Edward K. Lee. Frangipani: A Scalable Distributed File System. In Proceedings of the Symposium on Operating Systems Principles, 1997, pages 224-237.
[19] Edward K. Lee and Chandramohan A. Thekkath. Petal: Distributed Virtual Disks, In Proceedings of the Seventh International Conference on Architectural Support for Programming Languages and Operating Systems, Cambridge, MA, 1996, pages 84-92.
[20] Kenneth W. Preslan et al. Implementing Journaling in a Linux Shared Disk File System. Seventeenth IEEE Symposium on Mass Storage Systems, March 2000, pages 351-378.
[21] Kenneth W. Preslan et al. A 64-bit, Shared Disk File System for Linux. Sixteenth IEEE Mass Storage Systems Symposium, March 15-18, 1999, San Diego, California, pages 351-378.
原文发表于 USENIX FAST 2002 Conference on File and Storage Technologies，Monterey, California, USA，2002年1月28-30日。
浙公网安备 33010602011771号