文件系统更新

loughsky

在浏览过去的文章时，我突然发现，“高级文件系统实现者指南”系列文章从出现到现在已经近一年了！别担心，等我介绍了 IBM 用于 Linux 系统的 JFS 和 EVMS（企业卷管理，enterprise volume management）技术，这一系列文章就 快要结束了。但由于这是 IBM 的一个站点，我想在我介绍完其它全部用于 Linux 文件系统的新技术 之后，最好能再介绍一下由 IBM 开发的技术。
在我们开始 JFS 和 EVMS 之前，我要同您谈谈官方对 Linux 文件系统领域所发生的事情的当前状况所做的最新表述。我们遇到过许多 2.4 内核；其中一些很好，另外一些就没那么好。伴随着内核的开发进程，XFS、ext3 和 ReiserFS 的开发正紧锣密鼓地进行。在此期间，许多
Gentoo Linux
用户使用 XFS、ext3 和 ReiserFS 文件系统的不同组合得出了各种各样的结果。一般来说，不管 Gentoo Linux 用户在使用哪个新出现的文件系统时遇到了问题，我肯定会听说那个问题。那么，哪些文件系统最受欢迎？哪些又最可靠呢？在这篇文章中，我会与您分享我的经验，以及来自 ReiserFS、ext3 和 XFS 开发团队的反馈和状况的更新。
XFS 有什么新鲜事吗？
在过去的几个月中，选择 XFS 作为 Linux 文件系统成为一件很流行的事。根据来自 Gentoo Linux 用户的反馈，人们之所以喜欢是因为它具有健壮的功能集，而且一般情况下，它的整体性能良好。不过，XFS 的 1.0.x 发行版有一个严重的问题。您也许还记得，如果更新的是文件的元数据，但是某种不可预知的情况（如崩溃）导致无法将新数据写到磁盘上，那么象 XFS 和 ReiserFS 这样的“只支持元数据”的日志文件系统就会引起数据破坏。对于 ReiserFS，受影响的文件会包含受损的或无用的数据块，而对于 XFS，该文件会包含整块的二进制零。事实证明，如果您的服务器碰巧崩溃或者意外断电，XFS 1.0.x 有一种很不好的倾向，那就是会破坏最近修改过的文件。那些刚好在承受力较强的服务器上使用 XFS 的人一般都没问题，但那些在遇到某种软件或硬件稳定性问题的系统上运行 XFS 的人就面临着丢失很多数据的风险。
幸运的是，SGI XFS 的开发人员在 XFS 1.1 中大大减少了这个问题的出现次数。这个问题之所以在 XFS 1.0 中更加频繁的发生，原因在于对某类元数据的更新 必须按照其发生的顺序记录到文件系统中。这些按照顺序的元数据更新（被称为“同步”元数据更新）同样有将所有以前还没更新到磁盘上的元数据都刷新的效果。问题就出在这儿。如果这些早先的元数据刷新中也有一些相应的数据块需要被刷新，那么很可能在元数据被记录之后的半分钟内新的数据块仍然没有被写到磁盘上去。这就给发生数据丢失创造了一个很大的漏洞。

技术说明
对于 XFS 1.1，文件系统的元数据只在两种情况下会同步（有序）更新：

• 如果文件系统需要分配空间，并且有一个紧随的事务来释放同一块空间
  
• 在 XFS 处理用 O_SYNC （同步）选项打开的文件事务的时候；在这种情况下，对这个文件进行写操作将会使得文件系统对元数据所做的其它任何紧随其后的更改被刷新到磁盘。

幸运的是，绝大多数典型的服务器的 I/O 操作在本质上都是异步的。
如果在这个漏洞开启 期间（在元数据被刷新之后但是在相应的数据被写到磁盘上之前）重新启动系统或系统死机，那么新老数据都会丢失。出现这种情况的原因如下：元数据更新删除了对原先数据块的任何引用，却指向磁盘上没有填充过数据的数据块。服务器在崩溃后再次启动时，XFS 代码会查看日志，了解情况，把那些不完整的数据块填上二进制零以预防安全性问题。不幸的是，数据就永远丢失了。
这个问题在频繁使用全新的数据覆盖文件的情况下尤其麻烦。在这样的情况下，如果系统恰好在不合适的时候死机了，那么前面刷新过的元数据会导致文件内容整个丢失。这种特殊的情况 gentoo.org 服务器也遇到过几次，丢失了数据。由于每隔几分钟我们的邮差邮件列表软件就会用新数据覆盖它自己的配置文件，因此它最有可能发生上面所描述的情况。
这个故事寓意是这样的：SGI 的开发者在 XFS 1.1 中已经大大改善了这种局面，如果您运行的是 XFS 1.0，那么您应该下定决心尽快升级到 XFS 1.1。XFS 1.1 还包括了许多附加的修订。在 SGI 缓解了 XFS 对同步元数据更新的依赖的时候，它还能改进 XFS 1.0.x 的弱点之一 — 文件删除。真是太棒了！
过不了多久，我们还可以期待看到 XFS 的新发行版，它将更适合于 Intel Itanium 平台。目前，XFS 的 Linux 版本要求 XFS 文件系统块的大小与平台的内存页面大小相同。这常常使得在 x86 系统上的磁盘不可能移到 Itanium 系统上，因为 Itanium 可以使用最大 64K 的页面，而 x86 只能用 4K。此外，对于大多数的任务来说，大小为 64K 的文件系统块并非最佳选择，但当前的代码迫使一些 Itanium 系统必须使用这样的文件系统块大小。如果修复了这个块大小问题，不仅将 XFS 文件系统从 x86 迁移到 ia64 上变得容易了，而且提供了一个额外的好处，就是允许系统管理员选择适合于他们的需要的 XFS 文件系统块大小。




