OCFS2 手册

OCFS2 – Linux共享磁盘集群文件系统

引言

OCFS2是一个文件系统。它允许用户存储和检索数据。数据存储在以分层目录树组织的文件中。它是POSIX兼容的文件系统，支持该规范说明的标准接口和行为语义。

它也是一个共享磁盘集群文件系统，该文件系统允许多个节点同时访问同一磁盘。这就是乐趣的开始，因为允许在多个节点上访问文件系统会打开蠕虫罐。(This is where the fun begins as allowing a file system to be accessible on multiple nodes opens a can of worms.) 如果节点具有不同的架构怎么办？如果节点在写入文件系统时挂掉，该怎么办？如果两个节点上的进程同时进行读写操作，可以期待什么样的数据一致性？如果一个节点在文件仍在另一节点上使用的同时删除了该文件怎么办？

与答案模糊的大多数共享文件系统不同，OCFS2中的答案定义非常明确。它在所有节点上的行为与本地文件系统完全相同。如果删除了文件，则将删除目录条目，但只要在整个集群中都使用它，inode就会保留。当最后一个用户关闭描述符时，将索引节点标记为删除。

数据一致性模型遵循相同的原理。它就像在两个不同节点上运行的两个进程在同一个节点上运行一样。不管使用哪种IO模式，对节点的读取都将获得最后的写入。这些模式可以是缓冲，直接，异步，拼接或内存映射的IO。它是完全高速缓存连贯的。

以REFLINK功能为例，该功能允许用户创建文件的多个可写快照。像所有其他功能一样，此功能完全支持集群。在多个节点上写入的文件可以在另一个节点上安全地重新链接。创建的快照是文件的时间点映像，其中包括文件数据及其所有属性（包括扩展属性）。

它是日记文件系统。当节点死亡时，存活节点透明地重放死亡节点的日志。这样可以确保文件系统元数据始终保持一致。它还默认使用有序数据日志记录，以确保在日志记录提交之前将文件数据刷新到磁盘，以消除崩溃后文件中出现陈旧数据的这种很小的可能性。

它是体系结构和字节序中立的。它允许在具有不同处理器（例如x86，x86_64，IA64和PPC64）的节点上并发安装。它处理大小端字节的32位和64位体系结构。

它是功能丰富的。它支持索引目录、元数据校验和、扩展属性、POSIX ACL、配额、REFLINK、稀疏文件、未写入的扩展数据和内联数据。

它与主线Linux内核完全集成。OCFS2文件系统在2006年初合并到Linux内核2.6.16中。

它可快速安装。几乎所有Linux发行版都可以使用它。文件系统在所有磁盘上都是磁盘兼容的。

它是模块化的。可以将文件系统配置为与其他集群堆栈（如Pacemaker和CMAN）以及其自己的堆栈O2CB一起运行。

它易于配置。O2CB集群堆栈配置涉及编辑两个文件，一个用于集群布局，另一个用于集群超时。

它非常有效。OCFS2文件系统消耗很少的资源。它用于在有限的内存环境（例如Xen和KVM）中存储虚拟机映像。

总之，OCFS2是一个高效，易于配置，模块化，快速安装，完全集成和兼容，功能丰富的体系结构和字节序中性，缓存一致，有序数据日志记录，符合POSIX的共享磁盘集群文件系统。

概览

OCFS2是用于Linux的通用共享磁盘集群文件系统，能够同时提供高性能和高可用性。

由于它提供了本地文件系统语义，因此几乎可以与所有应用程序一起使用。支持集群的应用程序可以利用来自多个节点的缓存一致性并行I/O轻松扩展应用程序。如果节点发生故障，其他应用程序可以利用集群工具对正在运行的应用程序进行故障转移。

OCFS2文件系统值得关注的特性有：

可调块大小

文件系统支持512、1K，2K和4K字节的块大小。几乎总是建议使用4KB。该功能在OCFS2文件系统的所有发行版中均可用。

可调簇大小

簇大小也称为分配单位。文件系统支持4K，8K，16K，32K，64K，128K，256K，512K和1M字节的簇大小。对于大多数用例，建议使用4KB。
但是，对于托管大部分都非常大的文件（例如数据库文件、虚拟机映像等）的卷，建议使用较大的值。较大的簇大小可使文件系统更有效地存储大文件。该功能在OCFS2文件系统的所有发行版中均可用。

字节序和架构中立

文件系统可以同时挂载在具有不同体系结构的节点上。像32位、64位、Little-Endian（x86，x86_64，ia64）和Big-endian（ppc64，s390x）。该功能在OCFS2文件系统的所有发行版中均可用。

缓冲、直接、异步、拼接和内存映射的I/O模式

文件系统支持所有I/O模式，以实现最大的灵活性和性能。它还支持集群范围内的共享可写mmap(2)。在所有发行版中都提供对缓冲、直接和异步I/O的支持。在Linux内核2.6.20中添加了对Splice I/O的支持，并在2.6.23中添加了对共享可写map(2)的支持。

多个集群堆栈

文件系统包括一个灵活的框架，使其可以与用户空间集群堆栈（如Pacemaker（pcmk）和CMAN（cman））、其自己的内核内集群堆栈o2cb、无集群堆栈一起工作。

所有版本均提供对o2cb集群堆栈的支持。

Linux内核2.6.20中增加了对无集群堆栈或本地挂载的支持。

Linux内核2.6.26中增加了对用户空间集群堆栈的支持。

日志记录

文件系统支持有序（默认）和回写数据日志记录模式，以在电源故障或系统崩溃时提供文件系统一致性。它在Linux内核2.6.28及更高版本中使用JBD2。它在较早的内核中使用JBD。

基于范围的分配

文件系统在集群范围内分配和跟踪空间。这与必须跟踪每个块的基于块的文件系统不同。此功能使文件系统在处理大容量文件和大文件时都非常高效。该功能在文件系统的所有发行版中均可用。

稀疏文件

稀疏文件是带有空洞的文件。使用此功能，文件系统会延迟分配空间，直到向集群发出写操作为止。此功能已添加到Linux内核2.6.22中，并且需要启用磁盘功能sparse。

未写入的范围

未写入的范围也称为用户预分配。它允许应用程序请求在文件中分配一定范围的簇，但不初始化。预分配使文件系统可以用更少，更大的范围来优化数据布局。它还可以提高性能，延迟初始化，直到用户写入簇为止。此功能已添加到Linux内核2.6.23中，并且需要启用磁盘功能unwritten。

打孔

打孔允许应用程序删除文件中任意分配的区域。本质上是制造孔。这比将相同范围调零更为有效。此功能在虚拟化环境中特别有用，因为它允许将Guest文件系统中的块丢弃转换为主机文件系统中的打孔，从而允许用户减少磁盘空间使用。
此功能已添加到Linux内核2.6.23中，并且需要启用磁盘功能sparse以及unwritten。

