duotaiya 发表于 2004-8-2 13:08:31

高级文件系统实现者指南[转贴]

这是ibm china上的文章

日志和 ReiserFS

Daniel Robbins ([email protected])
总裁/CEO,Gentoo Technologies, Inc
2001 年 6 月

    伴随着 Linux 2.4 版本的发行,出现了大量的文件系统可能性,其中包括 ReiserFS、XFS、GFS 和其它文件系统。这些文件系统听起来的确都很酷,但是它们真正能做些什么呢,擅长在哪些方面,以及在 Linux 产品环境下如何才能安全地使用它们呢?在高级文件系统实现者指南中,Daniel Robbins 通过向您展示如何在 Linux 2.4 的环境下建立这些新的高级文件系统来回答以上的问题。遵从这个方法,他提供了在实际实现过程中的有价值的建议,性能信息和重要的技术性注意要点,以便于您在新的文件系统中能有令人愉快的经历。在这里,也就是这个系列的第一篇文章中,他解说了日志和 ReiserFS 的优点。

准备好的内容
这一系列文章的目的是向您详实地介绍 Linux 的各种新的文件系统,包括 ReiserFS、XFS、JFS、GFS、ext3 和其它的文件系统。我要让您知道一些必要的实用知识,有了这些知识您才能开始使用这些文件系统。我的目标是帮助您尽可能地避免潜在的隐患;这就是说,我们将仔细地了解一下文件系统的稳定性、性能问题(或好或差)、您应该知道的任何的负面应用程序交互作用、内核与补丁的最佳搭配以及更多内容。您可以把这一系列的文章看成是这些下一代文件系统的“内幕指南”。

这就是准备好的内容。但是要开始这一系列工作,我还有一篇文章要脱离这个主题,用来为接下来的行程做准备。我将会涉及两个对于 Linux 开发社区非常重要的主题 — 日志和 ReiserFS 后的设计理念。日志是非常重要的,因为它是我们长期以来一直期待的技术,而现在终于出现了。在 ReiserFS、XFS、JFS、ext3 和 GFS 中都用到它。确切地理解日志是做什么的和为什么 Linux 需要它是非常重要的。即使您对日志已有所掌握,我还是希望我有关日志的介绍可以成为一个好的模型,以用来向其他人解释这项技术,或者作为一项惯例,以利于全世界的部门和组织开始向这些新的日志文件系统进行转变。这个过程通常是由“Linux guy/gal”开始的,就像您自己也会说服其他人应该这么做。

在这篇文章的后半部分,我们将看看 ReiserFS 后的设计理念。通过这么做,我们能够很好地掌握一个事实,那就是这些新的文件系统并不只是为了做同样的事比老的系统快一点。它们还允许我们用以前完全不可能的方法来处理事情。开发人员在阅读这一系列文章时应该牢记这一点。这些新的文件系统的能力 将很可能对您今后的 Linux 软件开发工程的代码编写产生影响。

理解日志:元数据
正如您所了解的那样,文件系统的存在允许您储存、检索和操作数据。为了实现这一目的,文件系统需要保持一个内在的数据结构使得您的数据有组织并且便于访问。这一内部的数据结构(确切地说就是“关于数据的数据”)被称为 元数据。就是这个元数据的结构为文件系统提供了其特定的身份和性能特征。

通常,我们并不直接和文件系统的元数据打交道。而是一个特别的 Linux 文件系统驱动程序为我们作相应的工作。Linux 文件系统驱动程序是专门用来操作复杂的元数据的。然而,为了使得文件系统驱动程序正常工作,有一个很重要的必要条件;它需要在某种合理的、一致的和没有干扰的状态下找到元数据。否则,文件系统驱动程序就不能理解和操作元数据,那么您也就不能存取文件了。

理解日志:fsck
这就引出了 fsck。当 Linux 系统启动时,fsck 启动并扫描系统的 /etc/fstab 文件中列出的所有本地文件系统。fsck 的工作就是确保要装载的文件系统的元数据是处于可使用的状态。大多数的时候是可使用的。当 Linux 关闭时,它仔细地把所有的缓冲区数据转送到磁盘,并确保文件系统被彻底卸载,以保证系统再次启动时能够使用。典型的就是,fsck 扫描那些将被装载的文件系统,确定它们已被彻底卸载,并做出合理的假设 — 所有的元数据都没有问题。

然而,我们都知道不时地会有一些意外发生,例如意想不到的电源故障或者系统挂起。当出现这些不幸的情况时,Linux 没有机会彻底卸载文件系统。当系统重新启动,fsck 开始扫描时,它会检测到这些没有彻底卸载的文件系统,并做出合理的假设 — 文件系统可能没有为 Linux 文件系统驱动程序准备好。这就很有可能导致元数据在某种情况下陷入困境。

所以,为了弥补这种情况,fsck 将开始彻底的扫描并且全面地检查元数据,修正这一过程中找到的任何错误。一旦 fsck 完成这样的工作,文件系统就可以使用了。尽管意想不到的电源故障或者系统挂起可能造成最近修改的数据丢失,但是由于元数据现在是一致的,文件系统就可以被装载和投入使用了。

