深入理解Lustre文件系统-第12篇 Lustre磁盘文件系统：ldiskfs

关注

翻译最新推荐文章于 2026-06-09 12:36:15 发布 5.3k 阅读 AI 写同款· GEO 优化 ›

ldiskfs（有些时候被错误地称为Linux ext4文件系统）是对Linux ext3文件系统的打了很多补丁的一个版本，由Sun Microsystems公司开发和维护。ldiskfs是Linux ext3和ext4文件系统的超集。现在它只被Lustre文件系统用在服务器端，作为底层的本地文件系统。本节给出了对ldiskfs机器与ext3文件系统不同之处的简要介绍。

就各自的I/O路径而言，ext3和ldiskfs文件系统的不同之处如下所示：

在ldiskfs里，分配/块查找是在索引节点锁取得后就预先完成了，而随后在I/O提交到磁盘的过程中，索引节点锁就被丢弃了。这极大地提高了I/O的并发性，因为索引节点只被锁了很短的一段时间。

在ldiskfs中，分配是对整个RPC（1MB，或者换句话说，256×4KB块）一次性完成的，而不是像VFS所做的那样4KB一次。这个减少了许多重复搜索位图的开销，同时允许了更有效的extent查找。

在ldiskfs中，现在写入是完全和客户端同步的（知道数据和元数据写入磁盘上才回复），但是这一点正在改变。在新开发的“异步提交”路径里，对任何事务，将在数据提交到磁盘后，在元数据提交之前，回复客户端。另外新的ROC（1.8）将在把写入页放入磁盘之前，放入告诉缓冲，为OSS端完全异步的写作准备。

在Ldiskfs中，当前，日志刷新是在每个写RPC后强制执行的。

在ldiskfs中，和任意其他将被Lustre服务器使用的底层文件系统一样，下面列出的策略将影响IO路径。

客户端控制的：正在发送中的RPC，RPC大小和每个OST的缓冲的脏数据。为了减少readmodify-write（？）操作，RPC大小最好是底层RAID分条大小的倍数。同时，RPC大小×正在发送中的RPC数×客户端总数，将需要考虑到连接的带宽和底层块设备的带宽，以避免大延迟和在竞争点的请求堆积。

服务器控制的：IO线程数。当前，这个量限制了任意时刻后端设备的I/O量。

分条策略。它决定了对一给定文件，有多少OST参与I/O。

12.1 内核补丁

ldiskfs和Lustre有赖于一组Linux内核补丁，它们不仅在ext3上添加了新的特性，而且提高了性能。下面的列表给出了一些对ldiskfs必要的内核补丁，虽然它们中的一些可能对特定使用实例并不必要（例如sd_iostats）。

jbd-2.6.10-jcberr.patch：日志回调补丁，允许在数据至少提交到日志中时，以last_committed回复客户端。这也意味这数据可以在脱离客户端支持的情况下从本地文件系统中恢复。

jbd-stats-2.6-sles10.patch：提供了关于事务大小、时间等数据。

iopen-misc-2.6.12.patch：为getattr-by-fid和恢复提供了open-by-inode。

dev_read_only-2.6-fc5.patch：为测试和在不阻塞在正在进行中的I/O的基础上进行OST/MDT的failback，放弃对块设备的写入。

sd_iostats-2.6-rhel5.patch：提供可选的SCSI设备数据。

blkdev_tunables-2.6-sles10.patch：允许通过快层提交更大的I/O。

i_filter_data.patch：允许从内存中的索引节点连到MDS/OSS数据。

quota-fix-oops-in-invalidate_dquots.patch：修补上游内核限额源码的bug。这个bug已经在2.6.17内核中修补好了。

jbd-journal-chksum-2.6-sles10.patch：提供了日志事务校验码以检测磁盘毁坏。

1.2 补丁：ext3到ldiskfs

除了上述列出来的补丁外，ldiskfs还需要一些对ext3源码上所做的，用于增加性能和功能的补丁。下面的列表给出了ldiskfs文件系统所需的补丁。