内联数据

内联数据也称为in-inode数据，因为它允许在inode块中存储小的文件和目录。这不仅节省了空间，而且对冷缓存目录和文件操作产生了积极影响。当数据不再适合inode块时，将透明地移出数据。此功能已添加到Linux内核2.6.24中，并且需要启用磁盘功能inline-data。

REFLINK

REFLINK也称为快速复制。它允许用户自动（并立即）复制常规文件。换句话说，创建常规文件的多个可写快照。之所以称为REFLINK，是因为其看上去比传统快照更像（硬）链接。像链接一样，它是常规的用户操作，受限于reflinked的inode的安全性属性，而不是创建快照通常所需的超级用户特权。像链接一样，它在文件系统中运行。但是，与链接不同，它在数据范围级别上链接inode，从而使每个reflinked的inode在写入时都可以独立增长。多达40亿个inode可以共享一个数据范围。此功能已添加到Linux内核2.6.32中，并且需要启用磁盘功能引用计数（refcount）。

分配保留

文件连续性在文件系统性能中起着重要作用。当文件在磁盘上碎片化时，对该文件的读写操作涉及许多Seek动作，从而导致吞吐量降低。另一方面，连续文件可最大程度地减少寻道，从而使磁盘以最大速率执行IO。

通过分配保留，文件系统会在位图中为所有扩展文件保留一个窗口，从而允许每个文件尽可能连续地增长。由于实际上并没有分配额外的空间，因此如有需要，其他文件可以使用它。此功能已在Linux内核2.6.35中添加，可以使用挂载选项resv_level进行调整。

索引目录

索引目录允许用户在非常大的目录中快速查找文件。它还可以加快创建和取消链接的速度，从而提供更好的整体性能。此功能已添加到Linux内核2.6.30中，并且需要启用磁盘功能indexed-dirs。

文件属性

这指的是EXT2样式的文件属性，例如不可变的(immutable)，使用chattr修改并使用lsattr查询的属性。Linux内核2.6.19中添加了此功能。

扩展属性

扩展属性指的是一个name:value对，该对可以与常规文件、目录、符号链接等文件系统对象关联。OCFS2允许每个对象关联无限数量的属性。属性名称的长度最多为255个字节，以第一个NUL字符终止。虽然不是必需的，但建议使用可打印的名称（ASCII）。属性值最多可以是64 KB的任意二进制数据。可以使用标准Linux实用程序setfattr和getfattr修改和列出这些属性。此功能已添加到Linux内核2.6.29中，并且需要启用磁盘功能xattr。

元数据校验和

该功能允许文件系统检测所有元数据块（如inode和目录）中的无提示损坏。此功能已添加到Linux内核2.6.29中，并且需要启用磁盘功能metaecc。

POSIX ACL和安全属性

POSIX ACL允许为文件和目录分配细粒度的自由访问权限。该安全方案比传统的文件访问权限（采用严格的user-group-other模型）灵活得多。

安全属性允许文件系统支持其他安全机制，例如SELinux，SMACK，AppArmor等。

这两个安全扩展都是在Linux内核2.6.29中添加的，并且需要启用磁盘功能xattr。

用户和组配额

此功能允许通过使用诸如quota，setquota，quotacheck和quotaon之类的标准实用程序，来基于用户和用户组设置使用配额。此功能已添加到Linux内核2.6.29中，并且需要启用磁盘功能usrquota和grpquota。

Unix文件锁

Unix操作系统历来提供了两个系统调用来锁定文件。flock或BSD锁以及fcntl或POSIX锁。OCFS2将两个文件锁都扩展到了集群。在一个节点上执行的文件锁与在其他节点上执行的文件锁交互。（File locks taken on one node interact with those taken on other nodes.）

Linux内核2.6.26中增加了对集群flock的支持。支持所有flock选项，包括内核在用户收到适当的终止信号时取消锁定请求的功能。所有集群堆栈（包括o2cb）都支持此功能。

Linux内核2.6.28中增加了对集群fcntl的支持。但是因为需要群组通信才能使锁连贯，所以只有用户空间集群堆栈pcmk和cman支持它，而默认集群堆栈o2cb不支持。

全面的工具支持

文件系统具有全面的EXT3样式的工具集，该工具集尝试使用相似的参数来简化操作。它包括mkfs.ocfs2（格式化），tunefs.ocfs2（调整），fsck.ocfs2（检测），debugfs.ocfs2（调试）等。

在线调整大小

可以使用tunefs.ocfs2动态扩展文件系统。Linux内核2.6.25中添加了此功能。

兼容性

OCFS2开发团队竭尽全力维护兼容性。它尝试在文件系统的所有发行版之间维持磁盘和网络协议的兼容性。即使在添加需要磁盘格式和网络协议更改的新功能时，它也会这样做。为了成功做到这一点，它遵循一些规则：

磁盘格式更改由一组可以打开和关闭的功能标志管理。内核中的文件系统在挂载期间会检测到这些功能，并且仅在了解所有功能后才继续。遇到此问题的用户可以选择禁用该功能或将文件系统升级到较新的版本。
最新版本的ocfs2-tools与文件系统的所有版本兼容。所有实用程序都会检测磁盘上启用的功能，并且仅在了解所有功能后才能继续。遇到此问题的用户必须将工具升级到较新的版本。
节点协商网络协议版本，以确保所有节点都了解正活跃的协议版本。

功能特性标识

功能标志分为三类，即Compat，Incompat和RO Compat。

Compat，或说是Compatible/兼容，是指那种文件系统不需要完全了解即可安全地读取或写入卷的特性。其中一个示例是backup-super功能，该功能增加了在文件系统中多个位置备份超级块的功能。由于文件系统通常不会读取或写入备份超级块，因此较早的文件系统可以在启用此功能的情况下安全地挂载卷。

Incompat，或说是Incompatible/不兼容，是指那些文件系统需要充分了解才能读取/写入卷的特性。大多数功能特性都属于此类别。

RO Compat，或说是Read-Only Compatible/只读兼容，是文件系统需要充分了解它才能写入卷的功能特性。较旧的软件可以安全地读取启用这些特性的卷。用户和组配额就是一个例子。由于仅在写入文件系统时才操作配额，因此较旧的软件可以安全地以只读模式挂载此类卷。

功能标志列表，添加它的内核版本，了解它的工具的最早版本等如下：

