ext3日志记录选项和写等待时间

December 27th, 2007

来源: IBM developerworks 通用线程: 高级文件系统实现者指南，第 8 部分

在安装文件系统时，Ext3 允许您从三种数据日志记录方式中选择一个： data=writeback 、 data=ordered 和 data=journal 。

要指定日志方式，可以向 /etc/fstab 的选项节添加适当的字符串（例如 data=journal ），也可以在调用 mount 时直接指定 -o data=journal 命令行选项。如果您愿意指定用于根文件系统的数据日志记录方法（ data=ordered 是缺省值），则可以使用名为 rootflags 的特殊内核引导选项。因此，如果愿意将根文件系统置于完整数据日志记录方式下，则向内核引导选项添加 rootflags=data=journal 。

data=writeback 方式

处于 data=writeback 方式下，ext3 根本不执行任何形式的数据日志记录，提供给您的是和在 XFS、JFS 和 ReiserFS 文件系统中找到的类似的日志记录（仅元数据）。正如我在前一篇文章中讲到过，这会让最近修改的文件在出现意外的重新引导事件中被毁坏。如果不考虑这个缺点， data=writeback 方式在大多数情况下应该能够为您提供最佳的 ext3 性能。

data=ordered 方式

处于 data=ordered 方式下，ext3 只是正式记录元数据，而在逻辑上将元数据和数据块分组到称为事务的单个单元中。到了将新的元数据写到磁盘上的时候，首先写的是相关的数据块。 data=ordered 方式有效地解决了在 data=writeback 方式 下和大多数其它日志记录文件系统中发现的毁坏问题，而这是在不需要完整数据日志记录的情况下做到的。一般说来， data=ordered ext3 文件系统执行的速度比 data=writeback 文件系统执行的速度稍微慢一些，但比对应的完整数据日志记录还是要快出许多。

将数据附加到文件时， data=ordered 方式提供了 ext3 完整数据日志记录方式提供的所有完整性保证。不过，如果正在覆盖某一部分文件，而此时系统崩溃，那么有可能所写的区将包含原始块和在其中散布了更新块的组合。这是因为 data=ordered 不提供首先覆盖哪一个数据块的保证，因此不能假设只是因为更新了被覆盖的块 x，也就更新了被覆盖的块 x-1。 data=ordered 让写操作顺序由硬盘的写高速缓存决定。一般说来，这个限制并不经常对人们具有负面影响，因为附加的文件一般比覆盖的文件更普遍。出于这个原因， data=ordered 方式是对完整数据日志记录的一个很好的更高性能的替代。

data=journal 方式

data=journal 方式提供了完整数据和元数据日志记录。所有新数据首先写入日志，然后再写入它的最终位置。在崩溃情况下，可以重放日志，使数据和元数据处于一致的状态。

从理论上说， data=journal 方式是所有日志记录方式中最慢的，因为要将数据写入磁盘两次而不是一次。不过，在某些情况下， data=journal 方式也可以是极快的。Andrew Morton 在听取了有关 LKML 的报告（ext3 data=journal 文件系统为人们提供了难以置信的出色的交互式文件系统性能）后，决定组合出一个小测试。首先，他创建了一个简单的 shell 脚本，该脚本设计用来将数据尽快写入测试文件系统：
快速写

while true do     dd if=/dev/zero of=largefile bs=16384 count=131072 done

在将数据写入测试文件系统的同时，他尝试从 位于同一磁盘上的另一个 ext2 文件系统中读取 16Mb 的数据，并对此进行计时：
读取 16Mb 的文件

time cat 16-meg-file > /dev/null

结果让人惊奇。 data=journal 方式允许 16 兆文件以比其它 ext3 方式、ReiserFS，甚至 ext2（没有日志记录开销）高出 9 到 13 倍的速度读取：

写入文件系统

16 兆读取时间（秒）

Andrew 重复这个测试，但尝试从测试文件系统（而不是从其它文件系统）读取 16Mb 的文件，获得的结果是相同的。那么，这意味着什么呢？不知什么原因，ext3 的 data=journal 方式非常适合于需要同时从磁盘读写数据的情况。因此，ext3 的 data=journal 方式（被认为在几乎所有情况中是所有 ext3 方式中最慢的）实际上证明在需要最大化交互式 IO 性能的繁忙环境中具有重要的性能优势。可能 data=journal 方式毕竟没那么缓慢！

Andrew 仍然在尝试发现究竟为什么 data=journal 方式比其它方式好这么多。在这样做的同时，他也许能够对 ext3 的另外两种方式做必要调整，以便也能看到 data=writeback 和 data=ordered 方式的好处。

对 data=journal 的调整

有些人在繁忙的服务器上 - 特别是在繁忙的 NFS 服务器上 - 使用 ext3 的 data=journal 方式时曾经碰到一个特殊的性能问题。每隔 30 秒，服务器就会遇到磁盘写活动高峰，导致系统几乎陷于停顿。如果您遇到这个问题，修复它很容易。只要以 root 用户输入以下命令，就可以调整 Linux”脏”缓冲区刷新算法：
调整 bdflush

echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush

这些新的 bdflush 设置将导致 kupdate 每隔 0.6 秒而不是每隔 5 秒运行。另外，它们告诉内核每隔 3 秒而不是 30 秒（缺省值）刷新”脏”缓冲区。通过更有规律地将最近修改的数据刷新到磁盘，可以避免这些写操作的高峰。以这种方式执行的效率比较低，因为内核不太有机会组合写操作。但对于繁忙的服务器，写操作将更一致地进行，并将极大地改进交互式性能。

Last modified at: Thursday, December 27th, 2007 05:47:27 pm
Trackback URL: http://blog.zhangjianfeng.com/article/708/trackback

给本文打分: 1 Star