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

runsnake

通用线程: 高级文件系统实现者指南，第 8 部分
我实话实说。我本来计划用这篇文章向您展示如何在系统上设置和运行
ext3。尽管我这么说，但我并不打算这么做。Andrew Morton
那个很棒的“在 2.4 内核中使用 ext3
文件系统”页面已经很好地解释了如何在系统上启用
ext3，因此我没必要在这里重复所有基本概念。而是深入钻研某些更耐人寻味的
ext3
主题，我认为您会发现这些主题非常有用。阅读了这篇文章后，当您准备设置和运行
ext3 时，请参考 Andrew 的页面。
      
      
      
      
2.4 内核更新
      
      
首先，让我们从 2.4 内核更新开始。我在介绍 ReiserFS 时最后讨论到 2.4
内核稳定性。在那个时候，要找到一个稳定的 2.4
内核是个难题，我建议坚持使用已知的内核（那时最前沿的是 2.4.4-ac9
内核）― 特别对于计划在生产环境中使用 ReiserFS
文件系统的那些人。您可能猜到，自从 2.4.4-ac9
以来发生了许多事，而现在无疑是着眼于更新的内核的时候了。
      
      
随着内核 2.4.10 的出现，在性能和可伸缩性方面，2.4
系列达到了新的层次（这是我们盼望已久的）。那么，是什么碰巧让 Linux
2.4 最终成长起来的呢？用首字母缩写词表示，就是 VM。在认识到 2.4
系列表现不是非常出色后，Linus 去除了 Linux 有问题的 VM 代码，并用
Andrea Archangeli 开发的简单而普通的 VM 实现来替代。Andrea 的新 VM
实现（最先出现在 2.4.10
中）非常了不起；它真正提高了内核速度，并使整个系统反应更迅速。2.4.10
绝对是 2.4 Linux
内核开发中一个主要的转折点；到那时为止，事物还不是非常完美，我们当中有许多人都奇怪为什么自己不是
FreeBSD 开发人员。我们都应该感谢 Linus 在 2.4
稳定内核系列中所做的这些主要（但迫切需要）的更改。这的确是一件了不起的事。
      
      
因为 Andrea 的新 VM
代码需要一些时间才能与内核其余部分达到无缝集成，所以使用
2.4.13+。使用 2.4.16+ 会更好，因为稳固的 ext3
文件系统代码最终是集成到从 2.4.15-pre2 发行版开始的正式 Linus
内核中的。没有理由避免使用 2.4.16+ 内核，它能使设置和运行 ext3
的工作更为轻松。如果确实使用 2.4.16+ 内核，记住不再需要象 Andrew
的页面上所描述的那样应用 ext3 补丁了。Linus 已经为您添加了它 :)
      
      
      
      
您会注意到我建议使用 2.4.16+ 而非
2.4.15+，这是有充分理由的。随着内核 2.4.15-pre9
的发行，给内核引入一个非常讨厌的文件系统崩溃错误。直到 2.4.16-pre1
才发现并解决了这个问题，导致人们应该不计任何代价地避免使用这两个发行版之间的内核（包括
2.4.15）。选择 2.4.16+ 内核可以让您完全避免这个错误的批处理。
      
      



膝上电脑……小心？
      
      
Ext3
是一种稳固的文件系统，这个好名声由来已久，因此我在知道有相当多的膝上电脑用户在切换到
ext3
时有文件系统崩溃问题时很诧异。一般来说，对这些类型的报告做出的反映往往是完全避免使用
ext3；不过，在到处打听之后，我发现人们所遇到的磁盘崩溃问题与 ext3
本身并没有关系，而是由某些膝上电脑硬盘所引起的。
      
      
写高速缓存
      
      
您可能不知道，但大多数新式硬盘有一个称为“写高速缓存”的东西，硬盘使用它来收集暂时被挂起的写操作。通过将暂挂的写操作放到高速缓存中，硬盘固件就可
以重新为它们排序，并为它们分组，以便用尽可能最快的方式将它们写到磁盘中。通常认为写高速缓存是个非常好的事物（请阅读 Linus
对写高速缓存的解释和看法）。
      
      
      
      
不幸的是，现在市场上某些膝上电脑的硬盘具有这样一种不可靠的特性，即忽略将它们的写高速缓存刷新到磁盘上的所有正式
ATA 请求。虽然直到最近 ATA
规范
        
        还允许这种做法，但这并不是一种完美的设计特性。使用这些类型的驱动器，内核无法保证某一特定块实际上是否被记录到磁盘上。尽管听上去这是个棘手的问题，但这个特定问题本身可能不是人们所遇到的数据毁坏问题的原因。
      
      
      
      
不过，情况越来越差。一些新式膝上电脑的硬盘有一个更令人讨厌的习惯：每当重新引导或暂挂系统，就
        
        
丢弃它们的写高速缓存。很明显，如果硬盘有这两个问题，就会定期破坏数据，而
Linux 对于防止这种情况束手无策。
      
      
      
      
那么，解决方案是什么呢？如果您有膝上电脑，请小心使用。在对文件系统执行任何重大更改之前备份所有重要文件。如果遇到似乎符合上面我所描述的模式的数据毁坏问题，特别在使用
ext3
时，记住这可能是您膝上电脑硬盘的错。在这种情况下，您需要与膝上电脑制造商联系，并询问更换驱动器事宜。希望在几个月后，这些脆弱的硬盘将从市场上消失，我们就再也不必担心这个问题了。
      
      
既然我已经警告过您要小心，就让我们看看 ext3
的各种数据日志记录选项。
      
      





日志记录选项和写等待时间
      
      
在安装文件系统时，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 兆读取时间（秒）
         
          ext278ReiserFS67ext3
            
            data=ordered
         
          93ext3
            
            data=writeback
         
          74ext3
            
            data=journal
         
         
            
            7
         
         
      
      
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
秒（缺省值）刷新“脏”缓冲区。通过更有规律地将最近修改的数据刷新到磁盘，可以避免这些写操作的高峰。以这种方式执行的效率比较低，因为内核不太有机会组合写操作。但对于繁忙的服务器，写操作将更一致地进行，并将极大地改进交互式性能。
      
      



结束语
      
      
现在，我们已经结束了 ext3
的报道。敬请期待我的下一篇文章，因为我们将要研究……XFS
的许多奇妙之处！
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/9465/showart_161509.html