Feature Flags	Kernel Version	Tools Version	Category	Hex Value
backup-super	All	ocfs2-tools 1.2	Compat	1
strict-journal-super	All	All	Compat	2
local	Linux 2.6.20	ocfs2-tools 1.2	Incompat	8
sparse	Linux 2.6.22	ocfs2-tools 1.4	Incompat	10
inline-data	Linux 2.6.24	ocfs2-tools 1.4	Incompat	40
extended-slotmap	Linux 2.6.27	ocfs2-tools 1.6	Incompat	100
xattr	Linux 2.6.29	ocfs2-tools 1.6	Incompat	200
indexed-dirs	Linux 2.6.30	ocfs2-tools 1.6	Incompat	400
metaecc	Linux 2.6.29	ocfs2-tools 1.6	Incompat	800
refcount	Linux 2.6.32	ocfs2-tools 1.6	Incompat	1000
discontig-bg	Linux 2.6.35	ocfs2-tools 1.6	Incompat	2000
clusterinfo	Linux 2.6.37	ocfs2-tools 1.8	Incompat	4000
unwritten	Linux 2.6.23	ocfs2-tools 1.4	RO Compat	1
grpquota	Linux 2.6.29	ocfs2-tools 1.6	RO Compat	2
usrquota	Linux 2.6.29	ocfs2-tools 1.6	RO Compat	4

要查询卷上启用的功能特性，请执行以下操作：

$ o2info --fs-features /dev/sdf1
backup-super strict-journal-super sparse extended-slotmap inline-data xattr
indexed-dirs refcount discontig-bg clusterinfo unwritten

启用和禁用功能特性

格式实用程序mkfs.ocfs2，允许用户使用fs-features选项启用和禁用特定功能。这些功能以逗号分隔的列表形式提供。启用的功能按原样列出。禁用的功能以no为前缀。下面的示例显示了在禁用稀疏nosparse和启用内联数据inline-data的情况下格式化文件系统。

# mkfs.ocfs2 --fs-features=nosparse,inline-data /dev/sda1

格式化后，用户可以使用tune实用程序tunefs.ocfs2切换功能特性。这是一个离线操作。该卷需要在整个集群上卸载。以下示例显示了启用稀疏特性和禁用内联数据特性。

# tunefs.ocfs2 --fs-features=sparse,noinline-data /dev/sda1

在启用和禁用功能之前，应格外小心。计划将卷与文件系统的旧版本一起使用的用户最好不要启用新功能，因为调整禁用可能不会成功。

一个例子是禁用稀疏功能。这需要填充每个孔。只有文件系统具有足够的可用空间，操作才能成功。

检测功能不兼容

假设有人尝试挂载具有不兼容功能的卷。那会发生什么呢？如何发现问题？如何知道不兼容功能的名称？

首先，应该在dmesg中查找错误消息。由于功能不兼容而导致的挂载故障将始终导致如下错误消息：

ERROR: couldn't mount because of unsupported optional features (200).

这里，由于不支持的可选功能，文件系统无法挂载该卷。这意味着该功能是不兼容的功能。通过参考上表，可以推断出用户在启用xattr功能的情况下无法装入卷。（错误消息中的值为十六进制。）

由于不兼容而导致的错误消息的另一个示例如下：

ERROR: couldn't mount RDWR because of unsupported optional features (1).

在这里，文件系统无法以RW模式挂载该卷。这意味着该功能是RO Compat功能。再次查看该表，很明显该卷启用了unwritten功能。

在这两种情况下，用户都可以选择禁用该功能。在第二种情况下，用户可以选择在RO模式下挂载文件卷。

入门

OCFS2软件分为两个组件，即内核和工具。内核组件包括核心文件系统和集群堆栈，并且打包到内核。工具组件打包为ocfs2-tools，需要专门安装。它提供了用于格式化、调整、挂载、调试和检测文件系统的实用程序。

要安装ocfs2-tools，请参阅发行版中的软件包处理实用程序。

下一步是选择集群堆栈。选项包括：

A. 无集群堆栈或本地挂载。
B. 具有本地或全局心跳的内核o2cb集群堆栈。
C. 用户空间集群堆栈pcmk或cman。

文件系统允许使用tunefs.ocfs2轻松更改集群堆栈。要列出标记在OCFS2卷上的集群堆栈，请执行以下操作：

# mounted.ocfs2 -d
Device     Stack  Cluster     F  UUID                              Label
/dev/sdb1  o2cb   webcluster  G  DCDA2845177F4D59A0F2DCD8DE507CC3  hbvol1
/dev/sdc1  None                  23878C320CF3478095D1318CB5C99EED  localmount
/dev/sdd1  o2cb   webcluster  G  8AB016CD59FC4327A2CDAB69F08518E3  webvol
/dev/sdg1  o2cb   webcluster  G  77D95EF51C0149D2823674FCC162CF8B  logsvol
/dev/sdh1  o2cb   webcluster  G  BBA1DBD0F73F449384CE75197D9B7098  scratch

非集群或本地挂载

要将OCFS2卷格式化为非集群（本地）卷，请执行以下操作：

# mkfs.ocfs2 -L "mylabel" --fs-features=local /dev/sda1

要将现有的集群卷转换为非集群卷，请执行以下操作：

# tunefs.ocfs2 --fs-features=local /dev/sda1

非集群卷不与集群堆栈交互。可以同时挂载集群卷和非集群卷。

在格式化非集群卷时，用户应考虑以后将其转换为集群卷的可能性。如果有这种可能，则用户应使用-N选项添加足够的节点插槽。在格式化期间添加节点槽会创建大范围(扩展性)的日志。如果稍后创建，则日志将被分散，这不利于性能。

O2CB集群堆栈下的集群化挂载

两种心跳模式中，同一时间只能有一种模式处于活动状态。更改心跳模式是一项离线操作。

两种心跳模式都需要分别填充ocfs2.cluster.conf(5)和o2cb.sysconfig(5)中所述的/etc/ocfs2/cluster.conf和/etc/sysconfig/o2cb。两种模式之间唯一的区别在于，全局模式要求配置心跳设备，而本地模式则不需要。

有关更多信息，请参见o2cb(7)。

本地心跳

这是默认的心跳模式。用户需要按照用户手册ocfs2.cluster.conf(5)和o2cb.sysconfig(5)中所述填充配置文件。在这种模式下，集群堆栈心跳在所有已安装的卷上。因此，不必在cluster.conf中指定心跳设备。

配置完成后，o2cb集群堆栈可以按以下方式联机和脱机：

# service o2cb online
Setting cluster stack "o2cb": OK
Registering O2CB cluster "webcluster": OK
Setting O2CB cluster timeouts : OK

# service o2cb offline
Clean userdlm domains: OK
Stopping O2CB cluster webcluster: OK
Unregistering O2CB cluster "webcluster": OK

全局心跳

该配置类似于本地心跳。此模式下的另一个步骤是，它还需要配置心跳设备。

这些心跳设备是OCFS2格式的卷，在磁盘上启用了全局心跳。这些卷以后可以安装并用作集群文件系统。

o2cb手册中列出了在启用全局心跳的情况下格式化卷的步骤。还列出了列出磁盘堆栈上标记有集群堆栈的所有卷。