fsck 的问题
迄今为止,为确保文件系统的一致性,这种方法可能听起来并不是个坏主意,但是却不是最佳的解决方案。问题出自于这样一个事实 — fsck 必须扫描文件系统全部的元数据,以确保文件系统的一致性。对所有的元数据做彻底的一致性检查是一项极为费时的工作。通常至少要花上好几分钟才能完成。更糟糕的是,文件系统越大,完成这个彻底的扫描所花费的时间就 越长。这就是个大问题,因为当 fsck 做它自己事情的时候,您的 Linux 系统实际上就是被切断的,并且如果您有一个庞大数量的文件系统存储,您的系统可能就会花上半个小时或者更长的时间来执行 fsck。当然,在任务紧要的数据中心的环境里,也就是在系统正常运行极为重要的环境下,标准的 fsck 工作可能会造成破坏性的结果。幸运的是,有更好的解决方案。

日志
日志文件系统通过增加一个叫做日志的新的数据结构来解决这个 fsck 问题。这个日志是位于磁盘上的结构。在对元数据做任何改变以前,文件系统驱动程序会向日志中写入一个条目,这个条目描述了它将要做些什么。然后,它继续并修改元数据。通过这种方法,日志文件系统就拥有了近期元数据被修改的历史记录,当检查到没有彻底卸载的文件系统的一致性问题时,这个记录就唾手可得了。

可以这样来看待日志文件系统 — 除了存储数据(您的素材)和元数据(关于素材的数据)以外,它们还有一个日志。您可以称它们为元元数据(关于素材数据的数据)。

运作中的日志
那么,fsck 如何处理日志文件系统呢?实际上,通常它什么都不做。它只是忽略文件系统并允许它被装载。在快速地恢复文件系统到达一致性状态的背后,真正起作用的在于 Linux 文件系统驱动程序中。当文件系统被装载时,Linux 文件系统驱动程序查看文件系统是否完好。如果由于某些原因出了问题,那么就需要对元数据进行修复,但不是执行对元数据的彻底扫描(就像 fsck 那样),而是查看日志。由于日志中包含了按时间顺序排列的近期的元数据修改记录,它就简单地查看 最近被修改的那部分元数据。因而,它能够在几秒钟时间内将文件系统恢复到一致性状态。并且与 fsck 所采用的传统方法不同,这个日志重放过程在大型的文件系统上并不需要花更多的时间。多亏了日志,数百 G 的文件系统元数据几乎能在瞬间恢复到一致性的状态。

ReiserFS
现在,我们来谈一谈 ReiserFS,它是我们将要研究的几个日志文件系统中的第一个。ReiserFS 3.6.x(作为 Linux 2.4 一部分的版本)是由 Hans Reiser 和他的在 Namesys 的开发组共同开发设计的。Hans 和他的组员们相信最好的文件系统是那些能够有助于创建独立的共享环境或者命名空间的文件系统,应用程序可以在其中更直接、有效和有力地相互作用。为了实现这一目标,文件系统就应该满足其使用者对性能和功能方面的需要。那样,使用者就能够继续直接地使用文件系统,而不必建造运行在文件系统之上(如数据库之类)的特殊目的层。

小文件的性能
那么,如何能使文件系统更加适应环境呢?Namesys 已经决定着眼于文件系统的一个方面,至少最初是 — 小文件的性能。通常,像 ext2 和 ufs 这样的文件系统在这一方面做的并不是很好,经常迫使开发人员转向数据库或者特别组织的处理来获取他们所需要的某种性能。随着时间的推移,这种“围绕问题进行编码”的方法怂恿了代码的膨胀和许多不兼容的特殊目的 API,这并不是好事情。

这儿有一个 ext2 如何鼓励这种编程的例子。ext2 很擅长存储大量大小在 20k 以上的文件,但是对于存储 2,000 个 50 字节的文件来说,它就不是一种很理想的技术了。当 ext2 必须处理非常小的文件时,不只是性能显著地下降,而且存储效率也同样下降,因为 ext2 是按 1k 或者 4k 的块来分配空间的(可在文件系统创建时设定)。

现在,常规的明智做法会提示您不应该在文件系统上储存这么多小的文件。而是应该存储在某种运行在文件系统之上的数据库里。作为对这种说法的回应,Hans Reiser 指出无论何时您需要在文件系统的顶上建立一层,那就意味着文件系统不满足您的需要。如果文件系统满足您的需要,那么您首先就要避免使用特殊目的的解决方案。这样就可以节省开发的时间,并消除代码膨胀。这些代码可能是在您手动处理自己的个人存储器或者缓冲机制时,或者与数据库的某个库交互作用过程时所产生的。

理论上是这样。但是在实际运用中,ReiserFS 的小文件性能会是如何的好呢?好得让人吃惊。实际上,当处理小于 1k 的文件时,ReiserFS 大概要比 ext2 快 8 到 15 倍!更妙的是,这些性能提高并不以其它文件类型的性能损失为代价。通常,ReiserFS 几乎在各个方面都优于 ext2,但是在处理小文件时才真正体现出了其闪光点。

ReiserFS 技术
那么 ReiserFS 是怎样提供如此出色的小文件性能的呢?ReiserFS 使用了特殊的优化 b* 平衡树(每个文件系统一个)来组织所有的文件系统数据。这为其自身提供了非常不错的性能改进,也能够减轻文件系统设计上的人为约束。例如,现在一个目录下可以容纳 100,000 个子目录。另一个使用 b* 树的好处就是 ReiserFS 能够像大多其它的下一代文件系统一样,根据需要动态地分配索引节,而不必在文件系统创建时建立固定的索引节。这有助于文件系统更灵活地适应其面临的各种存储需要,同时提供附加的空间有效率。

