5.2 典型分布式文件系统分布式文件系统是一个比较活跃的研究方向，现国内外很多大学及研究机构还有公司等都已经或正着手开发自己的分布式文件系统以支持那些I/O密集型应用，以此来发挥集群系统的优势。近年来，美国、澳大利亚、日本等多个国家的大学已经研究出一些各具特色的分布式文件系统。一些计算机厂家也开发了自己的分布式文件系统，这些系统一般为专用文件系统，多为运行在特定的UNIX操作系统之上的工作站或并行计算机。而开源社区中也开发出了一批可运行于Linux操作系统之上的分布式文件系统，正是这些开源项目大大促进了分布式文件系统的发展与应用。现有的各种分布式文件系统各具特色，各有各的优势，各有各的侧重点。现已涌现出一批著名的分布式文件系统，如PVFS、GPFS、zFS、Google文件系统、Lustre等等，下面将着重介绍PVFS和Lustre这两种分布式文件系统。 5.2.1 并行虚拟文件系统（PVFS） PVFS [2]（Parallel Virtual File System）项目是Clemson大学为了运行Linux集群而创建的一个开源项目，因此，PVFS也无需特别的硬件设备。普通的能运行Linux系统的PC机即可。PVFS现已被广泛地使用，很多分布式文件系统都是以PVFS为基础架构而设计实现的[3]，比如国内的浪潮并行文件系统。目前的版本是第二版[4]。正如一般的分布式文件系统一样，PVFS将数据存储到多个集群节点中，数据保存在这些节点的本地文件系统之中，然后多个客户端可以并行同时访问这些数据。PVFS有以下4个重要功能： 1）命名空间的一致性：为了易于安装和使用，PVFS提供了统一的文件命名空间。 2）文件的数据分散分布到不同的集群节点的本地磁盘之上：为高速访问集群系统中的文件数据，PVFS将文件数据进行条块化划分，分散存储到不同集群节点（称作I/O节点，如图5.4所示）的多个磁盘上，从而消除了单个I/O路径带来的瓶颈问题，且增加了客户端的并发带宽。 3）兼容现有系统上的文件访问方式：对已安装PVFS文件和目录能够继续使用现有Linux系统上的命令和工具，比如ls、cat、dd和rm等等，方便用户的使用。该功能由Linux核心的一个模块提供支持。 4）为应用程序提供高性能的数据访问方式：PVFS还提供了libpvfs库，以专有接口来访问PVFS文件系统。而libpvfs库直接和PVFS服务器相连接，不需要把消息传递给内核，这样提高了访问效率。 （点击查看大图）图 5.4 PVFS系统结构图 PVFS系统是一个3方架构：计算节点、管理节点和I/O节点，如图 5.4所示。其中，计算节点的功能运行应用程序，发起PVFS的I/O请求；管理节点的功能是管理元数据，接受并调度计算节点的I/O请求；I/O节点的功能是存放PVFS文件系统中的文件数据，所有文件数据的读写都要与I/O节点打交道。 PVFS系统中有且只有一个管理节点，一个或者多个计算节点和I/O节点。PVFS集群中任意一个集群节点既可以只提供3方架构中的其中一种功能，也可以提供同时提供2种或者3种功能。计算节点也同时用来做管理节点，也可以充当I/O节点的角色，反之亦然。对于小规模的集群系统，这种功能重叠的方法可以节省开支，充分利用资源；对于大规模集群系统，则一般不推荐使用这种功能重叠的方法，因为功能重叠会使机器过于繁忙，从而导致性能下降，一般是一个节点只充当一个角色。 PVFS还存在以下不足： 1）单一管理节点。上面说到过PVFS中只有一个管理节点来管理元数据，当集群系统达到一定的规模之后，管理节点将可能出现过度繁忙的情况，这时管理节点将成为系统瓶颈。 2）对数据的存储缺乏容错机制。当某一I/O节点无法工作时，上面的数据将出现不可用的情况。 3）静态配置。对PVFS的配置只能在启动前进行，一旦系统运行则不可再更改原先的配置
5.2.2 Lustre
Lustre[5]文件系统是一个基于对象存储的分布式文件系统，并且与PVFS一样，Lustre也是一个开源项目。Lustre项目与1999年在Carnegie Mellon University启动，现在已经发展成为应用最广泛的分布式文件系统。Lustre已经运行在当今世界上最快的集群系统里面，比如Bule Gene，Red Storm等计算机系统，用来进行核武器相关的模拟，以及分子动力学模拟等等非常关键的领域。
Lustre的组织结构在其官方文档中有详细的介绍，如图 5.5所示，Lustre集群组件包含了MDS（元数据服务器）、MDT（元数据存储节点）、OSS（对象存储服务器）、OST（对象存储节点）、Client（客户端），以及连接这些组件的高速网络。
1）元数据存储与管理。MDS负责管理元数据，提供一个全局的命名空间，Client可以通过MDS读取到保存于MDT之上的元数据。在Lustre中MDS可以有2个，采用了Active-Standby的容错机制，当其中一个MDS不能正常工作时，另外一个后备MDS可以启动服务。MDT只能有1个，不同MDS之间共享访问同一个MDT。
（点击查看大图）图 5.5 Lustre集群架构
2）文件数据存储与管理。OSS负载提供I/O服务，接受并服务来自网络的请求。通过OSS，可以访问到保存在OST上的文件数据。一个OSS对应2到8个OST，其存储空间可以高达8TB。OST上的文件数据是以分条的形式保存的，文件的分条可以在一个OSS之中，也可以保存在多个OSS中。Lustre的特色之一是其数据是基于对象的职能存储的，跟传统的基于块的存储方式有所不同。
3）Lustre系统访问入口。Lustre通过Client端来访问系统，Client为挂载了Lustre文件系统的任意节点。Client提供了Linux下VFS（虚拟文件系统）与Lustre系统之间的接口，通过Client，用户可访问操作Lustre系统中的文件。
Lustre集群中的各个节点通过高速的以太网或Quadrics Elan、Myrinet等多种网络连接起来。
（点击查看大图）图 5.6 Lustre文件系统架构
在Lustre官方手册中给出了Lustre文件系统的架构，如图 5.6所示。Lustre文件系统也是一个3方架构，包括了MDS、OSS和Client这3个模块。文件的打开（open）和关闭（close）、元数据以及并发访问控制都在Client和MDS之间进行；文件I/O操作以及文件锁在OSS和Client之间进行；文件备份，文件状态获取以及文件创建等在MDS和OSS之间进行。目前Lustre文件系统最多可以支持100000个Client，1000个OSS 和2个MDS节点。
同PVFS类似，Lustre系统中既可以运行一个功能模块，也可以同时运行2个或3个功能模块，这取决于系统的规模。不过Lustre一般运行于高性能计算机系统之上，为了提高Lustre文件系统的性能，通常MDS、OSS和Client是分开运行在Lustre不同的节点之上的。
实验与应用已经证明，Lustre文件系统的性能和可扩展性都不错。不仅如此，Lustre文件系统还拥有基于对象的智能化存储、安全的认证机制、比较完善的容错机制等优点，值得注意的是，Lustre还实现了部分文件锁。Lustre确保从不同Client端挂载的Lustre文件系统看到的都是一个单一的、同步的、一致的命名空间。由于Lustre部分锁机制的存在，多个Client端在同一时间点可以写同一文件的不同区域，其它Client则可以读取文件的其它区域。由于部分文件锁的存在，极大的提高了多用户对同一文件进行并发访问时系统的性能，对同一文件并发访问这在像数据库这种应用里是极为常见的。
相对于PVFS，Lustre的可用性和扩展性以及性能上都有较大的提高。然而，Lustre需要特殊设备的支持，并且Lustre目前还没实现MDS的集群管理，虽然相比PVFS的单MDS，Lustre的双MDS在可用性上还是提高不少，但是当系统达到一定的规模之后，MDS还是很有可能成为Lustre系统中的瓶颈
5.2.3 Panasas文件系统
PanFS[6]（Panasas File System）是Panasas公司用于管理自己的集群存储系统的分布式文件系统。Panasas公司于1999年由卡内基梅隆大学的Garth Gibson等人创建。PanFS使用并行和冗余的方式存取对象存储设备，使用基于文件的RAID冗余模式，分布式元数据管理、一致的客户cache管理、文件锁服务和内部的集群管理提供一个可扩展、容错和高性能的分布式文件系统。
在Panasas系统中存储集群被分为存储结点和管理结点，它们之间的比例是10比1，并且这个比例也是允许改变的。存储结点采用对象存储的方式，客户端的I/O可以直接存取存储结点；管理结点管理整个存储集群，使用分布式文件系统语义，处理存储结点失效时的恢复，并通过NFS和CIFS输出Panasas文件系统视图。图 5.7给出了整体的结构。
图 5.7 Panasas文件系统整体结构
Panasas使用本地的OSDFS文件系统管理存储对象，每个对象使用两级的命名空间（partition ID/object ID）并通过iSCSI传输层传递OSD命令，它类似于SNIA的OSDv2标准。PanFS在存储对象之上，每个文件被分到一个或者多个对象上提供冗余和并发存取。文件系统的语义通过元数据服务器表达以方便客户端对于OSD的存取。客户读取对象存储使用iSCSI/OSD协议。I/O操作以直接和并行的方式访问存储结点，而不需要经过元数据服务器。
对象属性被用于存储文件属性，文件目录映射到对象的ID。因此，文件系统的信息被保存在对象自身，无需元数据服务以其他形式单独保存。
在Panasas系统中包括的主要软件部件是：OSDFS对象存储系统、元数据管理器、客户端模块、NFS/CIFS网关和全局集群管理系统。
Panasas客户端是可安装的核心模块，运行在Linux的核心态，它使用标准的VFS接口，客户可以使用标准POSIX接口存取OSD中的数据。并且在2.4和2.6的Linux内核下无需安装补丁。
每个存储结点运行FreeBSD系统，开发并实现了硬件监控、配置管理和全局控制服务。并且每个使用定制的本地文件系统OSDFS，它们实现iSCSI目标器和OSD命令集。集群管理维护一个全局配置，并控制其他节点上的服务。它提供命令行和图像控制界面进行配置和管理。同时集群管理对集群成员进行失效检测，配置管理和全局操作（软件升级和系统重启）。
Panasas元数据管理器实现文件系统的语义和管理数据在多个OSD上的分条。它是一个用户级应用，可以运行在每个节点上。元数据管理器负责多用户的安全存取，维护文件和对象级的元数据一致性，客户端cache的一致性和系统崩溃后的恢复。容错是基于本地事务日志，并在不同的管理节点有副本。在实际安装中，存储集群使用刀片技术，能够提供很好的扩展性。11个刀片被集成到1个4U的机架里，并安装大容量的电池和一个或2个16端口的千兆交换机。交换机可以聚合4个千兆端口形成一个trunk。第二个交换机提供冗余，并连接到每个刀片的第二个千兆端口上。OSD和元数据服务器使用几乎同样的刀片硬件配置。存储刀片包括一个商用处理器、2个磁盘、ECC内存和双端口千兆网络适配器。目录刀片包括更快的处理器，更多内存和一个较小磁盘。目录刀片处理元数据管理之外，还提供NFS和CIFS服务。更大的内存用于数据cache提高协议的运行效率。
Panasas使用POSIX语义能够隐藏更多的管理复杂性，管理员可以在线地增加存储设备，新的资源被自动发现。为了管理可用的存储资源，使用两个最基本的概念，一个是物理的存储池称为刀片集，而逻辑引用树则称为卷。刀片集是一个卷的物理边界，刀片集可以在任何时候扩容，包括引入新的刀片或者两个刀片集合并。逻辑卷是一个目录树结构，并分配到一个特定的刀片集，有一个容量定额的限制。在卷中的文件分布在刀片集中的所有刀片上。卷在文件系统命名空间中就是一个目录，包括一个mount点。每个卷被一个元数据管理器维护。为了实现简单，在卷边界上划分元数据管理责任。
Panasas可以进行自动的容量管理，这可以分为被动平衡和主动平衡，被动平衡是指改变在一个存储结点上创建文件和增长文件的概率；主动平衡是把存储对象从一个存储结点移动到另外一个存储结点并更新该对象的元数据映射。容量管理对于文件系统的用户是透明的，能够在存储池内平衡I/O负载。
为了保证数据对象的可用性，把文件分成多个对象并分散到不同的存储结点上面，这多个对象之间使用容错的分条算法（RAID-1或者RAID-5），小文件镜像称两个存储对象，大文件可以广泛地分布其数据对象。基于文件的RAID结构使得不同文件的校验信息分散存放，由客户端负责文件数据的校验，减少元数据服务器的负担。
在Panasas中，有几种元数据，包括对象ID到块地址映射、文件到一组对象的映射、文件的属性（包括存取控制表和其他信息）、文件系统命名空间信息和集群的配置和管理信息。这些元数据的管理被对象存储设备和元数据管理器所承担。其中块级元数据由存储结点的OSDFS在修改过的B树结构中存储文件系统的数据结构，例如分区和对象的分配表等。对于每个对象的块映射使用传统的直接、间接和多次间接结构。自由空间用位图数据结构维护。文件本身元数据（用户可以看到的，例如所有者等）和前两个数据对象存放在一起。文件名类似于传统的文件系统，而目录存放在特殊文件，用户可以读、缓冲和解析目录，或者通过查询RPC从元数据服务器上解析位置信息。系统级的元数据存在一组系统管理服务器上面，每个系统管理器维护一个基于Berkeley DB的本地数据库，系统管理服务器组通常设置奇数个服务器，使用PTP协议（Lamport' part-time parliament）去做出配置决定或升级配置。系统状态包括静态状态（刀片的身份等）和动态状态（各种服务的在线离线状态等）。集群管理在两个层面上应用，一个是底层PTP层管理系统管理器的增加，另一个是应用层去做出系统的配置决策
5.2.4 全局并行文件系统（GPFS）
GPFS[7]是IBM公司并行共享磁盘的集群文件系统，已经被应用于世界上很多大的超级计算中心。GPFS的扩展性来源于共享磁盘的系统结构，如图 5.8所示。
图 5.8 GPFS文件系统整体结构
集群中所有结点都可以平等地存取所有的磁盘，所有的文件以分条方式存放在所有磁盘上面，这能够充分发挥存储系统的吞吐率。
在GPFS中最有特殊的是分布式锁管理机制。由于在物理上所有磁盘可以在所有客户端之间共享，而文件系统的一致性以及POSIX语义的要求，物理上的并行性受到很大的限制。GPFS使用一个中央的全局锁管理器和文件系统结点上的本地锁管理器合作来处理锁令牌。重复的存取同一个磁盘对象只需要确认所有权的一个简单信息。当一个结点从全局锁管理器获取一个令牌，这个节点对于同一个对象的后续存取就不需要额外的通信。仅当其他结点对于同一个对象操作需要一个冲突锁，对于传递令牌到其他节点再需要额外的信息。锁在维护cache一致性方面也是重要的。GPFS使用字节粒度的锁去同步多个客户对于一个文件的读写操作。这导致多个客户可以同时写数据到一个文件不同的位置。考虑到字节锁会产生很大的维护开销，GPFS把维护文件字节锁的任务交给第一个存取该文件的节点负责，它和同时写该文件的后续客户协商和分配字节锁。对于多个客户同步存取文件的元数据，GPFS采用共享的写锁保证并行的写操作，客户对于大多数操作对于元数据的更新信息放到metanode结构，只有相应的inode从磁盘中读取或者写到磁盘时，metanode才合并多个更新。只有进行更新文件大小和修改文件更新时间时才需排他锁。
GPFS把恢复日志保存在共享磁盘上，由结点失效导致的元数据的不一致能够由其他节点运行失效结点的恢复日志很快修复。而GPFS使用组服务层来通过组成员协议和周期性的心跳测试检测结点失效，当一个结点失效时，组服务层通知组内剩余的结点，并启动恢复过程。而GPFS通过在多个磁盘或者磁盘阵列上分布数据以保证单个磁盘失效不会导致数据丢失。另外，GPFS能够在线地增加，减小或者重新分布磁盘
5.2.5 Google文件系统（GoogleFS）
谷歌文件系统（Google File System，GoogleFS）是为了满足快速增长的数据处理需要而设计的。在开发实现GoogleFS之前，设计人员首先对Google应用程序负载和应用环境进行了深入探讨和分析，它能运行在不可靠硬件设备上进行海量的数据处理，处理来自多个用户的并发访问。文件系统中存放的数据绝大部分采用追加新数据而非覆盖现有数据的方式进行写操作。除了考虑到这些需要和技术特点后，GoogleFS也考虑了分布式文件系统的共性设计目标：性能、可扩展性、可靠性和可用性。
（点击查看大图）图4.20 Google文件系统的架构示意图
GoogleFS包括一个主服务器和多个大数据块服务器，这些块服务器响应多个客户端的访问请求，如图所示。文件被分割成64MB固定大小的数据块（Chunk），它分布在各个块服务器上，每个块在多个服务器上都存有副本，为了可靠性，一般存放3个副本。块服务器使用下层物理文件系统（如Ext3）来存放数据块。
主服务器负责维护所有文件系统的元数据，包括命名空间、文件至数据块的映射信息，访问控制信息，以及主存中数据块的当前位置。之所以将数据块读入主存是为了提高主服务器的操作性能。为了获得数据块的位置信息，主服务器只在块服务器启动时轮询一下数据块信息，直到新的数据块产生并在心跳信息的提示下主服务器才更新这些位置信息。
客户端直接使用文件系统API来访问主服务器和块服务器。为了减少发给主服务器的请求数量，客户端只对元数据进行缓存，需要注意的是，客户端和块服务器对文件数据不进行高速缓存。GoogleFS采用的副本技术来提高数据可用性，数据块和元数据都存在副本，比如每个数据块在3台块服务器上都存在副本；当管理元数据的主服务器宕机时，备用的"影子"服务器则切换过来，但它只能提供读取操作，不支持修改、写入操作。为了增加数据可恢复性，GoogleFs采用了操作日志和快照技术
5.2.6 Hadoop分布式文件系统（HDFS）
Hadoop[8]是一个基于JAVA的支持数据密集型分布式应用的分布式文件系统。它能够保证应用可以在上千个低成本商用硬件存储结点上处理PB级的数据。Hadoop是Apache开源项目，Yahoo支持这个项目并在自己的web搜索和商业广告业务上使用它。Hadoop开发类似于Google的MapReduce和Google文件系统的技术。图 5.9为Hadoop的整体结构。
Hadoop作为一个开源项目，受到GoogleFS很大启发。Hadoop包括两个部分：Hadoop分布式文件系统（Hadoop Distributed File System，HDFS）和MapReduce编程模型，其中HDFS运行在商用硬件上，它和现有分布式文件系统很相似，但也具备了明显的差异性，比如HDFS是高度容错的，可运行在廉价硬件上；HDFS能为应用程序提供高吞吐率的数据访问，适用于大数据集的应用中；HDFS在POSIX规范进行了修改，使之能对文件系统数据进行流式访问，从而适用于批量数据的处理。HDFS为文件采用一种"一次写多次读"的访问模型，从而简化了数据一致性问题，使高吞吐率数据访问成为可能，一些Map/Reduce应用和网页抓取程序在这种访问模型下表现完美。
如果距离数据越近，计算就越为有效，特别是在大数据集情况下，它能最小化网络冲突并提高系统的总吞吐率。因此HDFS提出了"移动计算能力比移动数据更廉价" 的设计理念，它将计算迁移到距离数据更近的位置，而不是将数据移动到应用程序运行的位置，HDFS提供了这种迁移应用程序的API接口。
HDFS是一种主/从模式的系统结构，如错误！未找到引用源。5.9所示，主服务器，即上图中的命名节点，它管理文件系统命名空间和客户端访问，具体文件系统命名空间操作包括'打开'、'关闭'、'重命名'等，并负责数据块到数据节点之间的映射；此外，存在一组数据节点，它除了负责管理挂载在节点上的存储设备，还负责响应客户端的读写请求。HDFS将文件系统命名空间呈现给客户端，并运行用户数据存放到数据节点上。从内部构造看，每个文件被分成一个或多个数据块，从而这些数据块被存放到一组数据节点上；数据节点会根据命名节点的指示执行数据块创建、删除和复制操作。
大量的低成本商用计算机具有较高的失效率，因此失效检测，快速高效的恢复是Hadoop文件系统的主要设计目标。同时Hadoop也更加适用于批量流水数据存取应用而不是交互较多的小I/O应用，事实上它更加关注提高系统的整体吞吐率而不是响应时间。同时HDFS更优化存储大文件（最好是64MB的倍数）。并且系统使用简单的一致性协议，因此主要针对面向写一次读很多次的应用。Hadoop同时给应用程序提供接口以保证处理过程尽量靠近数据的位置，减少中间数据传输的开销。Hadoop很容易从一个平台移植到另一个平台。
（点击查看大图）图 5.9 Hadoop文件系统的整体结构
HDFS有一个主从结构。一个HDFS集群包含一个NameNode和多个DataNode。NameNode是主服务器，维护文件系统命名空间、规范客户对于文件的存取和提供对于文件目录的操作。DataNode负责管理存储结点上的存储空间和来自客户的读写请求。DataNode也执行块创建、删除和来自NameNode的复制命令。
HDFS被设计用来可靠性地保存大文件，它使用一组顺序块保存文件，除文件最后一个块外，其他的块大小相等。块大小和文件的副本数依赖于每个文件自己的配置。NameNode周期性的收到每个DataNode的心跳和块报告，前者表示相应的DataNode是正常的，而后者包括DataNode上所有block的列表。机架可知的副本放置策略是HDFS性能和可靠性的关键。它通过在多个节点上复制数据以保证可靠性。缺省的冗余度是3，两个数据副本在同一个机架，另一个在其他的机架。当用户访问文件时，HDFS把离用户最近的副本数据传递给用户使用。
HDFS的命名空间存放在NameNode上，NameNode使用事务log（EditLog）去记录文件系统元数据的任何改变。而文件系统命名空间包括文件和块的映射关系和文件系统属性等它们存放在FsImage文件中，Editlog和FsImage都保存在NameNode的本地文件系统中。同时它还在内存中保存整个文件系统的命名空间和文件的块映射图。
所有HDFS的通讯协议是建立在TCP/IP协议之上的，在客户和NameNode之间建立ClientProtocol协议，文件系统客户端通过一个端口连接到命名节点上，通过客户端协议与命名节点交换；而在DataNode和NameNode之间建立DataNode协议。上面两种协议都封装在远程过程调用协议（Remote Procedure Call，RPC）之中。一般地，命名节点不会主动发起RPC，只响应来自客户端和数据节点的RPC请求。
HDFS提出了数据均衡方案，即，如果某个数据节点上的空闲空间低于特定的临界点，那么就会启动一个计划自动地将数据从一个数据节点迁移到空闲的数据节点上。当对某个文件的请求突然增加时，那么也可能启动一个计划创建该文件新的副本，并分布到集群中以满足应用的要求。副本技术在增强均衡性的同时，也增加系统可用性。
当一个文件创建时，HDFS并不马上分配空间，而是在开始时，HDFS客户端在自己本地文件系统使用临时文件中缓冲的数据，只有当数据量大于一个块大小时，客户端才通知NameNode分配存储空间，在得到确认后，客户端把数据写到相应的DataNode上的块中。当一个客户端写数据到HDFS文件中时，本地缓冲数据直到一个满块形成，DataNode从NameNode获取副本列表，客户端把数据写到第一个DataNode后，当这个DataNode收到小部分数据时（4KB）再把数据传递给第二个DataNode，而第二个DataNode也会以同样方式把数据写到下一个副本中。这就构成了一个流水线式的更新操作。
在删除文件时，文件并不立刻被HDFS删除，而是重命名后放到/trash目录下面，直到一个配置的过期时间到才删除文件。
文件系统是建立在数据结点集群上面，每个数据结点提供基于块的数据传输。浏览器客户端也可以使用HTTP存取所有的数据内容。数据结点之间可以相互通信以平衡数据、移动副本，以保持数据较高的冗余度。
5.2.7 分布式文件系统评价
在Panasas，Lustre，GPFS和PVFS2这几种被应用的主流高性能文件系统集群中，Lustre需要使用相对比较健壮的对象存储服务器，使用简单的分条策略，但并没有在单个结点失效后主动重分布数据的能力。PVFS2在存储结点间结点进行数据分条，但没有使用校验和冗余机制以保证系统的可用性。并且GPFS和Lustre依赖于存储结点的磁盘阵列来容忍磁盘失效， PVFS2虽然使用普通的商用机器，但不能保证磁盘失效后系统运行的正常。
集群的NFS系统包括ISilon，NetApp的GX和PolyServe。这些系统受限于单一NFS入口点，使得扩展性受到限制，事实上发展中的并行NFS（NFS4.1）可能解决这个问题。
SAN文件系统包括CXFS、EMC的MPSFi、Oracle的OCFS2和GFS2等。它们是面向块接口的，元数据服务器需要管理十亿以上的数据块，并且使用非标准的客户端和元数据服务器。GPFS也是一种SAN文件系统，但使用分布锁管理和大数据块策略（256K到4MB）支持更大规模的集群系统。GPFS使用一个中央令牌管理器为块、inode、属性和目录项建立细粒度的锁，第一个获得锁的客户将负责维护相应共享对象的一致性管理，这减少了元数据服务器的负担。
还有几个正在开发中的对象存储系统，包括Ceph和Usra Minor。Usra Minor提供对象的基本属性改变的版本追踪。而Ceph使用基于Hash的分布策略，它的对象服务器相互传播副本，但没有采用分条策略。Lustre把分布式锁管理协议应用到所有部件（OSS，元数据服务器和客户端）中。Panasas对象模型是基于iSCSI/OSD命令集。
在多个数据存储服务器上分条是为了提高传输过程的整体带宽。在Zebra文件系统中，客户端产生写多个文件到不同服务器的日志，每个文件更新通道构成了一个数据流，一个校验数据被生产用于失效后的恢复。在NASD基础之上的Cheops并行文件系统使用了针对每个文件的分条机制。Isilon也把文件分条存放在多个存储结点上面，使用RAID和Reed Soloman编码区进行冗余保证数据不丢失。RAIF系统映射一个文件到多个文件系统，也允许分条。Lustre使用简单RAID0的分条机制。
Google文件系统是一个用户级的文件系统，它实现基于特定应用的函数库。GoogleFS使用副本来进行容错。客户端负责把数据写到副本中，再通知元数据服务器更新。GoogleFS使用应用层语义支持并发操作。
在所有系统中，仅Panasas、Isilon、Google和Ceph使用存储结点间冗余机制防止磁盘失效。其他系统依赖于存储结点的硬件RAID或者软件阵列保证磁盘失效时的数据可用性。目前大部分系统使用单个元数据服务器，而Panasas和GPFS有多个元数据服务器，而Ceph则使用细粒度的Hash策略分布元数据