在此模式下，心跳在集群联机时启动，在集群脱机时停止。

# service o2cb online
Setting cluster stack "o2cb": OK
Registering O2CB cluster "webcluster": OK
Setting O2CB cluster timeouts : OK
Starting global heartbeat for cluster "webcluster": OK

# service o2cb offline
Clean userdlm domains: OK
Stopping global heartbeat on cluster "webcluster": OK
Stopping O2CB cluster webcluster: OK
Unregistering O2CB cluster "webcluster": OK

# service o2cb status
Driver for "configfs": Loaded
Filesystem "configfs": Mounted
Stack glue driver: Loaded
Stack plugin "o2cb": Loaded
Driver for "ocfs2_dlmfs": Loaded
Filesystem "ocfs2_dlmfs": Mounted
Checking O2CB cluster "webcluster": Online
  Heartbeat dead threshold: 31
  Network idle timeout: 30000
  Network keepalive delay: 2000
  Network reconnect delay: 2000
  Heartbeat mode: Global
Checking O2CB heartbeat: Active
  77D95EF51C0149D2823674FCC162CF8B /dev/sdg1
Nodes in O2CB cluster: 92 96

用户空间集群堆栈下的集群化挂载

在使用tunefs.ocfs2更新磁盘上的集群堆栈之前，请配置并使用户空间堆栈pcmk或cman联机上线。

# tunefs.ocfs2 --update-cluster-stack /dev/sdd1
Updating on-disk cluster information to match the running cluster.
DANGER: YOU MUST BE ABSOLUTELY SURE THAT NO OTHER NODE IS USING THIS
FILESYSTEM BEFORE MODIFYING ITS CLUSTER CONFIGURATION.
Update the on-disk cluster information? y

有关启动和停止集群堆栈的信息，请参阅集群堆栈文档。

文件系统实用工具

本节列出了用于管理OCFS2文件系统的实用程序。这包括格式化、调整、检测、挂载、调试文件系统的工具。每个实用程序都有一个手册页，其中详细列出了其功能。

`mkfs.ocfs2`

文件系统格式化实用程序。所有文件卷在使用前都必须先格式化。由于该实用程序会覆写文件卷，因此请谨慎使用。仔细检查以确保该卷没有在群集中的任何节点上使用。

作为预防措施，如果在本地挂载该卷，该实用程序将中止。如果由OCFS2使用，它还将检测整个集群的使用情况。但是这些检查并不全面，可以被覆盖。因此请谨慎使用。

尽管并不总是必需的，但集群应该联机在线。

`tunefs.ocfs2`

文件系统调整实用程序。它允许用户更改某些磁盘上的参数，如卷标、uuid、节点插槽数、卷大小和日志大小。它还允许打开和关闭上面列出的文件系统功能特性。

此实用程序要求集群处于联机在线状态。

`fsck.ocfs2`

文件系统检测实用程序。它检测并修复磁盘上的错误。所有检测代码及其修复程序都列在手册fsck.ocfs2.checks(8)中。

此实用程序要求群集处于联机在线状态，以确保该卷未在其他节点上使用，并防止在检测期间挂载该卷。

`mount.ocfs2`

文件系统挂载实用程序。它由mount实用程序间接调用。

如果群集处于脱机状态或与磁盘上标记的群集不匹配，此实用程序将检测群集状态并中止。

`o2cluster`

文件系统群集堆栈更新实用程序。它允许用户将磁盘上的群集堆栈更新为所提供的堆栈。

仅在实用程序断定确保文件系统未被任何节点使用的情况下，该实用程序才会更新磁盘。

`o2info`

文件系统信息实用程序。它提供的信息包括磁盘上启用的功能、块大小、簇大小、可用空间碎片等。

特权用户和非特权用户都可以使用它。在设备上具有读取权限的用户可以提供设备的路径。其他用户可以提供已挂载文件系统上文件的路径。

`debugfs.ocfs2`

文件系统调试实用程序。它允许用户检查所有文件系统结构，包括遍历目录结构、显示inode、备份文件等，而无需挂载文件系统。

该实用程序要求用户在设备上具有读取权限。

`o2image`

文件系统镜像实用程序。它允许用户复制文件系统元数据框架（Skeleton），包括inode、目录、位图等。由于它排除了数据，因此极大地缩小了文件系统的大小。

创建的映像文件可用于调试磁盘损坏。

`mounted.ocfs2`

文件系统检测实用程序。它检测系统中的所有OCFS2卷，并列出其卷标、uuid和群集堆栈。

O2CB CLUSTER STACK UTILITIES

This sections lists the utilities that are used to manage O2CB cluster stack. Each utility has a man page that lists its capabilities in detail.

`o2cb`

This is the cluster configuration utility. It allows users to update the cluster configuration by adding and removing nodes and heartbeat regions. This utility is used by the o2cb init script to online and offline the cluster.

This is a new utility and replaces o2cb_ctl(8) which has been deprecated.

`ocfs2_hb_ctl`

This is the cluster heartbeat utility. It allows users to start and stop local heartbeat. This utility is invoked by mount.ocfs2(8) and should not be invoked directly by the user.

`o2hbmonitor`

This is the disk heartbeat monitor. It tracks the elapsed time since the last heartbeat and logs warnings once that time exceeds the warn threshold.

文件系统说明

本节包含一些可能对用户有帮助的有用说明。

平衡的集群

一个群集就是一台计算机。这是事实，而不是口号。这意味着群集中的错误节点会影响其他节点的行为。如果一个节点运行缓慢，则群集操作将在所有节点上减速。为避免这种情况，最好有一个平衡的群集。这是一个具有相同能力和负载的节点的群集。

对于此类群集的标准建议是在所有节点上具有相同的硬件和软件。但是，这不是一个硬性规定。毕竟，我们已经努力确保OCFS2在混合体系架构环境中工作。

如果在混合体系架构环境中使用OCFS2，请尝试确保节点具有相同的能力和负载。使用负载均衡器可以为后者提供帮助。能力指处理器的数量、速度，内存量，I/O吞吐量，网络带宽等。实际上，具有同等能力的异构节点并不总是可行的。在这种情况下，让较小的节点序数节点比较大的节点序数节点能力更强。O2CB群集堆栈在其所有平局竞争决胜算法逻辑中，都倾向于使用较低的节点序数。

这并不是建议您应在四核节点的群集中添加一个单核节点。节点序数的戏法没有任何帮助。

文件删除

在Linux中，rm删除目录条目。它不一定删除相应的inode。但是通过删除目录条目，它会给人inode索引节点已删除的错觉。
用户会迷惑——当他们在报告的可用空间中看不到相应的提升时。原因是inode删除还有更多的障碍需要克服。