ReiserFS 有许多特征是特别针对提高小文件的性能的。和 ext2 不同,ReiserFS 并不固定地以 1k 或者 4k 的块分配存储空间,而是分配所需要的精确尺寸。而且 ReiserFS 也包括了以尾文件为中心的特殊优化 — 尾文件是指那些比文件系统块小的文件及文件结尾部分。为了提高性能,ReiserFS 能够在 b* 树的叶子节点存储文件,而不是把数据存储在磁盘的其它地方再指向它。

这做了两件事。第一,它显著地提高了小文件的性能。由于文件数据和 stat_data(索引节)信息是紧挨着存储的,它们通常能被同一次磁盘 IO 操作所读取。第二,ReiserFS 能够压缩尾文件,节省大量磁盘空间。实际上,带有尾文件压缩功能(默认)的 ReiserFS 文件系统可以比同等的 ext2 文件系统多存储 6 个百分点的数据,这就其自身来说是令人惊叹的。

然而,由于在文件被修改时,尾文件压缩迫使 ReiserFS 重装数据,这就导致了性能上的轻微折损。鉴于这个原因,ReiserFS 尾文件压缩可以被关掉,允许系统管理员在速度与空间有效率上做出选择,或者牺牲一些存储能力来换取更高的速度。

ReiserFS 确实是一个非常出色的文件系统。在我的下一篇文章中,我将会指导您在 Linux 2.4 下完成 ReiserFS 安装的全过程。我们还将仔细地看一看性能调整,应用程序交互作用(和怎么围绕他们工作)以及使用的最佳内核等等。

参考资料

    * Namesys 网页正是更多地了解 ReiserFS 的地方。

    * 要想了解当前更为深入的 ReiserFS 信息,ReiserFS 邮件列表是一个极好的资源。也一定要查看 ReiserFS 邮件列表档案。

    * 您可以在 Juan I. Santos Florido 的 Linux Gazette 日志文件系统的回顾中,发现对于 UFS、ext2、ReiserFS 和更多文件系统中元数据的不同之处的深入探讨。

    * Jedi 的 ReiserFS/Qmail tuning page 中包含了许多对于 qmail 使用者来说很好的信息。也请一定查看 ReiserSMTP — Jedi 的 drop-in qmail 组件集,它提供了令人注目的更高 qmail 性能。

    * Linux 每周新闻是紧跟着最新内核发展的非常好的参考资料。

    * 请阅读在 developerWorks 上的 Steve Best 的 JFS 概述。

    * 请阅读一下在 developerWorks 上的 JFS 基础教程。



关于作者
Daniel Robbins 居住在新墨西哥州的 Albuquerque。他是 Gentoo Technologies, Inc. 的总裁兼 CEO,Gentoo Linux(用于 PC 的高级 Linux)和 Portage 系统(Linux 的下一代移植系统)的创始人。他还是 Macmillan 书籍 Caldera OpenLinux Unleashed、SuSE Linux Unleashed 和 Samba Unleashed 的合作者。Daniel 自二年级起就与计算机结下不解之缘,那时他首先接触的是 Logo 程序语言,并沉溺于 Pac-Man 游戏中。这也许就是他至今仍担任 SONY Electronic Publishing/Psygnosis 的首席图形设计师的原因所在。Daniel 喜欢与妻子 Mary 和新出生的女儿 Hadassah 一起共度时光。可通过 [email protected] 与 Daniel 联系。

duotaiya 发表于 2004-8-2 13:09:50

ext3 简介