回页首
ReiserFS
ReiserFS 文件系统堪称最有魄力的日志文件系统开发项目，因为它不只是将现有的文件系统移植到 Linux 内核（比如：XFS、JFS），它的设计也不是象 ext3 那样基于早先的文件系统。相反，ReiserFS 的设计完全是从头开始的，就其处理小文件而言，有一些 非常吸引人的性能指标。那么，自从 ReiserFS 被引入到 2.4 内核以来，它是怎样解决稳定性问题和一般的文件系统健壮性问题的呢？
从引入 ReiserFS 开始，它一直有数目非常多的稳定性和崩溃问题。有很多内核对 ReiserFS 用户来说根本就是噩梦，其中包括 2.4.3、2.4.9 甚至相对较新的 2.4.16。不过，尽管这些问题中有些是因 ReiserFS 文件系统代码本身的错误引起的，但有数目惊人的问题会因对内核的其它部分所做的修改而产生不希望的副作用。Linux 内核的开发过程中有一件不幸的事就是，无论您多么细心的测试您自己的代码，还是可能会有某个另外的内核开发者插入的一条很可能没有经过测试的更改而导致您的代码崩溃。最常见的情况是，只有在这些不希望的副作用已经被引入并向深信不疑的 Linux 计算公众用户发行 之后，开发者之间才会有交流。我认为，公平的说，有相当多的伤心的 ReiserFS 用户，他们发现自己正处于这一不幸的失败的环境中。
但是，我的朋友，好消息来了。在过去的几个月中，对于 ReiserFS 来说，情况看上去已经开始好转许多了。一是内核源代码开始稳定在 2.4.17 发行版。此外，在过去的几个月来 Namesys 的开发者（ReiserFS 的开发者）已经能修复相当多隐藏在他们的代码中的错误了。甚至还有更好的消息，内核 2.4.18 好象有一个 非常稳定的 ReiserFS 实现。2.4.18 绝非新出现的 — 在写这篇文章的时候，它出现已经将近三个月了，在代码中还没有发现任何重大问题。事实上，由于缺少新来的错误报告，Namesys 已经重新给发行版经理（Release Manager）指派了新的工作，改进 ReiserFS 的性能。
因此，ReiserFS 和 2.4 内核好象最终解决了它们的差异问题。就我个人观点而言，这真是振奋人心的消息；我很想再开始使用 ReiserFS，并计划在我下一次重新加载我的开发工作站时用它作为我的根文件系统。因为内核方面的问题已经平静下来了，我确信，现在有许多别的前 ReiserFS 用户也很愿意再次回到 ReiserFS。坦白的说，一旦您看到 ReiserFS 的小文件性能可以给某些应用程序的性能带来多大的提升，就很难再离开它了。
那么，在不远的将来我们期望在 ReiserFS 看到些什么呢？据 Hans Reiser 和他的开发者小组所说，预计在 2.4.20_pre1 会有一些非常好的改进，包括对 Chris Mason 的数据日志（象 ext3 的“data=journal”模式）的支持、伸缩性要好得多的新的块分配代码以及对大文件性能方面的一些改进，预计从 IDE 驱动器读取大文件时性能的提高要高达 15%。除这些马上就要着手进行的重大改进之外，我们很可能会看到 ReiserFS 将支持与 ext3 的“data=ordered”模式等价的模式。在这个问题上，ReiserFS 将提供和在 ext3 文件系统中发现的一样的数据完整性功能。我很高兴的看到 ReiserFS 开发小组正在将数据完整性（而不只是元数据完整性）提到这样高的优先级。




回页首
Ext3
那么，ext3 的情况如何呢？通常，ext3 相当稳定，还没有遇到过重大问题。为此，ext3 堪称非常可靠而且健壮的日志文件系统选择。尽管有些人也许会认为这个文件系统很“沉闷”，因为除很好的日志实现之外，看不出它对 ext2 做了任何重大改进，但“沉闷”在文件系统世界中是一件好事。它意味着文件系统很擅长只是不紧不慢的执行它的工作。此外，虽然与 ResierFS、XFS 和 JFS 相比，ext3 的可伸缩性具有局限性，但 ext3 已经证明，在大多数服务器和工作站所执行的典型文件系统操作中使用，它不仅速度很快而且很容易调整。很明显，ext3 开发者已经达到了他们要创建一个高质量的日志文件系统的目标，Linux 用户不用费什么力气就可以放心的升级到这一文件系统。
对于内核 2.4.19_pre5，现在同步安装 ext3 文件系统和“chattr +S”文件比从前快大约十倍。很快，我们有望看到添加一个选项用于特定目录树的同步更新，这个功能将主要用于邮件程序。此外，我们还期望能看到定期对代码进行小错误修复和性能改进，但是不会修改主要部分；ext3 已经很完美了，现在代码似乎处于维护模式。
非常感谢您花时间阅读我的这篇文章，请您下一次继续阅读我的文章，我们要看看 JFS！


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