首先是硬链接计数，它表示指向该inode的目录条目的数量。只要一个inode有一个或多个指向它的目录条目，就不能删除它。文件系统必须等待所有这些目录条目的删除。换句话说，等待该计数降至零。

第二个障碍是POSIX语义，即使文件在使用中也允许将其取消链接。在OCFS2中，这表示整个集群都在使用中。文件系统必须等待集群中的所有进程停止使用inode索引节点。

满足这些条件后，将删除索引节点，下一次同步之后，释放出来的空间即可见。

Now the amount of space freed depends on the allocation. Only space that is actually allocated to that inode is freed. 现在，释放的空间量取决于分配。仅那些实际分配到inode的已释放的空间。下面的示例显示了一个稀疏分配的文件，大小为51TB，其中实际上仅分配了2.4GB。

$ ls -lsh largefile
2.4G -rw-r--r-- 1 mark mark 51T Sep 29 15:04 largefile

此外，对于引用链接的（reflinked）文件，仅释放专用扩展区。当最后一个访问它的inode被删除时，共享的扩展区将被释放。下面的示例显示一个4GB文件，该文件与其他引用链接的（reflinked）文件共享3GB。删除它会增加1GB的可用空间。但是，如果它是唯一访问共享扩展区的文件，则将释放完整的4G。（下面提供了有关shared-du实用程序的更多信息。）

$ shared-du -m -c --shared-size reflinkedfile
4000    (3000)  reflinkedfile

删除本身是一个多步骤过程。一旦硬链接计数降至零，该索引节点便移至orphan_dir系统目录并将保留在该目录中，直到整个集群中的最后一个进程停止使用该inode为止。然后，文件系统释放扩展区，并将释放的空间计数添加到truncate_log系统文件中，并一直保留到下一次同步。只有在同步之后，释放的空间才对用户可见。

目录列表

ls可能是一个简单的命令，但并不便宜。昂贵的不是读取目录列表的部分，而是读取所有inode的第二部分，也称为inode状态。如果inode不在缓存中，则可能需要磁盘I/O。现在，尽管在所有文件系统中，冷缓存inode状态的价格都很昂贵，但在集群文件系统中更是如此，因为它需要在每个inode上获取集群锁。

另一方面，热缓存统计数据显示其对OCFS2的性能与对EXT3的性能相同。

换句话说，第二个ls将比第一个ls更快。但这是没保证的。假设您在文件系统中有一百万个文件，而内核内存不足以缓存所有inode。在这种情况下，每个ls都会涉及一些冷缓存统计信息。

分配预留

分配保留允许多个并发扩展的文件尽可能连续地增长。演示其功能的一种方法是运行一个脚本，该脚本以循环顺序扩展多个文件。下面的脚本通过将100个4KB的块挨个儿写入四个文件来实现。

$ for i in $(seq 0 99);
> do
>   for j in $(seq 4);
>   do
>     dd if=/dev/zero of=file$j bs=4K count=1 seek=$i;
>   done;
> done;

当在Linux内核2.6.34或更早版本的系统上运行时，我们最终得到的每个文件具有100个扩展数据块。完整的碎片。随着文件一个接一个地扩展，磁盘分配完全交错。

$ filefrag file1 file2 file3 file4
file1: 100 extents found
file2: 100 extents found
file3: 100 extents found
file4: 100 extents found

当在Linux内核2.6.35或更高版本的系统上运行时，我们看到每个文件具有7个扩展区。这比前面少了很多。越少的扩展范围，意味着磁盘上的连续性越高，并且总会带来更好的整体性能。

$ filefrag file1 file2 file3 file4
file1: 7 extents found
file2: 7 extents found
file3: 7 extents found
file4: 7 extents found

REFLINK操作

此功能允许用户创建常规文件的可写快照。在此操作中，文件系统使用与原始inode相同的扩展区指针创建一个新的inode。因此，多个inode可以共享数据范围。这在文件系统管理中增加了麻烦，因为Linux中没有任何现有的文件系统实用程序会出现此现象。du是一种用于计算文件空间使用情况的实用程序，简单地累加分配给每个inode的块。由于它不知道共享范围，因此它会高估使用的空间。假设，我们有一个5GB的文件，位于一个有42GB可用空间的卷中。

$ ls -l
total 5120000
-rw-r--r--  1 jeff jeff   5242880000 Sep 24 17:15 myfile

$ du -m myfile*
5000    myfile

$ df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdd1             50G   8.2G   42G  17% /ocfs2

如果我们将其reflink4次，则我们会期望目录列表报告五个5GB的文件，但df会报告可用空间不会丢失。而另一方面，du会报告磁盘使用上升到了25GB。

$ reflink myfile myfile-ref1
$ reflink myfile myfile-ref2
$ reflink myfile myfile-ref3
$ reflink myfile myfile-ref4

$ ls -l
total 25600000
-rw-r--r--  1 jeff jeff   5242880000 Sep 24 17:15 myfile
-rw-r--r--  1 jeff jeff   5242880000 Sep 24 17:16 myfile-ref1
-rw-r--r--  1 jeff jeff   5242880000 Sep 24 17:16 myfile-ref2
-rw-r--r--  1 jeff jeff   5242880000 Sep 24 17:16 myfile-ref3
-rw-r--r--  1 jeff jeff   5242880000 Sep 24 17:16 myfile-ref4

$ df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdd1             50G   8.2G   42G  17% /ocfs2

$ du -m myfile*
5000    myfile
5000    myfile-ref1
5000    myfile-ref2
5000    myfile-ref3
5000    myfile-ref4
25000 total

输入shared-du，一个可感知共享扩展区的du。该实用程序在括号中报告每个文件的共享扩展区和总占用空间。正如预期的那样，它列出了5GB的总体占用空间。可以使用shared-filefrag查看扩展区的详细信息。这两个实用程序都可以从http://oss.oracle.com/~smushran/reflink-tools/获得。我们目前正在将变更推向这些实用程序的上游维护者。

$ shared-du -m -c --shared-size myfile*
5000    (5000)  myfile
5000    (5000)  myfile-ref1
5000    (5000)  myfile-ref2
5000    (5000)  myfile-ref3
5000    (5000)  myfile-ref4
25000 total
5000 footprint

# shared-filefrag -v myfile
Filesystem type is: 7461636f
File size of myfile is 5242880000 (1280000 blocks, blocksize 4096)
ext logical physical expected length flags
0         0  2247937            8448
1      8448  2257921  2256384  30720
2     39168  2290177  2288640  30720
3     69888  2322433  2320896  30720
4    100608  2354689  2353152  30720
7    192768  2451457  2449920  30720
 . . .
