概述
前文已经大概介绍过OCFS2的部署和应用场景，本文及后续文章重点介绍OCFS2文件系统的具体实现。为了便于后续代码的理解，本文首先介绍一下该文件系统关键数据的磁盘布局情况。理解磁盘布局是理解OCFS2文件系统的基础，只有理解了布局，才能更好的理解代码中的各种处理流程。
本文介绍基于Linux4.1.12内核，其它版本内核可能稍有不同，但不影响理解。
本文示例文件系统格式化采用默认参数，也即4K逻辑块大小和128K簇块大小
本文首先介绍文件系统在整个磁盘的布局情况，然后介绍文件夹内数据和文件内数据的布局。整体原则是从整体到局部，从轮廓到细节的顺序。
整体磁盘布局
整体布局主要介绍OCFS2文件系统如何实现对整个磁盘的管理。如下图OCFS2文件系统与Ext4文件系统类似，将磁盘划分为若干组进行管理，Ext4文件系统叫块组（block group），这里成为簇组（cluster group），虽然概念不同，但大体用途基本一致。如果不了解Ext4文件系统也没有关系，下图能很清楚的说明磁盘的整体布局情况。如图所示最上面方框（第一行方框）表示的是簇组（cluster group），分别是Cluster Group0、Cluster Group1等等。对于文件系统将磁盘划分为簇组（可以简单理解为组）类似于超时将一层楼的空间划分为若干个货架来摆放货物，而不是堆到一起。通过货架来摆放物品明显可以提高货物查找的便捷性。
如上图所示除了第一个簇组（Cluster Group0）比较特殊之外，其它簇组都是一样的，也就是最前面一个块是簇组描述信息，其后为数据簇（Cluster），也就是被管理的单元。第一个簇组特殊的原因是其中包含了很多元数据（管理数据），包括文件系统的超级块、系统文件夹和系统文件等内容，但管理的原理是一致的。
OCFS2在管理磁盘空间时同时采用两种管理单元，一种叫做逻辑块，大小范围从512B到4K，大小必需是512B的2的幂整数倍（也即512B、1K等以此类推）；另外一种叫簇组，大小范围是4KB到1MB，大小必需是4KB的2的幂整数倍。
如下图行所示为管理磁盘空间的基本原理。在簇组的最前面有一个簇组描述信息，其中一部分是位图（Bitmap），位图的每一位（Bit）与该空间的一个簇对应，如果对应的位为1，则标明相应的簇已经分配出去了，如果为0则说明没有被使用。因此文件系统可以根据位图中的相应位来确认那些簇是可以使用的。
前文已述，OCFS2第一个簇组（Cluster Group0）相对特殊，主要是包含很多元数据。如图1所示，主要包含如下几部分内容：
预留块：在磁盘最开始的2个逻辑块为预留块，这个主要是为了与第一版本（OCFS）进行区分，因为两者是完全不兼容的。簇组描述符：簇组描述符是一个数据结构，里面包含描述簇组的所有信息，包含该簇组的使用情况、可用位的数量和本描述的偏移等等信息。数据簇：实际存储数据的部分
了解了这些基本概念之后，还有一个问题没有解决。那就是簇组的大小是如何确定的呢？前文我们已经知道簇组通过其前面的簇组描述符进行管理，而该描述符默认占用一个块（4K）的空间，而该描述符前面基本描述信息占了64B，因此位图剩余的可用空间为4032(4096-64)B，也就是大3225位（Bit），因此最多可以管理32256个簇，也即4032M（32256*128KB）。
另外，OCFS2还有一个本地管理的概念，由于OCFS2是集群文件系统，为了保证各个节点的协同，必然需要一种跨节点的网络锁（分布式锁），这样势必造成文件系统整体性能的下降。因此OCFS2在设计的时候增加了一个本地分配的功能，其基本原理是预先占用全局分配中的一块区域，然后在本节点内独自对该空间进行管理。
对于本地分配的最大管理空间，由于使用的ocfs2_dinode进行管理（后面详述原理），也是占用1个块（4K），前面描述信息占用了208B，因此剩余的空间可以管理的最大空间为3888M。上文是以128K簇为例描述的，不同簇大小，簇组大小和本地分配的最大空间会有相应的变化，具体如下表所示。
| cluster size | group size | local alloc |
|---|---|---|
| 4K | 126M | 121M |
| 8K | 252M | 243M |
| 16K | 504M | 486M |
| 32K | 1008M | 972M |
| 64K | 2016M | 1944M |
| 128K | 4032M | 3888M |
| 256K | 8064M | 7776M |
| 512K | 16128M | 15552M |
| 1024K | 32256M | 31104M |
磁盘空间的管理
上面一节主要描述了OCFS2文件系统关于磁盘布局的基本内容及涉及的几个关键概念。本节将介绍一下该文件系统是如何对磁盘空间进行管理的。OCFS2比较特殊的地方在于，其都是通过inode进行管理的，每种不同的资源有不同的inode。在该文件系统中有一个用户看不到的文件夹，这里成为系统文件夹，其中存储这管理用的inode，也就是本文件系统的基本元数据。具体如表所示，本表不是全量，选择几个关键的inode进行介绍。
| inode编号 | 名称 | 描述 |
|---|---|---|
| 65 | 根目录 | 这个是本文件系统的根目录，文件系统挂载后呈现给用户的根目录 |
| 66 | 系统目录 | 本文件系统的管理目录，这个目录对用户不可见，用于实现对磁盘空间的管理 |
| 68 | global_inode_alloc | 系统inode分配管理的inode，也就是该inode用于管理系统inode分配和回收 |
| 71 | global_bitmap | 全局位图，用于实现对簇组簇的全局管理，访问时需要通过分布式锁进行保护 |
| 80 | extent_alloc:0000 | 元数据分配，带有0000是集群节点相关的，具体数量与槽位数相同，例如0000,0001等 |
| 88 | inode_alloc:0000 | 用于本地inode的分配管理，这个是用户的inode |
| 104 | local_alloc:0000 | 该inode用于实现本地磁盘空间的管理 |
文件夹数据
本文首先介绍文件夹是因为文件系统挂载后，首先呈现给用户的就是一个文件夹。挂载成功后，用户可以在其上创建文件，写读数据。文件名称和子文件夹其实就是文件夹内的数据，因此首先介绍文件夹的数据布局。
文件夹中数据的存储有两种模式，如果开启了inline-data特性，那么起始情况下这些数据（文件名称和inode等信息）是存放在文件夹的inode的所在的区域内的。由于一个inode默认情况下占用4K的空间，因此对于文件数量不太多的文件夹，通过这块区域就可以存储，不需要额外申请空间。如果在文件夹中有海量文件的情况下，inode节点空间不足以存储这些信息，此时就会通过extent的方式存储这些数据。另外，为了便于文件夹内文件的检索，OCFS2有实现了一个索引树，可以通过该索引树快速检索文件。
inline模式
inline模式比较简单，数据就存储在inode的内部，其位置是通过inode成员遍历id2确定。该成员是一个联合体，在不同的场景下类型不同，在文件夹inline模式下为一个ocfs2_inline_data的结构体，具体如图所示。
id2对象内部成员id_count表示该文件夹内部项目的数量，id_data指向具体存储文件夹内部项目的信息。具体项目是通过一个名为ocfs2_dir_entry的结构体描述的。文件夹内部的这些项目线性的排布在id_data分配的存储空间中。如图是文件夹内部项目排布示意图和ocfs2_dir_entry结构体定义。这里需要重点说明的是ocfs2_dir_entry的rec_len成员，这里记录了该结构体的长度，这样根据起始位置id_data和前一个成员的长度，就能找到下一个成员的位置，也即进行项目的遍历。
extent模式
在extent模式则相对复杂一些，该种模式下extent其实是以B+树的方式存储文件夹内部的数据的。关于B+树的概念超出了本文的范围，具体实现请参考其它文章，本文仅仅介绍该种场景下文件夹数据的布局情况。如前文所示，不同的模式下inode的id2成员的类型不同，在extent模式下，该成员为ocfs2_extent_list类型的结构体。此时该inode的结构体定义如图所示。
对于文件夹数据所组成的B+树，是以ocfs2_dinode为根的一颗树，如下图灰色虚线指示的为树的父子节点之间的关系。红色虚线指示的是对结构体的进一步细化。本例中为B+树的高度为2，其中树根指向下一级节点，该级节点全部为叶子节点。叶子节点中有相关的记录项，记录了逻辑位置与磁盘物理位置的关系，而此时物理块的 数据就是目录项。实际情况可能树高可能为1，此时inode中的id2成员中的数据记录了逻辑位置与磁盘物理位置的关系。也可能树高更改，此时中间层存储的映射到的物理块并不是存储目录项的内容，而是进一步的映射关系。
在extent模式下一共涉及4种数据结构，分别是ocfs2_inode、ocfs2_extent_block、ocfs2_extent_list和ocfs2_extent_rec。其中ocfs2_extent_list是树中一个节点维护记录列表的数据结构，其中l_recs成员是一个ocfs2_extent_rec类型的数组，每一项记录了一个映射关系（逻辑地址到磁盘物理地址）。ocfs2_extent_block结构体可以理解为B+树非根节点的描述，其中也包含一个ocfs2_extent_list类型的成员，通过其内部的记录可以指向下一级节点（非叶子节点场景），或者其本身就可以指向存储文件夹数据的磁盘块（叶子节点场景）。
文件内数据
文件内数据的存储方式与文件夹类似，也存在这两种模式。文件的数据布局的基本原理与文件夹是一样的，差异是其中存储的是文件的具体数据。具体实现可以阅读代码，本文不在赘述。
关注作者微信公众号，更及时的获取原创IT技术文章。