ext3-wantedi-2.6-rhel4.patch：允许了通过号码来创建特定索引节点，用于恢复。假设客户端的进行了一个打开/创建，并且得到了来自服务器的带有特定索引节点号的回复。让我们假设此时，服务器崩溃了，然而创建还没有反映到磁盘上去，所以该信息丢失了。在服务器重启并进入恢复后，客户端重新连接上，并再次发送它的打开/创建请求，其中给定了上次由服务器传达的索引节点号。在Lustre 2.0中，这个过程将不需要了，因为那是使用的将是另外一组Lustre 索引节点号而不是对应实际的磁盘上的索引节点号。在服务器端提供的由Lustre 索引节点号到实际盘上索引节点号将消除对这个补丁的依赖。 iopen-2.6-fc5.patch：允许了通过号码查找索引节点。一般，查找文件需要全路径，但是Lustre在它的协议里没有这个功能。当查找时，只有父索引节点号和孩子名，正常情况下，这就够了。但是如果Lustre处于恢复模式，所有先前的查找步骤都丢失了，Lustre需要一个找到父索引节点号的方法。这个补丁提供了这个功能。这各问题在ext3中不存在，因为文件系统是本地的，在崩溃的时候，所有东西都挂了，而在恢复（或者重启）的时候，所有的查找功能从根文件开始。

ext3-map_inode_page-2.6-suse.patch：为快读/写操作稍后进行的I/O提交分配数据块。这个补丁创建了一个API，可以用来map Lustrefsfilt层的inode_page函数。Lustre需要这个补丁，因为它预先分配块，提高了元数据性能。

接着五个补丁可以分为一组，因为它们于ext3文件系统之上提供了extent格式的能力。他们也在Linux ext4文件系统中使用。ext3文件系统按照块来寻址文件，每块在索引节点里有4字节的记录，里面记录了指明实际数据存储位置的块号。对于长文件，这导致了在索引节点中存储了许多块信息，这是非常低效的。而extent概念定义了分配给大文件使用的，作为单一实体的一个块区间。块区间里块的最大为128MB。这是由于每128MB就有一个块保存了下个128MB的配给位图。这个情况的唯一例外是空洞（hole），一个空洞，不管它有多大，可以以一个extent来标识。对于包含下列补丁的Lustre中的一个非常大的文件，它将会有多个extent，每个extent大小是128MB减去4KB，其中4KB用来存储位图，此位图用来映射大小为128MB 的extent组。extent概念提高了性能，因为：它不仅减少了分配时间，而且，例如，在unlink文件的时候，只需要提供关于该文件的，用来确定extent的信息。

ext3-extents-2.6.16-sles10.patch:

ext3-extents-fixes-2.6.9-rhel4.patch:

ext3-extents-multiblock-directio-2.6.9-rhel4.patch:

ext3-extents-search-2.6.9-rhel4.patch:

ext3-extents-sanity-checks.patch:

接下来两个补丁为ldiskfs文件系统提供了一个多块（multi-block，mballoc）分配者。它们也用在Linux ext4文件系统中。此时需要澄清的是，extent和mballoc分配时完全无关的。当分配一个extent时，会分配一组连续的块。让我们假设这个extent的第一个块开始于x，而最后一个块石x+y。下一个将要分配给同一个文件的extent可能是也可能不是以x+y+1开始，但是在任意一种情况下，新快将会分配为一组连续的块。这样，当寻址这两组可能不相邻的磁盘块时，我们需要提供他们的extent信息，而不是对它们一个块一个块地寻址。mballoc则是用一次调研分配所需数量的（很有可能连续的）块。

ext3-mballoc3-core.patch:

ext3-mballoc3-sles10.patch:

ext3-nlinks-2.6.9.patch：允许在一个给定目录下创建超过32,000个子目录。这是通过在i_nlink（15比特）溢出时（如果子目录大于32,000个），设置它为1的方法实现的（也用在Linux ext4文件系统里）。

ext3-ialloc-2.6.patch：为避开满载的组（即跳过满载的组），改变了OST的索引节点分配策略。在每个索引节点组的开始，有一个位图，表明哪些组被完全用光了，哪些组被部分使用了，哪些组是空闲的。超级块包含一些关于在不同的索引节点组中有多少索引节点空闲的信息。这个补丁给出一个索引节点组的信息：在该组里面是否有空闲索引节点，而不要完整扫描这个组。