37  1073408  2032129  2030592  30720 shared
38  1104128  2064385  2062848  30720 shared
39  1134848  2096641  2095104  30720 shared
40  1165568  2128897  2127360  30720 shared
41  1196288  2161153  2159616  30720 shared
42  1227008  2193409  2191872  30720 shared
43  1257728  2225665  2224128  22272 shared,eof
myfile: 44 extents found

数据一致性

共享文件系统中的挑战之一是当多个节点写入同一组文件时的数据一致性。例如，NFS提供了close-to-open的数据一致性，从而导致在客户端上关闭文件时才将数据刷新到服务器。这为在另一个节点上读取过时的数据打开了一个宽阔的时间窗口。

一个检测共享文件系统数据一致性的简单测试，涉及向同一文件同时追加数据。比如使用并行分布式shell如dsh或pconsole，运行uname -a >>/dir/file。如果一致，则文件将包含所有节点的结果。

# dsh -R ssh -w node32,node33,node34,node35 "uname -a >> /ocfs2/test"
# cat /ocfs2/test
Linux node32 2.6.32-10 #1 SMP Fri Sep 17 17:51:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Linux node35 2.6.32-10 #1 SMP Fri Sep 17 17:51:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Linux node33 2.6.32-10 #1 SMP Fri Sep 17 17:51:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Linux node34 2.6.32-10 #1 SMP Fri Sep 17 17:51:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

OCFS2是一个具有完全缓存一致性的集群文件系统。

不连续的块组

大多数文件系统在格式化期间都会为inode预分配空间。OCFS2在需要时动态分配此空间。

但是，当可用空间非常分散时，这种动态分配就存在问题，因为文件系统要求inode和扩展区分配器以连续的固定大小的块增长。

不连续块组功能特性，它通过允许分配器以较小的，可变大小的块来增长，以此来解决该问题。

此功能已添加到Linux内核2.6.35中，并且需要启用磁盘上的功能discontig-bg。

BACKUP SUPER BLOCKS

A file system super block stores critical information that is hard to recreate. In OCFS2, it stores the block size, cluster size, and the locations of the root and system directories, among other things. As this block is close to the start of the disk, it is very susceptible to being overwritten by an errant write. Say, dd if=file of=/dev/sda1.

Backup super blocks are copies of the super block. These blocks are dispersed in the volume to minimize the chances of being overwritten. On the small chance that the original gets corrupted, the backups are available to scan and fix the corruption.

mkfs.ocfs2(8) enables this feature by default. Users can disable this by specifying –fs-features=nobackup-super during format.

o2info(1) can be used to view whether the feature has been enabled on a device.

# o2info --fs-features /dev/sdb1
backup-super strict-journal-super sparse extended-slotmap inline-data xattr
indexed-dirs refcount discontig-bg clusterinfo unwritten

In OCFS2, the super block is on the third block. The backups are located at the 1G, 4G, 16G, 64G, 256G and 1T byte offsets. The actual number of backup blocks depends on the size of the device. The super block is not backed up on devices smaller than 1GB.

fsck.ocfs2(8) refers to these six offsets by numbers, 1 to 6. Users can specify any backup with the -r option to recover the volume. The example below uses the second backup. If successful, fsck.ocfs2(8) overwrites the corrupted super block with the backup.

# fsck.ocfs2 -f -r 2 /dev/sdb1
fsck.ocfs2 1.8.0
[RECOVER_BACKUP_SUPERBLOCK] Recover superblock information from backup block#1048576? <n> y
Checking OCFS2 filesystem in /dev/sdb1:
  Label:              webhome
  UUID:               B3E021A2A12B4D0EB08E9E986CDC7947
  Number of blocks:   13107196
  Block size:         4096
  Number of clusters: 13107196
  Cluster size:       4096
  Number of slots:    8

/dev/sdb1 was run with -f, check forced.
Pass 0a: Checking cluster allocation chains
Pass 0b: Checking inode allocation chains
Pass 0c: Checking extent block allocation chains
Pass 1: Checking inodes and blocks.
Pass 2: Checking directory entries.
Pass 3: Checking directory connectivity.
Pass 4a: checking for orphaned inodes
Pass 4b: Checking inodes link counts.
All passes succeeded.

合成文件系统（SYNTHETIC FILE SYSTEMS）

OCFS2的开发工作包括两个合成文件系统configfs和dlmfs。它还搞了第三个，debugfs。

`configfs`

configfs has since been accepted as a generic kernel component and is also used by netconsole and fs/dlm. OCFS2 tools use it to communicate the list of nodes in the cluster, details of the heartbeat device, cluster timeouts, and so on to the in-kernel node manager. The o2cb init script mounts this file system at /sys/kernel/config.

`dlmfs`

dlmfs exposes the in-kernel o2dlm to the user-space. While it was developed primarily for OCFS2 tools, it has seen usage by others looking to add a cluster locking dimension in their applications. Users interested in doing the same should look at the libo2dlm library provided by ocfs2-tools. The o2cb init script mounts this file system at /dlm.

`debugfs`

OCFS2 uses debugfs to expose its in-kernel information to user space. For example, listing the file system cluster locks, dlm locks, dlm state, o2net state, etc. Users can access the information by mounting the file system at /sys/kernel/debug. To automount, add the following to /etc/fstab: debugfs /sys/kernel/debug debugfs defaults 0 0

分布式锁管理器

集群的关键技术之一就是锁管理器，它可以维护集群中所有资源的锁状态。锁管理器的一种简单实现包含指定一个节点来处理所有事情。在此模型中，如果节点想要获取锁，则它将请求发送到锁管理器。但是，此模型有一个弱点：锁管理器挂掉将导致群集被seize up。

更好的模型是，所有节点都管理锁资源的子集。每个节点为它感兴趣的所有锁资源维护足够的信息。一旦某节点挂掉，其余节点将在该信息中合并以重建由死节点维护的锁状态。在这种方案中，锁开销分布在所有节点间。因此，术语为分布式锁管理器。

O2DLM是一个分布式锁管理器。它基于Kristin Thomas编写的，名为”Programming Locking Application”的规范，可通过以下链接获得。
http://opendlm.sourceforge.net/cvsmirror/opendlm/docs/dlmbook_final.pdf

DLM DEBUGGING

O2DLM has a rich debugging infrastructure that allows it to show the state of the lock manager, all the lock resources, among other things. The figure below shows the dlm state of a nine-node cluster that has just lost three nodes: 12, 32, and 35. It can be ascertained that node 7, the recovery master, is currently recovering node 12 and has received the lock states of the dead node from all other live nodes.

# cat /sys/kernel/debug/o2dlm/45F81E3B6F2B48CCAAD1AE7945AB2001/dlm_state
Domain: 45F81E3B6F2B48CCAAD1AE7945AB2001  Key: 0x10748e61
Thread Pid: 24542  Node: 7  State: JOINED
Number of Joins: 1  Joining Node: 255
Domain Map: 7 31 33 34 40 50
Live Map: 7 31 33 34 40 50
Lock Resources: 48850 (439879)
MLEs: 0 (1428625)
  Blocking: 0 (1066000)
  Mastery: 0 (362625)
  Migration: 0 (0)