Daniel Robbins([email protected]
总裁/CEO,Gentoo Technologies,Inc.
2001 年 11 月

    Linux 的 2.4 发行版带来了使用多种新文件系统的可能性,包括 Reiserfs、XFS、GFS 以及其它文件系统。这些文件系统听起来很酷,但是它们到底能做什么,它们擅长于什么,还有,您到底如何着手在 Linux 生产环境下安全地使用它们呢?Daniel Robbins 通过向您展示如何在 Linux 2.4 上设置这些新的高级文件系统来回答这些问题。在这一部分,Daniel 研究了 ext3,它是 ext2 的新改进版,具有日志记录能力。

在前面几部分中,我们花费了一些精力去研究非传统文件系统(譬如 tmpfs 和 devfs)。现在,是时候回到基于磁盘的文件系统上来了,我们将通过研究 ext3 来实现这个目的。ext3 文件系统(由 Stephen Tweedie 博士设计)构建在现有的 ext2 文件系统的框架上;实际上,除了一个微小(但重要)的区别 — ext3 支持日志记录以外,ext3 和 ext2 非常相似。但正是因为具有了这个小小的增加,您会发现 ext3 具有几种令人惊讶和富有吸引力的能力。在本文中,我将让您充分了解与当前可用的其它日志记录文件系统相比,ext3 有哪些优缺点。在我的下一篇文章中,我们将设置和运行 ext3。

理解 Ext3
那么,与 ReiserFS 相比,ext3到底如何呢?在以前的文章中,我解释了 ReiserFS 是如何充分适合处理小文件的(4K 以下),并且,在某些情况下,ReiserFS 处理小文件的能力比 ext2 和 ext3 强十到十五倍。但尽管 ReiserFS 有许多长处,它还是有弱点。在当前的 ReiserFS(版本 3.6)实现中,与 ext2 和 ext3 相比,尤其是读取大的邮件目录时,特定文件访问模式实际上可能导致特别糟糕的性能。还有,ReiserFS 没有好的 NFS 兼容性跟踪记录,同时稀疏文件性能也较差。 相反,ext3 是一个非常全面的文件系统。ext3 很象 ext2;它不会为您提供象 ReiserFS 那样特别快的小文件性能,但是,它也不会给您带来意外的性能或功能性瓶颈。

ext3 最妙的特性之一是:因为 ext3 基于 ext2 的代码,所以它的磁盘格式和 ext2 的相同;这意味着,一个干净卸装的 ext3 文件系统可以作为 ext2 文件系统毫无问题地重新挂装。并且不仅如此。应该感谢 ext2 和 ext3 都使用相同的元数据,因而有可能执行 ext2 到 ext3 文件系统的现场升级。是的,您的理解是正确的。通过升级一些关键系统实用程序、安装新的 2.4 内核,并在每个文件系统上输入单条 tune2fs 命令,就可以把现有的 ext2 服务器转换成日志记录 ext3 系统。甚至可以在 ext2 文件系统已挂装的情况下进行这些操作。转换是安全的、可逆的、并且令人难以置信地简单,和到 XFS、JFS 或 ReiserFS 的转换不同,您不必备份和从头创建文件系统。现在花一些时间思考一下,有数以千计的 ext2 生产服务器,只要几分钟时间就能升级到 ext3;那么,您就会充分理解 ext3 对于 Linux 社区的重要性了。

如果非要用一个词来描述 ext3,我会说“舒适”。在已有的 ext2 系统上安装启用 ext3 的过程轻松得令人难以置信,并且升级以后,也不会导致任何意外的性能急剧下降。并且,ext3 在舒适方面还有一个优点,那就是,ext3 恰巧又是 Linux 可用的最可靠的日志记录文件系统之一,我将在下面解释这一点。

Ext3 可靠性
除了与 ext2 兼容之外,ext3 还通过共享 ext2 的元数据格式继承了 ext2 的其它优点。譬如,ext3 用户可以使用一个稳固的 fsck 工具。您会回想起使用日志记录文件系统的要点之一是首先避免对彻底的 fsck 的需求,但是如果您确实要从脆弱的内核、坏的硬盘或者别的什么地方获得毁坏的元数据,您将非常感激 ext3 从 ext2 继承了 fsck 这个事实。相反,ReiserFS 的 fsck 还很幼稚,当脆弱的元数据真的出现时,对脆弱元数据的修复过程将是困难和危险的。

仅元数据日志记录
有趣的是,ext3 处理日志记录的方式与 ReiserFS 和其它日志记录文件系统所用的方式迥异。使用 ReiserFS、XFS 和 JFS 时,文件系统驱动程序记录元数据,但不提供数据日志记录。使用 仅元数据日志记录,您的文件系统元数据将会异常稳固,因而可能永远不需要执行彻底 fsck。然而,意外的重新引导和系统锁定可能会导致最近修改数据的明显毁坏。Ext3 使用一些创新的解决方案来避免这些问题,我们将对此做稍微深入的研究。

但首先,重要的是确切理解仅元数据日志记录最终是如何危害您的。举例来说,假设您正在修改名为 /tmp/myfile.txt 的文件时,机器意外锁定,被迫需要重新引导。如果您使用的是仅元数据日志记录文件系统,譬如 ReiserFS、XFS 或者 JFS,文件系统元数据将容易地修复,这要感谢元数据日志,您不必耐着性子等待艰苦的 fsck 了。

但是,存在一种明显的可能性:在将 /tmp/myfile.txt 文件装入到文本编辑器时,文件不仅仅丢失最近的更改,而且还包含许多乱码甚至可能完全不可读的信息。这种情况并不总会发生,但它 可能并且经常发生。

下面解释原因。典型的日志记录文件系统(譬如 ReiserFS、XFS 和 JFS)对元数据有特别处理,但是对数据不够重视。在上述示例中,文件系统驱动程序处于修改一些文件系统块的过程中。文件系统驱动程序更新适当的元数据,但是没有时间将其缓存中的数据刷新到磁盘的新块中。因此,当您将 /tmp/myfile.txt 文件装入文本编辑器时,文件的部分或全部包含乱码 — 在系统锁定之前来不及初始化的数据块。

ext3 方法
既然我们对这个问题已经有了一个总的很好的理解,让我们来看 ext3 是如何实现日志记录的。在 ext3 里,日志记录代码使用一个特殊的称为“日志记录块设备”层或 JBD 的 API。JBD 被设计成在任何块设备上实现日志的特殊目的。Ext3 通过“钩入(hooking in)”JBD API 来实现其日志记录。例如,ext3 文件系统代码将正在执行的修改告知 JBD,并且还会在修改磁盘上包含的特定数据之前请求 JBD 的许可。通过执行这些操作,给予了 JBD 代表 ext3 文件系统驱动程序管理日志的适当机会。这是很好的安排,因为 JBD 是作为一个单独的、一般实体而开发的,将来它可以用于向其它文件系统添加日志记录能力。

关于 JBD 管理的 ext3 日志有一些巧妙的特性。其中之一是,ext3 的日志存储在一个索引节点中 — 基本上是个文件。能否看到这个位于 /.journal 的文件,取决于您是如何在文件系统上“启用 ext3”的。当然,通过将日志存储在索引节点中,ext3 可以向文件系统添加必要的日志,而不需要对 ext2 元数据进行不兼容扩展。 这是 ext3 文件系统保持对 ext2 元数据,以及 ext2 文件系统驱动程序的向后兼容性的关键方式之一。

不同的日志记录方法
不必惊讶,确实有许多方法用于实现日志。例如,文件系统开发者可能会设计出一种日志,该日志存储在主机文件系统上需要修改的 字节范围。这种方法的好处在于,日志能够以一种非常高效的方式存储许多对文件系统的微小修改,这是因为它只记录需要修改的个别字节,而不记录除此以外的任何信息。

JBD 使用另外一种(从某种意义来说是更好的)方法。JBD 存储完整的被修改的文件系统块本身,而不是记录必定会被更改的字节范围。ext3 文件系统驱动程序也使用这种方法,存储内存中被修改的块(大小为 1K、2K 或 4K)的完整副本,以跟踪暂挂的 IO 操作。开始,这看起来有点浪费。毕竟,包含已修改数据的完整块中还可能包含 未修改的(已经在磁盘上)数据。

JBD 所使用的方法称为物理日志记录,这意味着 JBD 使用完整的物理块,作为实现日志的主要媒介。相反,只存储已修改的字节范围而非完整块的方法称为 逻辑日志记录,这是 XFS 所使用的方法。因为 ext3 使用物理日志记录,所以 ext3 日志将具有比其它文件系统日志(例如,XFS 日志)更大的相对磁盘占用。但是,因为 ext3 在文件系统内部和日志中使用完整块,ext3 处理的复杂度比实现逻辑日志记录的要小。另外,完整块的使用允许 ext3 执行一些额外的优化,譬如,将多个暂挂的 IO 操作“压扁”到同一内存数据结构的单个块中。 接下来,这种优化允许 ext3 将这多个更改在一次写操作中写到磁盘上,而不需要多次写操作。此外,因为文字块数据存储在内存中,这些内存数据在写到磁盘之前,不必或只需作很少更改,大大减少了 CPU 开销。

Ext3,数据保护者
现在,我们最后来了解一下 ext3 文件系统是如何高效地提供元数据和数据日志记录,以避免在本文前面部分所描述的数据毁坏问题的。实际上,ext3 有两种确保数据和元数据完整性的方法。

最初,ext3 被设计用来执行完整数据和元数据日志记录。在这种方式下(称之为“data=journal”方式),JBD 将所有对数据和元数据的更改都记录到文件系统中。因为数据和元数据都被记录,JBD 可以使用日志将元数据和数据恢复到一致状态。完整数据日志记录的缺点是它可能会比较慢,但可以通过设置相对较大日志来减少性能损失。

最近,ext3 添加了一种新的日志记录方式,该方式提供完整日志记录的好处而不会带来严重的性能损失。这种新方式只对元数据进行日志记录。但是,ext3 文件系统驱动程序保持对与每个元数据更新对应的特殊数据块的跟踪,将它们分组到一个称为事务的实体中。当事务应用于适当的文件系统时,数据块首先被写到磁盘。一旦写入数据块,元数据将随后写入日志。通过使用这种技术(称为“data=ordered”方式),即使只有元数据更改被记录到日志中,ext3 也能够提供数据和元数据的一致性。ext3 缺省使用这种方式。

结束语
最近,有许多人在尝试确定哪种 Linux 日志记录文件系统是“最好的”。实际上,没有一个针对每个应用程序都“合适的”文件系统,每个文件系统都有自身的长处。这是有这么多下一代 Linux 文件系统供选择的好处之一。所以,理解每种文件系统的长处和弱点,以便对使用哪种文件系统作出一个有根据的选择,远远优于选出一个绝对的“最好的”文件系统,并将它用于所有可能的应用程序。

Ext3 具有许多长处。它被设计得极易部署。它基于稳固的 ext2 文件系统代码,并继承了一个很好的 fsck 工具。还有,ext3 的日志记录能力经过特别设计,以确保元数据和数据的完整性。总之,ext3 确实是一个很棒的文件系统,并且是现在仍受到推崇的 ext2 文件系统的一个合格的继承者。请关注我的下一篇文章,那时我们将设置和运行 ext3。在那之前,您可能会需要查看下列参考资料。

参考资料

    * 请阅读 Daniel 在本系列中的其它文章,他描述了:
          o 日志记录和 ReiserFS 的好处 (第 1 部分)
          o 设置 ReiserFS 系统(第 2 部分)
          o 使用 tmpfs 虚拟内存文件系统和绑定挂装(第 3 部分)
          o 设备管理文件系统,devfs 的好处(第 4 部分)
          o 开始到 devfs 的转换(第 5部分)
          o 用 init 封装器完成到 devfs 的转换(第 6 部分)

    * 阅读 Stephen Tweedie 博士的 Ext3,日志记录文件系统发言的 完整版,他的发言在 2000 年 7 月的渥太华 Linux 讨论会上受到重视。

    * 请到 Andrew Morton 的 ext3 for 2.4 页面查找更多关于与 2.4 内核一起使用 ext3 的内容。 Andrew Morton 是负责将 ext3 移植到 2.4 内核的人,并对撰写这篇文章提供了非常宝贵的帮助。如果您等不及我的下一篇文章,Andrew 有一个很好的 ext3 和 2.4 用法页面,该页将立即向您展示如何设置并运行 ext3。

    * 要了解 ext3 开发的最新信息,请务必访问 ext3 用户邮件列表档案。当然,您也可以订阅。

    * 在developerWorks可以获得 Daniel Robbins 的免费 JFS 基础教程。

    * 浏览 developerWorks 上的更多 Linux 参考资料。

    * 浏览 developerWorks 上的 更多开放源码参考资料。



关于作者
作者 Daniel Robbins 住在美国新墨西哥州的阿尔布开克(Albuquerque)。他是 Gentoo Technologies,Inc. 的总裁兼 CEO、Gentoo Linux(用于 PC 的高级 Linux)的创始人,以及 Portage 系统(Linux 的下一代移植系统)的创始人。他还曾经是 Macmillan 出版的一些书籍(包括 Caldera OpenLinux Unleashed、SuSE Linux Unleashed 和 Samba Unleashed)的投稿人。Daniel 自小学二年级起就与计算机结下不解之缘,那时他首先接触的是 Logo 程序语言,并沉溺于 Pac Man 游戏中。这也许就是他至今仍担任 SONY Electronic Publishing/Psygnosis 的首席图形设计师的原因所在。 Daniel 喜欢和妻子 Mary 以及他们的女儿 Hadassah 一起共度时光。可通过 [email protected] 与 Daniel 联系。

duotaiya 发表于 2004-8-2 13:10:24

XFS 简介

Daniel Robbins([email protected]
总裁兼 CEO,Gentoo Technologies,Inc.
2002 年 1 月

    随着 Linux 2.4 发行版的到来,给我们带来了使用多种新文件系统的可能性,包括 Reiserfs、XFS、GFS 以及其它文件系统。这些文件系统听起来很酷,但是它们到底能做什么,它们擅长于什么,还有,您到底如何着手在 Linux 生产环境下安全地使用它们呢?Daniel Robbins 通过向您展示如何在 Linux 2.4 下设置这些新的高级文件系统来回答这些问题。在这一部分,Daniel 介绍了 XFS — 目前可用于 Linux 的 SGI 的免费企业级文件系统。

在本文中,我们将研究 XFS — 用于 Linux 的 SGI 的免费、64 位高性能文件系统。首先,我将说明,XFS 与 ext3 和 ReiserFS 相比,各有什么优缺点,并描述许多 XFS 内部使用的技术,然后,在下一篇文章中,我将全程指导您在自己的系统上设置 XFS,并讲述了 XFS 调优技巧和诸如 ACL(访问控制表)及扩展属性支持之类有用的 XFS 特性。

XFS 简介
XFS 最初是由 Silicon Graphics,Inc. 于 90 年代初开发的。那时,SGI 发现他们的现有文件系统(existing filesystem,EFS)正在迅速变得不适应当时激烈的计算竞争。为解决这个问题,SGI 决定设计一种全新的高性能 64 位文件系统,而不是试图调整 EFS在先天设计上的某些缺陷。因此,XFS 诞生了,并于 1994 年随 IRIX 5.3 的发布而应用于计算。它至今仍作为 SGI 基于 IRIX 的产品(从工作站到超级计算机)的底层文件系统来使用。现在,XFS 也可以用于 Linux。XFS 的 Linux 版的到来是激动人心的,首先因为它为 Linux 社区提供了一种健壮的、优秀的以及功能丰富的文件系统,并且这种文件系统所具有的可伸缩性能够满足最苛刻的存储需求。

XFS、ReiserFS 和 ext3 的性能
到目前为止,选择合适的下一代 Linux 文件系统一直很简单。那些只寻求原始性能的人通常倾向于使用 ReiserFS,而那些更关心数据完整性特性的人则首选 ext3。然而,随着 XFS 的 Linux 版的发布,事情突然变得令人困惑。尤其是,对于 ReiserFS 是否依然是下一代文件系统性能方面的佼佼者,人们开始感到疑惑。

最近,我进行了一系列测试,试图比较 XFS、ReiserFS 和 ext3 在原始性能方面的优劣。在与您分享该结果之前,理解以下事实很重要:该结果只着重比较了在单处理器系统上,系统负载较轻的情况下,常规文件系统的性能趋势,它并不是衡量某一个文件系统是否比另一个文件系统“更好”的绝对尺度。尽管如此,我的结果应该可以帮助您形成一些概念,那就是:哪个文件系统可能最适于某个特定任务。再次声明,不应该将我的结果视为结论性的;最好的测试总是:在每个文件系统上运行您的特定应用程序,以观察它是如何执行的。

结果
在测试中,我发现 XFS 通常是相当快的。在大文件操作方面,XFS 在所有测试中一直处于领先地位,这是意料之中的,因为其设计者花了数年时间设计和调整它,以便能够极出色地完成此类任务。我还发现 XFS 有一个单点性能缺陷:它删除文件不是很快;在这一方面,ReiserFS 和 ext3 轻易地胜过了它。据 Steve Lord(SGI 的文件系统软件总工程师)说,刚编写完一个补丁来解决该问题,并且不久将可以使用该补丁。

除此以外,XFS 的性能非常接近 ReiserFS,并在大多数测试指标上都超过了 ext3。XFS 最佳表现之一在于:象 ReiserFS 一样,它不产生不必要的磁盘活动。XFS 设法在内存中缓存尽可能多的数据,并且,通常仅当内存不足时,才会命令将数据写到磁盘时。当它将数据清仓(flushing)到磁盘时,其它 IO 操作在很大程度上似乎不受影响。相反,在 ext3(“data=ordered”缺省方式)下,将数据清仓到磁盘时,将导致许多额外寻道,甚至还会引起某种不必要的磁盘抖动(thrashing)(取决于 IO 负载)。

我的性能和调整测试主要是关于将 RAM 磁盘中未压缩的内核源文件 tar 包(tarball)抽取到要测试的文件系统,然后递归地将新源文件树复制到同一文件系统中的一个新目录中。XFS 对这类任务执行得很好,尽管,最初 XFS 性能比 ReiserFS 略差一点。然而,在调整了测试 XFS 文件系统的 mkfs.xfs 和 mount 选项以后,当处理诸如在内核源文件树中的中等大小的文件时,XFS 执行效率比 ReiserFS 略好一点。但这不包括删除操作;至少目前,ReiserFS 和 ext3 删除文件要比 XFS 快得多。

性能总结
XFS 在哪些方面可以给您提供哪种性能,对于这一点,希望我的测试结果有助于您形成总的概念;我的测试结果显示,如果需要操作大文件,XFS 文件系统是您最好的选择。对于小文件和中等大小的文件,如果您使用一些能够增强性能的选项创建和挂装 XFS 文件系统的话,它可以与 ReiserFS 匹敌,有时甚至比 ReiserFS 更快。在“data=journal”方式下的 ext3 提供了良好性能,但是它很难获得一致的性能数据,原因在于,ext3 将先前测试中的数据清仓到磁盘所使用的方式,具有明显的不规律性,这将导致某种磁盘抖动。

XFS 设计
在 USENIX '96 上刊载的文章“Scalability in the XFS Filesystem”中(请参阅本文后面的参考资料),SGI 工程师解释:他们设计 XFS 的主要思想只有一个,那就是:“考虑大东西”。确实,XFS 的设计消除了传统文件系统中的一些限制。现在,让我们研究 XFS 幕后一些有趣的设计特性,正是这些设计特性使这一点成为可能。

分配组(allocation groups)简介
当创建 XFS 文件系统时,底层块设备被分割成八个或更多个大小相等的线性区域(region)。您可以将它们想象成“块”(chunk)或者“线性范围(range)”,但是在 XFS 术语中,每个区域称为一个“分配组”。分配组是唯一的,因为每个分配组管理自己的索引节点(inode)和空闲空间,实际上,是将这些分配组转化为一种文件子系统,这些子系统正确地透明存在于 XFS 文件系统内。

分配组与可伸缩性
那么,XFS 到底为什么要有分配组呢?主要原因是,XFS 使用分配组,以便能有效地处理并行 IO。因为,每个分配组实际上是一个独立实体,所以内核可以同时与多个分配组交互。如果不使用分配组,XFS 文件系统代码可能成为一种性能瓶颈,迫使大量需求 IO 的进程“排队”来使索引节点进行修改或执行其它种类的元数据密集操作。多亏了分配组,XFS 代码将允许多个线程和进程持续以并行方式运行,即使它们中的许多线程和进程正在同一文件系统上执行大规模 IO 操作。因此,将 XFS 与某些高端硬件相结合,您将获得高端性能而不会使文件系统成为瓶颈。分配组还有助于在多处理器系统上优化并行 IO 性能,因为可以同时有多个元数据更新处于“在传输中”。

B+ 树无处不在
分配组在内部使用高效的 B+ 树来跟踪主要数据,譬如空闲空间的范围和索引节点。实际上,每个分配组使用两棵 B+ 树来跟踪空闲空间;一棵树按空闲空间的大小排序来存储空闲空间的范围,另一棵树按块设备上起始物理位置的排序来存储这些区域。XFS 擅长于迅速发现空闲空间区域,这种能力对于最大化写性能很关键。

当对索引节点进行管理时,XFS 也是很有效的。每个分配组在需要时以 64 个索引节点为一组来分配它们。每个分配组通过使用 B+ 树来跟踪自己的索引节点,该 B+ 树记录着特定索引节点号在磁盘上的位置。您会发现 XFS 之所以尽可能多地使用 B+ 树,原因在于 B+ 树的优越性能和极大的可扩展性。

日志记录
当然,XFS 也是一种日志记录文件系统,它允许意外重新引导后的快速恢复。象 ReiserFS 一样,XFS 使用逻辑日志;即,它不象 ext3 那样将文字文件系统块记录到日志,而是使用一种高效的磁盘格式来记录元数据的变动。就 XFS 而言,逻辑日志记录是很适合的;在高端硬件上,日志经常是整个文件系统中争用最多的资源。通过使用节省空间的逻辑日志记录,可以将对日志的争用降至最小。另外,XFS 允许将日志存储在另一个块设备上,例如,另一个磁盘上的一个分区。这个特性很有用,它进一步改进了 XFS 文件系统的性能。

象 ReiserFS 一样,XFS 只对元数据进行日志记录,并且在写元数据之前,XFS 不采取任何专门的预防措施来确保将数据保存到磁盘。这意味着,使用 XFS(就象使用 ReiserFS)时,如果发生意外的重新引导,则最近修改的数据有可能丢失。然而,XFS 日志有两个特性使得这个问题不象使用 ReiserFS 时那么常见。

使用 ReiserFS 时,意外重新引导可能导致最近修改的文件中包含先前删除文件的部分内容。除了数据丢失这个显而易见的问题以外,理论上,这还可能引起安全性威胁。相反,当 XFS 日志系统重新启动时,XFS 确保任何未写入的数据块在重新引导时置零。因此,丢失块由空字节来填充,这消除了安全性漏洞 — 这是一种好得多的方法。

现在,关于数据丢失问题本身,该怎么办呢?通常,使用 XFS 时,该问题被最小化了,原因在于以下事实:XFS 通常比 ReiserFS 更频繁地将暂挂元数据更新写到磁盘,尤其是在磁盘高频率活动期间。因此,如果发生死锁,那么,最近元数据修改的丢失,通常比使用 ReiserFS 时要少。当然,这不能彻底解决不及时写数据块的问题,但是,更频繁地写元数据也确实促进了更频繁地写数据。

延迟分配
研究一下延迟分配这个 XFS 独有的特性,然后我们将结束关于 XFS 的技术概述。正如您可能知道的,术语分配(allocation)是指:查找空闲空间区域并用于存储新数据的过程。

XFS 通过将分配过程分成两个步骤来处理。首先,当 XFS 接收到要写入的新数据时,它在 RAM 中记录暂挂事务,并只在底层文件系统上保留适当空间。然而,尽管 XFS 为新数据保留了空间,但它却没有决定将什么文件系统块用于存储数据,至少现在还没决定。XFS 进行拖延,将这个决定延迟到最后可能的时刻,即直到该数据真正写到磁盘之前作出。

通过延迟分配,XFS 赢得了许多机会来优化写性能。到了要将数据写到磁盘的时候,XFS 能够以这种优化文件系统性能的方式,智能地分配空闲空间。尤其是,如果要将一批新数据添加到单一文件,XFS 可以在磁盘上分配一个单一、相邻区域来储存这些数据。如果 XFS 没有延迟它的分配决定,那么,它也许已经不知不觉地将数据写到了多个非相邻块中,从而显著地降低了写性能。但是,因为 XFS 延迟了它的分配决定,所以,它能够一下子写完数据,从而提高了写性能,并减少了整个文件系统的碎片。

在性能上,延迟分配还有另一个优点。在要创建许多“短命的”临时文件的情况下,XFS 可能根本不需要将这些文件全部写到磁盘。因为从未给这些文件分配任何块,所以,也就不必释放任何块,甚至根本没有触及底层文件系统元数据。

结束语
我希望您喜欢阅读这篇关于 XFS(Linux 的、功能强大的下一代文件系统之一)的性能和技术特征的文章。在下一篇文章中,我们再见,那时我将向您展示如何设置 XFS,并在您的系统上运行它。在下一篇文章中,我们还将研究 XFS 的一些高级特性,譬如 ACL 和扩展属性。那么我们下次见!

参考资料

    * 请阅读 Daniel 在本系列中先前的文章,其中,他描述了:
          o 日志记录和 ReiserFS 的好处(第 1 部分)
          o 设置 ReiserFS 系统(第 2 部分)
          o 使用 tmpfs 虚拟内存文件系统和绑定挂装(第 3 部分)
          o 设备管理文件系统,devfs 的好处(第 4 部分)
          o 开始到 devfs 的转换(第 5 部分)
          o 用 init 封装器完成到 devfs 的转换(第 6 部分)
          o ext3 文件系统的好处(第 7 部分)
          o Ext3 和最新内核更新(第 8 部分)

    * 可以在 SGI 的 XFS 页面上学到更多关于 XFS 的知识。请阅读 FAQ。请加入邮件列表。如果您已经迫不及待,可以直接到下载和安装 XFS,开始摆弄 XFS。

    * 要学习更多关于 XFS 内部的知识,我强烈推荐由 Adam Sweeney、Doug Doucette、Wei Hu、Curtis Anderson、Mike Nishimoto 和 SGI 的 Geoff Peck 编写的“Scalability in the XFS File System”。

    * 请浏览 developerWorks 上的更多 Linux 参考资料。

    * 请浏览 developerWorks 上的更多开放源码参考资料。



关于作者
作者作者 Daniel Robbins 住在美国新墨西哥州的阿尔布开克(Albuquerque)。他是 Gentoo Technologies,Inc. 的总裁兼 CEO、Gentoo Linux(用于 PC 的高级 Linux)的创始人,以及 Portage 系统(Linux 的下一代移植系统)的创始人。他还是 Macmillan 出版的 Caldera OpenLinux Unleashed、SuSE Linux Unleashed 和 Samba Unleashed 等书籍的作者。Daniel 自小学二年级起就与计算机结下不解之缘,那时他首先接触的是 Logo 编程语言,并沉溺于 Pac Man 游戏中。这也许就是他至今仍担任 SONY Electronic Publishing/Psygnosis 的首席图形设计师的原因所在。Daniel 喜欢和妻子 Mary 以及他们的女儿 Hadassah 一起共度时光。可通过 [email protected] 与 Daniel 联系。

cnhnln 发表于 2004-8-2 15:35:00

没有jfs

BOoRFGOnZ 发表于 2004-8-2 15:40:06

收藏

cnhnln 发表于 2004-8-2 16:09:38

性能比较
http://people.freebsdchina.org/million/doc/ext3-reiserfs-jfs-xfs.pdf

cnhnln 发表于 2004-8-2 16:11:01

内容太老了,就像这篇测试一样。不,比这个测试还老,只能作为借鉴
页: [1]
查看完整版本: 高级文件系统实现者指南[转贴]