Lists: Dirty=Empty  Purge=Empty  PendingASTs=Empty  PendingBASTs=Empty
Purge Count: 0  Refs: 1
Dead Node: 12
Recovery Pid: 24543  Master: 7  State: ACTIVE
Recovery Map: 12 32 35
Recovery Node State:
        7 - DONE
        31 - DONE
        33 - DONE
        34 - DONE
        40 - DONE
        50 - DONE

The figure below shows the state of a dlm lock resource that is mastered (owned) by node 25, with 6 locks in the granted queue and node 26 holding the EX (writelock) lock on that resource.

# debugfs.ocfs2 -R "dlm_locks M000000000000000022d63c00000000" /dev/sda1
Lockres: M000000000000000022d63c00000000   Owner: 25    State: 0x0
Last Used: 0      ASTs Reserved: 0    Inflight: 0    Migration Pending: No
Refs: 8    Locks: 6    On Lists: None
Reference Map: 26 27 28 94 95
 Lock-Queue  Node  Level  Conv  Cookie           Refs  AST  BAST  Pending-Action
 Granted     94    NL     -1    94:3169409       2     No   No    None
 Granted     28    NL     -1    28:3213591       2     No   No    None
 Granted     27    NL     -1    27:3216832       2     No   No    None
 Granted     95    NL     -1    95:3178429       2     No   No    None
 Granted     25    NL     -1    25:3513994       2     No   No    None
 Granted     26    EX     -1    26:3512906       2     No   No    None

The figure below shows a lock from the file system perspective. Specifically, it shows a lock that is in the process of being upconverted from a NL to EX. Locks in this state are are referred to in the file system as busy locks and can be listed using the debugfs.ocfs2 command, “fs_locks -B”.

# debugfs.ocfs2 -R "fs_locks -B" /dev/sda1
Lockres: M000000000000000000000b9aba12ec  Mode: No Lock
Flags: Initialized Attached Busy
RO Holders: 0  EX Holders: 0
Pending Action: Convert  Pending Unlock Action: None
Requested Mode: Exclusive  Blocking Mode: No Lock
PR > Gets: 0  Fails: 0    Waits Total: 0us  Max: 0us  Avg: 0ns
EX > Gets: 1  Fails: 0    Waits Total: 544us  Max: 544us  Avg: 544185ns
Disk Refreshes: 1

With this debugging infrastructure in place, users can debug hang issues as follows:

Dump the busy fs locks for all the OCFS2 volumes on the node with hanging processes. If no locks are found, then the problem is not related to O2DLM.
Dump the corresponding dlm lock for all the busy fs locks. Note down the owner (master) of all the locks.
Dump the dlm locks on the master node for each lock.

At this stage, one should note that the hanging node is waiting to get an AST from the master. The master, on the other hand, cannot send the AST until the current holder has down converted that lock, which it will do upon receiving a Blocking AST. However, a node can only down convert if all the lock holders have stopped using that lock. After dumping the dlm lock on the master node, identify the current lock holder and dump both the dlm and fs locks on that node.

The trick here is to see whether the Blocking AST message has been relayed to file system. If not, the problem is in the dlm layer. If it has, then the most common reason would be a lock holder, the count for which is maintained in the fs lock.

At this stage, printing the list of process helps.

$ ps -e -o pid,stat,comm,wchan=WIDE-WCHAN-COLUMN

Make a note of all D state processes. At least one of them is responsible for the hang on the first node.

The challenge then is to figure out why those processes are hanging. Failing that, at least get enough information (like alt-sysrq t output) for the kernel developers to review. What to do next depends on where the process is hanging. If it is waiting for the I/O to complete, the problem could be anywhere in the I/O subsystem, from the block device layer through the drivers to the disk array. If the hang concerns a user lock (flock(2)), the problem could be in the user’s application. A possible solution could be to kill the holder. If the hang is due to tight or fragmented memory, free up some memory by killing non-essential processes.

The thing to note is that the symptom for the problem was on one node but the cause is on another. The issue can only be resolved on the node holding the lock. Sometimes, the best solution will be to reset that node. Once killed, the O2DLM recovery process will clear all locks owned by the dead node and let the cluster continue to operate. As harsh as that sounds, at times it is the only solution. The good news is that, by following the trail, you now have enough information to file a bug and get the real issue resolved.

NFS 导出

OCFS2 volumes can be exported as NFS volumes. This support is limited to NFS version 3, which translates to Linux kernel version 2.4 or later.

If the version of the Linux kernel on the system exporting the volume is older than 2.6.30, then the NFS clients must mount the volumes using the nordirplus mount option. This disables the READDIRPLUS RPC call to workaround a bug in NFSD, detailed in the following link:
http://oss.oracle.com/pipermail/ocfs2-announce/2008-June/000025.html

Users running NFS version 2 can export the volume after having disabled subtree checking (mount option no_subtree_check). Be warned, disabling the check has security implications (documented in the exports(5) man page) that users must evaluate on their own.

文件系统限制

OCFS2对文件系统中文件和目录的总数没有固有限制。通常，它仅受设备大小的限制。
但是当前文件系统有一个限制。它最多可以处理40亿个簇。
簇大小为1MB的文件系统最多可以扩展到4PB，而簇大小为4KB的文件系统可以扩展到16TB。

系统对象

OCFS2文件系统将其内部元数据（包括位图、日志等）存储为系统文件。这些分组在系统目录中。这些文件和目录无法通过文件系统界面访问，但可以使用debugfs.ocfs2工具进行查看。

要列出系统目录（引用为双斜杠），请执行以下操作：

# debugfs.ocfs2 -R "ls -l //" /dev/sde1
        66     drwxr-xr-x  10  0  0         3896 19-Jul-2011 13:36 .
        66     drwxr-xr-x  10  0  0         3896 19-Jul-2011 13:36 ..
        67     -rw-r--r--   1  0  0            0 19-Jul-2011 13:36 bad_blocks
        68     -rw-r--r--   1  0  0      1179648 19-Jul-2011 13:36 global_inode_alloc
        69     -rw-r--r--   1  0  0         4096 19-Jul-2011 14:35 slot_map
        70     -rw-r--r--   1  0  0      1048576 19-Jul-2011 13:36 heartbeat
        71     -rw-r--r--   1  0  0  53686960128 19-Jul-2011 13:36 global_bitmap
        72     drwxr-xr-x   2  0  0         3896 25-Jul-2011 15:05 orphan_dir:0000
        73     drwxr-xr-x   2  0  0         3896 19-Jul-2011 13:36 orphan_dir:0001
        74     -rw-r--r--   1  0  0      8388608 19-Jul-2011 13:36 extent_alloc:0000
        75     -rw-r--r--   1  0  0      8388608 19-Jul-2011 13:36 extent_alloc:0001
        76     -rw-r--r--   1  0  0    121634816 19-Jul-2011 13:36 inode_alloc:0000
        77     -rw-r--r--   1  0  0            0 19-Jul-2011 13:36 inode_alloc:0001
        77     -rw-r--r--   1  0  0    268435456 19-Jul-2011 13:36 journal:0000
        79     -rw-r--r--   1  0  0    268435456 19-Jul-2011 13:37 journal:0001
        80     -rw-r--r--   1  0  0            0 19-Jul-2011 13:36 local_alloc:0000
        81     -rw-r--r--   1  0  0            0 19-Jul-2011 13:36 local_alloc:0001
        82     -rw-r--r--   1  0  0            0 19-Jul-2011 13:36 truncate_log:0000
        83     -rw-r--r--   1  0  0            0 19-Jul-2011 13:36 truncate_log:0001

以数字结尾的文件名是特定于节点插槽的，称为本地节点系统文件。节点使用的节点本地文件集可以从插槽映射中确定。列出节点插槽映射：

# debugfs.ocfs2 -R "slotmap" /dev/sde1
    Slot#    Node#
        0       32
        1       35
        2       40
        3       31
        4       34
        5       33

更多信息，请参考 http://oss.oracle.com/projects/ocfs2 上，”Documentation”部分中的OCFS2支持指南。

心跳、Quorum和圈离

心跳是任何集群中的必不可少部分。它负责精确地将节点指定为已死亡或存活。此处有错，可能导致集群挂起或损坏。

o2hb是o2cb的磁盘心跳组件。它会定期更新磁盘上的时间戳，从而向其他人指示此节点处于存活状态。它还会读取所有时间戳以标识其他活动节点。其他集群组件（例如o2dlm和o2net）使用o2hb服务获取节点启动和关停事件。

Quorum是集群中允许在共享存储上操作的节点组。当集群出现故障时，节点可分割为多个组，这些组可以在其组中通信，以及与共享存储进行通信，但不能在组之间进行通信。o2quo确定哪个组可以继续，并启动其他组的圈拦隔离。

圈离是从集群中强制删除节点的行为。当挂载了OCFS2的节点意识到其在一个已降级的集群中不满足Quorum时，将对自身进行圈拦隔离。这样做是为了避免其他节点尝试访问其资源而卡住。

o2cb使用机器重置(Machine Reset)进行圈离。这是节点重新加入集群的最快路线。

进程

[o2net]

每节点一个。它是工作队列线程，在群集联机时启动，在群集脱机时停止。它处理所有挂载的网络通信。它从O2HB获取存活节点列表，并与每个活动节点建立TCP/IP通信通道。它发送常规的keep-alive数据包以检测通道上的任何中断。

[user_dlm]

每节点一个。它是工作队列线程，在加载dlmfs时启动，卸载时停止（dlmfs是一个合成文件系统，允许用户空间进程访问in-kernel的dlm）。

[ocfs2_wq]

每节点一个。它是工作队列线程，在加载OCFS2模块时启动，卸载时停止。为它分配了后台文件系统任务，这些任务可能需要集群锁，例如刷新截断日志，孤儿目录恢复和本地分配恢复。例如，孤儿目录恢复会在后台运行，因此它不影响恢复时间。

[o2hb-14C29A7392]

One per heartbeat device. It is a kernel thread started when the heartbeat region is populated in configfs and stopped when it is removed. It writes every two seconds to a block in the heartbeat region, indicating that this node is alive. It also reads the region to maintain a map of live nodes. It notifies subscribers like o2net and o2dlm of any changes in the live node map.

[ocfs2dc]

One per mount. It is a kernel thread started when a volume is mounted and stopped when it is unmounted. It downgrades locks in response to blocking ASTs (BASTs) requested by other nodes.

[jbd2/sdf1-97]

One per mount. It is part of JBD2, which OCFS2 uses for journaling.

[ocfs2cmt]

One per mount. It is a kernel thread started when a volume is mounted and stopped when it is unmounted. It works with kjournald2.

[ocfs2rec]

It is started whenever a node has to be recovered. This thread performs file system recovery by replaying the journal of the dead node. It is scheduled to run after dlm recovery has com‐
pleted.

[dlm_thread]

One per dlm domain. It is a kernel thread started when a dlm domain is created and stopped when it is destroyed. This thread sends ASTs and blocking ASTs in response to lock level convert
requests. It also frees unused lock resources.

[dlm_reco_thread]

One per dlm domain. It is a kernel thread that handles dlm recovery when another node dies. If this node is the dlm recovery master, it re-masters every lock resource owned by the dead node.

[dlm_wq]

One per dlm domain. It is a work-queue thread that o2dlm uses to queue blocking tasks.

未来的工作

文件系统开发是一个永无止境的循环。更快、更大的磁盘，更快、更多的处理器数量，更大的缓存等，这些都在不断改变性能的最佳点，这迫使开发人员重新考虑长期以来的信念。加上新的使用场景，也迫使开发人员在提供与现有语义无缝融合的解决方案方面进行创新。

目前，我们正在寻求添加透明压缩、透明加密、延迟分配、多设备支持等功能，以及致力于提高新一代机器的性能。

如果您有兴趣贡献，请给开发团队发电子邮件：[email protected]。

致谢

The principal developers of the OCFS2 file system, its tools and the O2CB cluster stack, are Joel Becker, Zach Brown, Mark Fasheh, Jan Kara, Kurt Hackel, Tao Ma, Sunil Mushran, Tiger Yang and Tristan Ye.

Other developers who have contributed to the file system via bug fixes, testing, etc. are Wim Coekaerts, Srinivas Eeda, Coly Li, Jeff Mahoney, Marcos Matsunaga, Goldwyn Rodrigues, Manish Singh and Wengang Wang.

The members of the Linux Cluster community including Andrew Beekhof, Lars Marowsky-Bree, Fabio Massimo Di Nitto and David Teigland.

The members of the Linux File system community including Christoph Hellwig and Chris Mason.

The corporations that have contributed resources for this project including Oracle, SUSE Labs, EMC, Emulex, HP, IBM, Intel and Network Appliance.

另参阅

debugfs.ocfs2(8) fsck.ocfs2(8) fsck.ocfs2.checks(8) mkfs.ocfs2(8) mount.ocfs2(8) mounted.ocfs2(8) o2cluster(8) o2image(8) o2info(1) o2cb(7) o2cb(8) o2cb.sysconfig(5) o2hbmonitor(8) ocfs2.cluster.conf(5) tunefs.ocfs2(8)

作者

Oracle Corporation

版权

版本 1.8.6，2012年01月