高级文件系统实现者指南(上)
2010-03-01 10:20:44 阿炯

Daniel Robbins (drobbins@gentoo.org), 总裁/CEO, Gentoo Technologies, Inc

1 部分 日志和 ReiserFS
2001 年 6 月 01 日

伴随着 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 安装的全过程。我们还将仔细地看一看性能调整,应用程序交互作用(和怎么围绕他们工作)以及使用的最佳内核等等。

第 2 部分     使用 ReiserFS 和 Linux 2.4
2001 年 8 月 01 日

随着 Linux 2.4的发行,出现了使用很多新的文件系统的可能性,包括ReiserFS、XFS、GFS和另外一些文件系统。这些文件系统听起来很“酷”,但是它们到底能做些什么呢,它们擅长什么,还有您究竟怎样才能在一个产品Linux 环境中安全地使用它们呢?在本系列文章中,Daniel Robbins通过向您展示怎样在 Linux 2.4下安装这些新的高级文件系统,回答了这些问题。在他的 本系列前面的文章中,Daniel 介绍了日志和 ReiserFS 的好处。在本文中 Daniel将教您安装一个非常稳定的基于 Linux 2.4 的 ReiserFS系统。

在本文中,我会向您展示如何让 ReiserFS 运行在 2.4 系列的内核下。我还会和您分享很多关于不同主题的技术信息,包括使用 ReiserFS 最好的 2.4 内核,性能注意事项等等。因为我首先会谈到安装,所以我建议您先通读本文,然后再遵循安装指示。这样,您开始在自己的系统上运行 ReiserFS 的时候,脑子里就会有所有的技术注解,这样您就可以在各个步骤作必要的调整。

寻找好的内核

要在您的系统上使用 ReiserFS,您首先需要找到一个合适的内核。如果您已经熟悉 2.4 内核的发展,您就会知道这个过程比它听起来要复杂。本文完成时,最新的内核是 2.4.6-pre2;但是我建议您在自己的 ReiserFS 系统上还是使用 2.4.4(标准的 Linus 内核)或者 2.4.4-ac9(稍作改进的 Alan Cox 内核)。从我的测试看来,2.4.5 似乎很不稳定,所以我不推荐将这个内核作为产品使用;让我们希望 2.4.6 会比它好很多吧。

如果您想在自己的产品 ReiserFS 系统中使用除 2.4.4 或 2.4.4-ac9 以外的其它内核, 一定要作必要的检查以确保 ReiserFS(和内核大体上)是稳定的。当然,如果您是在一个测试服务器上安装 ReiserFS,只要不会丢失重要的数据,您就可以随意使用任一种内核。

总的来说,要注意内核稳定性问题,特别是 ReiserFS 的稳定性问题,这有两个原因。因为 ReiserFS 是一个“实验的”内核功能,您不能假定一个使用新内核的 ReiserFs 实现刚刚从 tarball 中解出就能够很好地运行。第二个原因(也许在目前是更重要的问题)在于大部分的 2.4 内核发行版和补丁都有一点不稳定,所以目前您行动时还是需要谨慎一点。理论上,所有的 2.4 发行版都应该是准产品化的,因为 2.4 版本应该是一个稳定的系列;但是,实际上它们(还)不是,所以强烈鼓励您小心使用新的、没有测试过的内核。

这段信息的意思不是要吓得您不敢使用 ReiserFS 或者 Linux 2.4,而是要给那些更敢于冒险的人一点理性。不要总是在重要的系统上使用各种还处于测试期的内核;如果这样,您 会吃到苦头的。当您使用一个不可靠的内核时,您不仅仅面临着系统锁定的危险;您还面临着丢失数据和文件系统崩溃的危险,这是您绝对不希望发生的。即便 ReiserFS 实现本身是稳定的,内核其他部分的主要错误也很可能引起文件系统崩溃的产生。

如果您没有最新的内核稳定性信息来源,我建议您定期地访问 Linux 每周新闻(请参阅本文后面的 参考资料),及时了解最新的可能出现的内核问题(信息每个星期四更新)。希望现在我已经说服了更多喜欢冒险的读者坚持使用 2.4.4 或 2.4.4-ac9 内核作为产品 ReiserFS 的配置,让我们继续吧。

标准内核

OK,我们现在可以谈谈安装和运行一个准产品化的 ReiserFS 系统的三种选择。第一种选择是只用标准 2.4.4 Linux 内核。第二种选择是使用 2.4.4 内核,同时使用 ReiserFS 大补丁,它包括了一些专门的补丁,使 ReiserFS 达到配额兼容,并与在本机运行的 NFS 服务器更加兼容。第三种选择是,我们可以使用 2.4.4 内核和 ac9 补丁(即 2.4.4-ac9),再加上或不加大补丁。通常我推荐使用 2.4.4-ac9 和大补丁,因为大补丁并没有任何负作用,而且您可能会需要它,而且 ac9 比标准内核执行得好多了。但是,如果您不愿意使用 ac 内核,标准 2.4.4 也不错了。我会简单地向您介绍设置 2.4.4-ac9 和大补丁的步骤,但是如果因为某些原因您不愿安装这两个补丁或其中之一,只要跳过这个步骤即可。现在,让我们开始吧。

首先,从 kernel.org 下载 2.4.4 内核源码并进入您的 /usr/src 目录。 移去该处的任何 linux 目录或者符号连接,如果是目录就将其改名,如果是符号连接就只需删除它。然后:
# cd /usr/src
# cat /path/to/linx-2.4.4.tar.bz2 | bzip2 -d | tar xvf -

ac9 补丁和大补丁

如果您计划只用标准 2.4.4 内核,您就已经拥有全部所需的资源了,可以跳过其余的补丁。然而,我推荐您继续使用下面的 ac 补丁和大补丁。

要使用 ac9 补丁,请从 kernel.org 下载 Alan Cox ac9 补丁。然后键入:
# cd /usr/src/linux
# bzip2 -dc /path/to/patch-2.4.4-ac9.bz2 | patch -p1

一旦标准内核安装完毕,就到 DiCE 网站去下载 DiCE 的 ReiserFS 大补丁。这个步骤还是可选的,不过也是推荐的,特别是如果您将在此系统上运行 NFS 服务器或者需要配额(如果不是这样,无论如何这个补丁也不会有什么坏处)。要使用大补丁请遵循以下步骤:
# cd /usr/src/linux
# bzip2 -dc /path/to/bigpatch-2.4.4.diff.bz2 | patch -p1

一旦所有可选的修正和大补丁安装完毕,您就可以为 ReiserFS 配置内核了。

注意:如果您需要更多关于如何编译 Linux 内核的指导,可参阅 developerWorks上的 编译 Linux 内核免费教程。下面是一个简单的摘要。

配置内核非常简单。首先,键入“make menuconfig”。在“Code maturity level options”部分,确保启用了“Prompt for development and/or incomplete code/drivers”选项。然后到“File systems”部分,启用“ReiserFS support”选项。 您将 ReiserFS 设置为直接编译到内核中(而不是作为一种模块);而且通常启用“Have reiserFS do extra internal checking”这个选项不是什么好主意。现在,保存您的设置,编译您的内核(“make dep;make bzImage;make modules;make modules_install”),然后配置您的引导装载器(boot loader)来装载新的配置了 ReiserFS 的内核。

重点:保存当前内核并配置引导装载器(boot loader)总是个好主意,这样万一您的新内核无法工作,您就可以用原来的内核启动。

使用 ReiserFS

安装工具

在重新启动之前,我们需要安装“reiserfsprogs”工具,它包括了“mkreiserfs”、“resize_reiserfs”(对 LVM 用户很有用),还有“fsck.reiserfs”。您可以从 Namesys.com 下载页下载最新版本的“reiserfsprogs”(目前是“3.x.0j”)。一旦这些工具下载完毕,您就可以按以下步骤编译和安装“reiserfsprogs”了:
# cd /tmp
# tar xzvf reiserfsprogs-3.x.0j.tar.gz
# cd reiserfsprogs-3.x.0j
# ./configure
./configure output will appear here
# make
make output will appear here
# make install
make install output will appear here

既然工具已经安装完毕,现在您可以按需要创建任何新的分区(使用“fdisk”或者“cfdisk”)或 LVM 逻辑卷(使用“lvcreate”)并重新启动您的系统。如果您正在创建标准分区,您可以简单地将此分区标记为一个“Linux native file system”(83)。

创建和安装文件系统

重新启动后,您就可以在一个空的分区上创建 ReiserFS 文件系统,如下所示:
# mkreiserfs /dev/
hdxy

在上面的示例中,/dev/hdxy 应该是对应于一个空闲分区的设备节点。象安装其它文件系统一样安装它:
# mount /dev/
hdxy
/mnt/reiser

而且,如果您想在自己的 /etc/fstab 文件中添加一个 ReiserFS 文件系统,只需将“freq”和“passno”字段设置为“0”,如下所示:
/dev/hdc1       /home                   reiserfs        defaults       0 0

从这以后,您的 ReiserFS 文件系统应该不比它的对手 ext2 逊色了,而且您再也不必担心长时间的“fsck”,整体性能也会好得多 ― 特别是对于小文件来说。

ReiserFS 技术注解

文件系统稳定性

我已经在一个产品环境下使用了一个多月 2.4.4 版本内核的 ReiserFS(在 cvs.gentoo.org 开发服务器上),根本没有什么崩溃问题。2.4.4 和 2.4.4-ac9 已经非常稳定了。我们的服务器执行大量的磁盘 IO 任务,因为它是我们的 cvs 资料档案库、 gentoo.org 邮件服务器、基于邮差的邮件列表,还有很多其他东西的所在之处。

ReiserFS 的局限性

虽然 ReiserFS 在几乎每一种类型的应用程序上都比 ext2 文件系统表现得好,有些地方 ReiserFS 目前还是有点欠缺。令人欣慰的是,这些问题其实并不是 ReiserFS 无法克服的局限性,只是 Namesys 开发人员还没有来得及编码或优化的地方。

没有 dump/restore

是的,这是真的;ReiserFS 没有“dump”和“restore”实现。如果您想使用 ReiserFS 又碰巧是个喜欢使用“dump”的人,您就必须寻找备份数据的其他方法。实际上,事实证明这个根本就不是问题,因为 2.4 系列内核从一开始就不兼容“dump”和“restore”命令。要了解关于 dump 和 2.4 内核的不兼容性的更多信息,请阅读 Linus Torvalds 的帖子(请参阅 参考资料),他在帖子中说道“Dump 从一开始就是个愚蠢的程序。不要去碰它。”

性能问题

虽然 ReiserFS 通常抢尽了 ext2 的风头,但它在特定情况下确实有性能上的不足之处。第一个就是处理稀疏文件的能力。ReiserFS 处理稀疏文件的能力 会比 ext2 差很多。当 Namesys 开发人员一直设法为 ReiserFS 4 优化 ReiserFS 的这一部分时,这一点会有所改观。在这之前,ext2 是对处理稀疏文件有很高要求的应用程序的较好的解决方案。

在对大量文件执行多个 stat() 调用的代码中,可能也会碰到问题。一个可能触发这种性能缺陷的应用程序(它只存在于 2.4 系列内核的 ReiserFS 实现,在 2.2 内核中不存在)就是“mutt”邮件用户代理(请参阅 参考资料),它在被用于读取大型 maildir 形式的邮箱时会触发性能缺陷。显然,每个邮件文件 mutt 都要 stat 两次,这样就会比平常更加影响性能。ReiserFS 开发小组已经意识到了这个特殊的问题,并已经确定了它的起因,如果近期没有解决方案的话,您应该可以在 ReiserFS 4 中看到相应的解决方案。

性能调整

幸运的是,有几种简单通用的性能调整方法可以用来缓解这些问题。第一种是用“noatime”选项(一种对 ReiserFS 和其它文件系统都有用的安装选项)来安装您的 ReiserFS 文件系统。您可能知道,UNIX 系统为文件系统上的每一个对象记录一个 atime,或称为访问时间,每次读取文件时,atime 都会被更新。对于大部分人来说,atime 邮戳功能不是十分有用,而且几乎没有任何应用程序(我想不到一个)依靠 atime 处理什么重要的任务。出于这个原因,通常可以安全地关掉它,这样可以带来一个很好的全面性能提升。通常情况下,除非您确实知道自己需要 atime 支持,您还是应该用 noatime 选项来安装文件系统。使用如下所示的 /etc/fstab 条目:
/dev/hdc1       /home                   reiserfs        noatime       0 0

在关于ReiserFS 的第一篇文章中,我曾提到 ReiserFS 有一项特别的功能,称为“tail packing”。在 ReiserFS 术语中,“tail”是小于一个系统文件块(4k)的文件,或不能填满一个完整的文件系统块的文件末尾部分。ReiserFS 具有确实卓越的小文件处理性能是因为它能够将这些 tail 合并到它的 b*tree(它的主要数据组织结构)中去,这样它们就能真正地接近 stat-data(ReiserFS 中等同于索引节点的单元)。然而,因为这些 tail 不能填满一个完整的块,它们会浪费很多磁盘空间(当然是相对地说)。为了解决这个问题,ReiserFS 使用了它的“tail packing”功能来将这些 tail 压缩到占用尽可能小的空间。通常,这么做可以让 ReiserFS 文件系统比大小相等的 ext2 文件系统多容纳大约 5% 的数据。

更多关于 notail 的内容

然而,tail packing 也有它的缺点。首先,它的确给性能带来了一个小却不可忽视的冲击。幸运的是,ReiserFS 开发人员已经预计到有些人宁愿牺牲大约 5%的磁盘空间换取一点额外的性能,所以他们创建了“notail”安装选项。当文件系统用这个选项安装时,tail packing 将被关闭,使您的存储容量减小,却有更快的速度。通常,重视文件系统性能的狂热分子同时启用“notail”和“noatime”选项来安装他们的文件系统,从而带来显著的性能提升:
/dev/hdc1       /home                   reiserfs        noatime,notail       0 0

即便您想节省一点磁盘空间,有时候暂时用一下“notail”选项安装文件系统也是件好事。特别是,大多数引导装载器(boot loader)装载一个在启用 tail packing 的 ReiserFS 文件系统上创建的内核时,都会出现问题。如果您正在使用一个比版本 21.6 还低的 LILO,您就会碰到这种问题。在使用最新版本的 GRUB 时也会碰到问题,即不能装载它的 stage1 和 stage1_5 文件,尽管在装载实际内核的时候没有什么问题。如果您已经在经历这种问题了,您可以这样修正此问题-使用“notail”选项安装文件系统,将文件移到另一个文件系统中,然后再把它们移回来。当文件被重新创建时,就不会有 tail 了。另外,记住您还可以很轻易地 重新安装文件系统(用新选项),而不需要卸载它。这个特别的示例使用“notail”选项重新安装根目录文件系统。通常情况下,如果您想使用 tail packing,但也需要引导装载器(boot loader)从根目录文件系统装载辅助文件(如内核),这条命令就很有用了:
# mount / -o remount,notail

Qmail 注解

如果您正在 ReiserFS 中使用 qmail,您应该了解一些重要的参考资料。首先,您应该使用 qmail 1.03 源码的补丁。它修正了 qmail 非同步调用“link()”和“unlink()”时出现的问题,它不但是 ReiserFS 的问题,恰好也是 ext2 的问题。接下来您应该看看 Jedi 的 qmail 调优页面,它包含了很多关于怎样尽可能发挥 qmail 性能的很好的建议。最后,请务必查看 Jedi 的 ReiserSMTP 软件包。ReiserSMTP 包含一个 GPL 插件来代替 qmail 的 SMTP 部分;Jedi 的这种替换是特别为 ReiserFS 调整的,依赖新的队列处理例程,它可以给您带来双倍的邮件收取性能。

结论

我发现 ReiserFS 真是一个不可思议的文件系统,它提供了很好的小文件处理性能和非常好的(通常比 ext2 要好)的常规文件处理性能。因为有了 ReiserFS,我的开发人员可以在仅仅 15 秒内完成 Gentoo Linux “cvs” 更新,而使用 ext2 通常要花大约两分钟时间。ReiserFS 使我们开发人员的生活更加愉快,还使我们的 cvs 服务器处理大量的并发 IO 而不会引起硬盘狂转和对交互性能的负面影响。

然而除了所有这些,关于 ReiserFS 最激动人心的地方是它将来的发展方向。Hans Reiser 对 ReiserFS 有一个非常激进而创新的计划,包括计划扩展文件系统从而能够将其作为一个发展成熟的高性能数据库来使用,最后还包括事务支持和高级查询功能。这意味 ReiserFS 将不仅仅“只是另一个高性能文件系统”;相反,它将开拓新的可能和道路,使我们能够用创新方式去解决传统的存储问题。有了 Namesys 的合作,Linux 将来的发展一定会非常激动人心 -这绝对是一件好事情。

第3部分       使用虚拟内存(virtual memory,VM)文件系统和绑定安装
2001 年 9 月 01 日

伴随着 Linux 2.4 版本的发行,出现了大量的文件系统可能性,其中包括 ReiserFS、XFS、GFS 和其它文件系统。这些文件系统听起来的确都很酷,但是它们真正能做些什么呢,擅长在哪些方面,以及在 Linux 产品环境下如何才能安全地使用它们呢?Daniel Robbins 通过向您展示如何在 Linux 2.4 的环境下建立这些新的高级文件系统来回答以上的问题。在这个部分,Daniel 简单地介绍了 tmpfs,一个基于 VM 的文件系统,还向您介绍了 2.4 版本的“绑定”安装功能带来的新的可能。

在本系列我以前的文章中,我 介绍了创建日志和使用 ReiserFS 的好处,并 展示了如何安装一个稳固的基于 Linux 2.4 的 ReiserFS 系统。在本文中,我们要谈论几个相对次要的主题。首先,我们会简单地介绍一下 tmpfs,也就是我们知道的虚拟内存(virtual memory,VM)文件系统。Tmpfs 可能是现在 Linux 可以使用的最好的类似于 RAM 磁盘的系统,而且是 2.4 内核的一个新功能。然后,我们将简单地介绍另一个 2.4 内核的新功能,叫做“绑定安装”,它在安装(和重新安装)文件系统的时候带来了很大的灵活性。在下一篇文章中,我们会把重点集中在 devfs 上,之后,我们会花点时间来进一步熟悉新的 ext3 文件系统。

介绍 tmpfs

如果我必须一下子说清楚 tmpfs,我会说 tmpfs 就象虚拟磁盘(ramdisk),但不一样。象虚拟磁盘一样,tmpfs 可以使用您的 RAM,但它也可以使用您的交换分区来存储。而且传统的虚拟磁盘是个块设备,并需要一个 mkfs 之类的命令才能真正地使用它,tmpfs 是一个文件系统,而不是块设备;您只是安装它,它就可以使用了。总而言之,这让 tmpfs 成为我有机会遇到的最好的基于 RAM 的文件系统。

tmpfs 和 VM

让我们来看看 tmpfs 更有趣的一些特性吧。正如我前面提到的一样,tmpfs 既可以使用 RAM, 也可以使用交换分区。刚开始这看起来可能有点武断,但请记住 tmpfs 也是我们知道的“虚拟内存文件系统”。而且,您可能也知道,Linux 内核的虚拟内存资源同时来源于您的 RAM 和交换分区。内核中的 VM 子系统将这些资源分配到系统中的其它部分,并负责在后台管理这些资源,通常是透明地将 RAM 页移动到交换分区或从交换分区到 RAM 页。

tmpfs 文件系统需要 VM 子系统的页面来存储文件。tmpfs 自己并不知道这些页面是在交换分区还是在 RAM 中;做这种决定是 VM 子系统的工作。tmpfs 文件系统所知道的就是它正在使用某种形式的虚拟内存。

不是块设备

这里是 tmpfs 文件系统另一个有趣的特性。不同于大多数“标准的”文件系统,如 ext3、ext2、XFS、JFS、ReiserFS 和其它一些系统,tmpfs 并不是存在于一个底层块设备上面。因为 tmpfs 是直接建立在 VM 之上的,您用一个简单的 mount 命令就可以创建 tmpfs 文件系统了。
# mount tmpfs /mnt/tmpfs -t tmpfs

执行这个命令之后,一个新的 tmpfs 文件系统就安装在 /mnt/tmpfs,随时可以使用。注意,不需运行 mkfs.tmpfs ;事实上,那是不可能的,因为没有这样的命令存在。在 mount 命令执行之后,文件系统立即就被安装并且可以使用了,类型是 tmpfs 。这和 Linux 虚拟磁盘如何使用大相径庭;标准的 Linux 虚拟磁盘是 块设备,所以在使用它们之前必须用您选择的文件系统将其格式化。相反,tmpfs 是一个文件系统。所以,您可以简单地安装它就可以使用了。

Tmpfs 的优势

动态文件系统的大小

您可能想知道我们前面在 /mnt/tmpfs 安装的 tmpfs 文件系统有多大。这个问题的答案有点意外,特别是在和基于磁盘的文件系统比较的时候。/mnt/tmpfs 最初会只有很小的空间,但随着文件的复制和创建,tmpfs 文件系统驱动程序会分配更多的 VM,并按照需求动态地增加文件系统的空间。而且,当 /mnt/tmpfs 中的文件被删除时,tmpfs 文件系统驱动程序会动态地减小文件系统并释放 VM 资源,这样做可以将 VM 返回到循环当中以供系统中其它部分按需要使用。因为 VM 是宝贵的资源,所以您一定不希望任何东西浪费超出它实际所需的 VM,tmpfs 的好处之一就在于这些都是自动处理的。 请参阅 参考资料。

速度

tmpfs 的另一个主要的好处是它闪电般的速度。因为典型的 tmpfs 文件系统会完全驻留在 RAM 中,读写几乎可以是瞬间的。即使用了一些交换分区,性能仍然是卓越的,当更多空闲的 VM 资源可以使用时,这部分 tmpfs 文件系统会被移动到 RAM 中去。让 VM 子系统自动地移动部分 tmpfs 文件系统到交换分区实际上对性能上是 好的,因为这样做可以让 VM 子系统为需要 RAM 的进程释放空间。这一点连同它动态调整大小的能力,比选择使用传统的 RAM 磁盘可以让操作系统有好得多的整体性能和灵活性。

没有持久性

这看起来可能不象是个积极因素,tmpfs 数据在重新启动之后不会保留,因为虚拟内存本质上就是易失的。我想您可能猜到了 tmpfs 被称为“tmpfs”的一个原因,不是吗?然而,这实际上可以是一件好事。它让 tmpfs 成为一个保存您不需保留的数据(如临时文件,可以在 /tmp 中找到,还有 /var 文件系统树的某些部分)的卓越的文件系统。

使用 tmpfs

为了使用 tmpfs,您所需要的就是启用了“Virtual memory file system support(以前是 shm fs)”选项的 2.4 系列内核;这个选项在内核配置选项的“File systems”部分。一旦您有了一个启用了 tmpfs 的内核,您就可以开始安装 tmpfs 文件系统了。其实,在您所有的 2.4 内核中都打开 tmpfs 选项是个好主意,不管您是否计划使用 tmpfs。这是因为您需要内核 tmpfs 支持来使用 POSIX 共享的内存。然而, System V共享的内存不需要内核中有 tmpfs 就 可以工作。注意,您 不需要为了让 POSIX 共享的内存工作而安装 tmpfs 文件系统;您只需要在内核中支持 tmpfs 就可以了。POSIX 共享的内存现在使用得不太多,但这种情况可能会随着时间而改变。

避免低 VM 情况

tmpfs 根据需要动态增大或减小的事实让人疑惑:如果您的 tmpfs 文件系统增大到它耗尽了 所有虚拟内存的程度,而您没有剩余的 RAM 或交换分区,这时会发生什么?一般来说,这种情况是有点讨厌。如果是 2.4.4 内核,内核会立即锁定。如果是 2.4.6 内核,VM 子系统已经以很多种方式得到了修正,虽然耗尽 VM 并不是一个美好的经历,事情也不会完全地失败。如果 2.4.6 内核到了无法分配更多 VM 的程度,您显然不愿意不能向 tmpfs 文件系统写任何新数据。另外,可能会发生其他一些事情。首先,系统的其他一些进程会无法分配更多的内存;通常,这意味着系统多半会变得 极度缓慢而且几乎没有响应。这样,超级用户要采取必要的步骤来缓解这种低 VM 的情况就会很困难,或异常地耗时。

另外,内核有一个内建的最终防线系统,用来在没有可用内存的时候释放内存,它会找到占用 VM 资源的进程并终止该进程。不幸的是,这种“终止进程”的解决方案在 tmpfs 的使用增加引起 VM 耗尽的情况下通常会导致不良后果。以下是原因。tmpfs 本身不能(也不应该)被终止,因为它是内核的一部分而非一个用户进程,而且也没有容易的方法可以让内核找出是那个进程占满了 tmpfs 文件系统。所以,内核会错误地攻击它能找到的最大的占用 VM 的进程,通常会是 X 服务器(X server),如果您碰巧在使用它。所以,您的 X 服务器会被终止,而引起低 VM 情况的根本原因(tmpfs)却没有被解决。Ick.

低 VM:解决方案

幸运的是,tmpfs 允许您在安装或重新安装文件系统的时候指定文件系统容量的最大值上限。实际上,从 2.4.6 内核到 2.11g 内核,这些参数只能在 安装时设置,而不是重新安装时,但我们可以期望在不久的将来可以在重新安装时设置这些参数。tmpfs 容量最大值的最佳设置依赖于资源和您特定的 Linux 主机的使用模式;这个想法是要防止一个完全使用资源的 tmpfs 文件系统耗尽所有虚拟内存结果导致我们前面谈到的糟糕的低 VM 情况。寻找好的 tmpfs 上限值的一个好方法是使用 top 来监控您系统的交换分区在高峰使用阶段的使用情况。然后,确保指定的 tmpfs 上限稍小于所有这些高峰使用时间内空闲交换分区和空闲 RAM 的总和。

创建有最大容量的 tmpfs 文件系统很容易。要创建一个新的最大 32 MB 的 tmpfs 文件系统,请键入:
# mount tmpfs /dev/shm -t tmpfs -o size=32m

这次,我们没有把 tmpfs 文件系统安装在 /mnt/tmpfs,而是创建在 /dev/shm,这正好是 tmpfs 文件系统的“正式”安装点。如果您正好在使用 devfs,您会发现这个目录已经为您创建好了。

还有,如果我们想将文件系统的容量限制在 512 KB 或 1 GB 以内,我们可以分别指定 size=512k 和 size=1g 。除了限制容量,我们还可以通过指定 nr_inodes=x 参数限制索引节点(文件系统对象)。在使用 nr_inodes 时, x 可以是一个简单的整数,后面还可以跟一个 k 、 m 或 g 指定千、百万或十亿(!)个索引节点。而且,如果您想把上面的 mount tmpfs 命令的等价功能添加到 /etc/fstab,应该是这样:
tmpfs      /dev/shm tmpfs      size=32m 0     0

在现存的安装点上安装

在以前使用 2.2 的时候,试图在 已经安装了东西的安装点再次安装任何东西都会引发错误。然而,重写后的内核安装代码使多次使用安装点不再成为问题。这里是一个示例的情况:假设我们有一个现存的文件系统安装在 /tmp。然而,我们决定要开始使用 tmpfs 进行 /tmp 的存储。过去,您唯一的选择就是卸载 /tmp 并在其位置重新安装您新的 tmpfs/tmp 文件系统,如下所示:
#  umount /tmp
#  mount tmpfs /tmp -t tmpfs -o size=64m

可是,这种解决方案也许对您不管用。可能有很多正在运行的进程在 /tmp 中有打开的文件;如果是这样,在试图卸载 /tmp 时,您就会遇到如下的错误:
umount: /tmp: device is busy

然而,使用最近的 2.4 内核,您可以安装您新的 /tmp 文件系统,而不会遇到“device is busy”错误:
# mount tmpfs /tmp -t tmpfs -o size=64m

用一条命令,您新的 tmpfs /tmp 文件系统就被安装在 /tmp,并安装在已经安装的不能再被直接访问的分区 之上。然而,虽然您不能访问原来的 /tmp,任何在原文件系统上还有打开文件的进程都可以继续访问它们。而且,如果您 unmount 基于 tmpfs 的 /tmp,原来安装的 /tmp 文件系统会重新出现。实际上,您在相同的安装点上可以安装任意数目的文件系统,安装点就象一个堆栈;卸载当前的文件系统,上一个最近安装的文件系统就会重新出现。

绑定安装

使用绑定安装,我们可以将所有甚至 部分已经安装的文件系统安装到另一个位置,而在两个安装点可以同时访问该文件系统。例如,您可以使用绑定安装来安装您现存的根文件系统到 /home/drobbins/nifty,如下所示:
#  mount --bind / /home/drobbins/nifty

现在,如果您观察 /home/drobbins/nifty 的内部,您就会看到您的根文件系统(/home/drobbins/nifty/etc、/home/drobbins/nifty/opt 等)。而且,如果您在根文件系统修改文件,您在 /home/drobbins/nifty 中也可以看到所作的改动。这是因为它们是同一个文件系统;内核只是简单地为我们将该文件系统映射到两个不同的安装点。注意,当您在另一处安装文件系统时,任何安装在绑定安装文件系统 内部的安装点的文件系统都不会随之移动。换句话说,如果您在单独的文件系统上有 /usr,我们前面执行的绑定安装就会让 /home/drobbins/nifty/usr 为空。您会需要附加的绑定安装命令来使您能够浏览位于 /home/drobbins/nifty/usr 的 /usr 的内容:
#  mount --bind /usr /home/drobbins/nifty/usr

绑定安装部分文件系统

绑定安装让更妙的事情成为可能。假设您有一个 tmpfs 文件系统安装在它的传统位置 /dev/shm,您决定要开始在当前位于根文件系统的 /tmp 使用 tmpfs。虽然可以在 /tmp(这是可能的)安装一个新的 tmpfs 文件系统,您也可以决定让新的 /tmp 共享当前安装的 /dev/shm 文件系统。然而,虽然您可以在 /tmp 绑定安装 /dev/shm 就完成了,但您的 /dev/shm 还包含一些您不想在 /tmp 出现的目录。所以,您怎么做呢?这样如何:
# mkdir /dev/shm/tmp
# chmod 1777 /dev/shm/tmp
# mount --bind /dev/shm/tmp /tmp

在这个示例中,我们首先创建了一个 /dev/shm/tmp 目录,然后给它 1777 权限,对 /tmp 适当的许可。既然我们的目录已经准备好了,我们可以安装,也只能安装 /dev/shm/tmp 到 /tmp。所以,虽然 /tmp/foo 会映射到 /dev/shm/tmp/foo,但您没有办法从 /tmp 访问 /dev/shm/bar 文件。

正如您所见,绑定安装非常强大,让您可以轻易地修改文件系统设计,丝毫不必忙乱。下一篇文章,我们会谈到 devfs,至于现在,您也许会想看看下面的参考资料。

第 4 部分     介绍 devfs
2001 年 9 月 01 日

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

介绍 devfs

设备,到处都是设备

Devfs,也叫设备文件系统(Device Filesystem),设计它的唯一目的就是提供一个新的(更理性的)方式管理通常位于 /dev 的所有块设备和字符设备。您也许知道,典型的 /dev 树包含数百个块特殊文件和字符特殊文件,它们全都在根文件系统上。每个特殊文件都可以让用户空间进程轻松地与内核设备实现交互。举例来说,通过对这些特殊文件执行操作,您的 X 服务器就能够访问视频硬件, fsck 可以执行文件系统检验, lpd 可以通过并行端口向打印机发送数据。

实际上,通常 Linux 和 Unix 更“酷”的方面是,设备不是简单地隐藏在晦涩的 API 之后,而是真正地与普通文件、目录和符号链接一样存在于文件系统上。因为字符和块设备是映射到普通文件系统名称空间的,我们通常可以用有意义的方式来与硬件交互,可以仅使用标准 Unix 命令,如 cat 和 dd。除了有趣之外,这还使我们有更强的能力,并提高生产力。

设备管理问题

然而,虽然设备特殊文件本身是一件好事情,但典型的 Linux 系统以一种不太理想而且麻烦的方式管理这些特殊文件。 如今,Linux 支持 很多不同种类的硬件。这意味着严格意义上我们中绝大多数在 /dev 中都有数百个特殊文件来表示所有这些设备。还不止这样,这些特殊文件中大多数甚至不会映射到系统中存在的设备上(但需要它们存在,只是考虑到我们最终会在系统中添加新的硬件/驱动器),这让事情变得更令人困惑。

仅从这个方面来看,我们就知道 /dev 需要彻底检修,而创建 devfs 的明确目的就是让 /dev 变回原形。为了很好地理解 devfs 是怎样解决绝大多数 /dev 管理问题的,我们从设备驱动程序的角度来看看 devfs。

设备管理内幕

为了很好地理解 devfs ,最好是先理解从设备驱动程序的角度来看 devfs 是怎样改变事物的。传统地(不使用 devfs),根据是否注册在 块设备或 字符设备,基于内核的设备驱动程序通过调用 register_blkdev()或 register_chrdev() 向系统的其余部分注册设备。

您必须提供一个 主设备号(一个无符号 8 位整数)作为 register_blkdev()或 register_chrdev() 的参数;然后,在设备注册之后,内核就会知道这个特定的主设备号对应于执行 register_--?dev()调用的特定设备驱动程序。

那么,设备驱动程序开发人员为调用 register_--?dev() 提供的主设备号 应该是什么呢?如果开发人员不打算将设备驱动程序与外界共享,那么什么号码都可以,只要它与当前内核使用的其它主设备号都不冲突即可。开发人员还可以选择动态地分配 register_--?dev() 调用的设备的主设备号。然而,这样的解决方案通常只是在驱动程序不会被其它人使用的情况下可行。

获取号码

然而,如果开发人员想让驱动程序与外界共享(大多数 Linux 开发人员常常采用这一方法),那么仅仅从“真空”中抽一个主设备号或者使用动态的主设备号分配就不行了。相反,开发人员必须联系 Linux 内核开发人员,这样他(她)的特定的设备才能分配一个“正式”主设备号。那么,在整个 Linux 世界中,这个特定的设备(也 只有这个设备)才会被关联到那个特定的主设备号。

有一个“正式的”主设备号很重要,因为要与特定的设备交互,管理员必须在 /dev 创建一个特殊文件。当设备节点(特殊文件)创建后,它使用的主设备号必须同内核内部使用的完全相同。这样,进程对设备执行操作时,内核就会知道应该引用什么设备驱动程序。让特殊文件到内核驱动程序的映射成为可能的是主设备号,而不是真实的设备名称(它和非 devfs 系统无关)。

一旦设备驱动程序具备正式主设备号,设备就可以被公开使用了,设备节点也就可以开始并入不同分发版的 /dev 树,还有它们的正式 /dev/MAKEDEV 脚本(用来帮助超级用户用正确的主从设备号、权限和所有权创建设备节点的特殊脚本)中。

传统的问题

不幸的是,这种方法有很多可伸缩性问题。不仅设备驱动程序开发人员联系内核开发人员来获取正式主设备号是一件讨厌的事,内核开发人员弄清他们怎样分配所有这些主设备号甚至更加恼人。这种任务在很多方面很象系统管理员跟踪公司局域网静态 IP 地址分配的工作 ― 这并不十分有趣。正如系统管理员可以利用 DHCP 来缓解这种管理负担,如果设备注册有某种类似的方法就好了。

不只是这样,Linux 还正在耗尽主设备号和副号码。虽然这种问题可以通过简单地扩展主设备号和副号码使用的位数,首先维护这些主设备号映射就很讨厌了,所以我们又在考虑有没有更好的方法来处理这些事情。幸运的是,有这样的方法;进入 devfs。

进入 devfs

devfs_register()

这里是对 devfs 如何一下子处理事情和解决这些问题的一个简单明了的快速纲要。一旦 devfs 被正确配置(包括在内核添加 devfs 支持和对启动脚本进行一些稍复杂的更改),超级用户重新启动系统。然后内核开始启动,设备驱动程序开始向系统的剩余部分注册设备。您会记起在非 devfs 系统上, register_blkdev()和 register_chrdev() 调用(连同提供的主设备号)正是用于这一目的。然而,现在启用了 devfs,设备驱动程序是用一种新的、改进了的内核调用来注册设备,称为 devfs_register()。

这里是 devfs_register() 调用有趣的地方。虽然为了兼容性目的指定主设备号和副号码作为参数是可能的,但不再需要这样了。相反, devfs_register()调用接受 设备路径(就是它在 /dev 下可能的出现形式)作为参数。举例来说,假设 foo 设备驱动程序希望使用 devfs 注册设备。它会提供一个 foo0 的参数给 devfs_register(),从而告诉内核应该在 devfs 名称空间的根目录创建一个新的 foo0 设备。相应的, devfs_register() 在 devfs 名称空间的根目录添加 foo0设备节点,并记录这个新的 foo0 节点应该映射到内核中的 foo设备驱动程序。

运行的 Devfs

一旦所有设备驱动程序启动并向内核注册适当的设备,内核就启动 /sbin/init 和系统初始化脚本开始执行。在启动过程初期(在文件系统检查前),rc 脚本将 devfs 文件系统安装在 /dev 中,/dev 包含了 devfs 名称空间的表达。这意味着在安装 /dev 后,所有注册的设备(如上面的 /dev/foo0)都可以访问,就象在非 devfs 上一样。当它们被访问时,内核 通过 devfs 设备名称映射到合适的设备驱动程序,而不是通过主设备号。

这种系统的优点是,所有需要的设备节点(没有别的了)都由内核自动创建。这不仅仅意味着不再需要 MAKEDEV(因为所有注册的设备都只“出现”在 /dev 中),还意味着 /dev 不再被成百个“无用的”设备节点所充斥。实际上,使用 devfs,您可以只要查看 /dev 就知道系统上有什么设备。所以,如果您有一台支持热插拔的膝上型电脑,这意味着您甚至可以在您从系统中插入和拔出 PC 卡时魔术般地让设备从 /dev 中出现和消失。这让 devfs 成为对以前笨拙局面的一个非常彻底和实用的解决方案。

devfs 的优点

Devfs 让很多事变得容易许多。请考虑一下创建一张 Linux 可引导光盘的问题,它包括一个位于 CD 上的引导装载器、一个 initrd、一个内核和一个回送文件系统。当 CD 引导时,引导装载器装载内核和 initrd,然后内核执行 initrd 上的 /linuxrc脚本。 /linuxrc 的主要任务是安装 CD,从而使回送文件系统本身也可以被安装和访问。

没有 devfs, linuxrc 就需要“查看” /dev 中的很多特殊文件,它们可能有也可能没有表示连接到系统的真实硬件。例如, linuxrc 会需要检测 /dev/hdc、/dev/scd0、/dev/hdb 和其它的设备以检测“活动的”光盘驱动器设备。在检测进程中,很可能命中几个“无用的”设备节点。

然而,使用 devfs, linuxrc 只在 /dev/cdroms 中寻找,它包含了系统中所有和 活动的光盘驱动器相关联的特殊文件,不管是 IDE 的还是 SCSI 的。由于这种便捷的新式 devfs 约定,再不需要猜测了;只有活动的设备才会列出,而且设备检测代码甚至不必担心底层的光盘驱动器的细节,比如说它使用什么 IDE 通道或者什么 SCSI ID。实际上,这是 devfs 的另一个主要好处;在我下一篇文章中,我们会看到 devfs 下 /dev 中的设备有全新的缺省位置。

实际上,如果您想访问一个特定的块设备(如磁盘、分区、光盘驱动器等等),事实上有 几个不同的特殊文件可以引用。例如,我的服务器只有一个 SCSI 光盘驱动器;如果启用了 devfs,我就可以通过安装 /dev/cdroms/cdrom0 或 /dev/scsi/host0/bus0/target4/lun0/cd 访问它。两种都引用同一个设备,我可以引用我认为最方便的特殊文件。如果愿意,我还可以使用一种老式的设备名称(/dev/sr0)访问光盘驱动器,这都是因为有一个非常便捷的叫 devfsd的小程序。 devfsd 是一个有功能很多的程序,它负责创建老式的“兼容性”特殊文件,还允许您以很多种方式自定义 /dev。在我的下一篇文章中,我们会详细讨论 devfsd,到时我会一直引导您启动 devfs 并在您自己的系统上运行它。在那之前,请参考下面的参考资料以了解更多关于 devfs 的信息。

第5部分       设置 devfs
2001 年 10 月 01 日

Linux 2.4 发行版能支持很多新的文件系统,包括 Reiserfs、XFS、GFS和其它文件系统。这些文件系统听起来不错,但它们到底能做什么,擅长做什么,又如何在 Linux 生产环境中,安全地着手使用这些文件系统呢?Daniel Robbins 通过演示如何在 Linux 2.4 系统下,安装这些新的高级文件系统来回答这些问题。在这部分中,Daniel 将带您经历为系统准备 devfs 的整个过程。阅读完本文,将可以在系统上启用 devfs;在下一篇文章里 Daniel Robbins 将介绍 devfs 最终安装的细节。

在上一部分(第 4 部分)中,我们具体讨论了什么是 devfs,以及它是如何解决几乎所有的设备管理问题的。现在是在您的系统上启动和运行 devfs 的时候了。 在本文中,我们将使您的系统为启用 devfs 作好准备,在下篇文章中,我们将真正开始向 devfs 的转换。即使在 devfs 的下一篇(也是最后一篇)出版以前,您也完全可以遵循本文中的步骤,因为当我们完成了所有这些步骤之后,您的系统将仍旧继续正常运行 ― 它仅仅为即将来临的 devfs 转换作好了准备。因此,没有必要因为后继文章还未出现而不遵循这些步骤。

请注意: 因为我们将对 Linux 系统的几个部分作出相当大的更改,所以确实可能搞糟您的系统。因此,如果您在对 Linux 系统内部更改方面没有经验的话,毫无疑问您应该在一个无关紧要的 Linux 机器上这样做,至少第一次应该这样。

需求

要启动和运行 devfs,需要使用 Linux 2.4 的一些版本(2.4.6 或 2.4.8 就不错)以及 glibc 2.1.3 或更高版本。还建议您使用 Xfree86 4.0 或更高版本,如果您的系统版本较低,建议您首先升级到 Xfree86 4.1。

紧急 bash 救援

在下篇文章中,我们将更改 Linux 系统中对启动至关重要的部分。既然完全可能因某个错误而使您偶尔搞糟引导过程,我将在本文首先讲述:如何用紧急 bash shell 命令启动和运行系统。如果您确实碰巧发现系统因为 init 脚本或 /sbin/init 本身的问题而不能引导,就可以使用这个紧急引导过程。

进行紧急引导最简单的方法是:在引导时刻使用 GRUB 或 LILO 把 init=/bin/bash 选项传递给内核。 如果使用 GRUB,您应该能够通过点击 e 来实时地编辑当前菜单项,从而在需要时交互地传递该选项。如果使用 LILO,则确保在继续下一步之前,您已知道如何向内核传递启动选项,必要时,还要创建一个新的“紧急”LILO 启动选项。

过程

这样,基本的“救援”过程如下。首先,将 init=/bin/bash 作为一个内核引导选项传递给内核。当内核引导时,它将以 /bin/bash 而不是通常的 /sbin/init 作为第一个进程启动。 您不会被提示进行登录就看到一个 root 用户 bash 提示符:
#

然而,尽管您看到一个 root bash 提示符,实际上只安装了根文件系统,而且仅以只读的形式安装。下面介绍在这之后如何启动和运行您的系统。如果文件系统没有卸装干净的话,应该首先对它们进行 fsck 。首先对根文件系统执行 fsck -a ,然后 fsck -R -A -a 就会负责处理所有其它的文件系统:
# fsck -a /dev/hda1
# fsck -R -A -a

既然文件系统已经一致(或者,如果文件系统在系统重引导时已经卸装干净,并且您跳过了上一步骤),我们可以简单地以可读写方式重新安装根文件系统并且安装 /proc,如下所示:
# mount / -o remount,rw
# mount /proc

然后,安装可能位于其它分区中的所有重要的文件系统树。例如,如果在另一个分区上有 /usr,则还要输入:
# mount /usr

如果您想做的不仅仅只是打开一个编辑器的话,则最好是激活交换分区。如果您使用 emacs,您可能会需要它:)
# swapon -a

现在,您应该能够使用您喜爱的编辑器来编辑任何需要编辑的文件,以便修复现有的引导问题。一旦完成,只需按安装时的顺序,以只读方式重新安装分区即可。例如,如果有一个单独的 /usr 分区,为使所有的文件系统处于一致的状态(准备重新引导),可以输入:
# mount /usr -o remount,ro
# mount / -o remount,ro

现在,您可以安全地重新引导了。但愿现在已经解决了引导问题,并且可以使用正常的 LILO 或 GRUB 选项启动和运行系统。
# /sbin/reboot -nfi


为 devfs 作好准备

devfs 配置

既然您知道了在紧急情况下该怎么做,我们就可以使系统为 devfs 做好准备了。在下一篇文章里,我们将对 Linux 系统作相对复杂的更改。为什么需要这样呢?因为我们不仅仅在内核中启用 devfs 功能,这的确非常容易。我们还将以一种特别方式设置 devfsd (设备管理守护进程),用它来备份和恢复任何对设备许可权和所有权的更改。我们需要用到很多小窍门来使这个新的系统极佳地工作。但是一旦实现,我想您将对这个结果 非常满意。

devfs 内核支持

在系统上启用 devfs 的第一步比较简单:就是要使内核支持 devfs。为此目的,您需要一个 2.4 系列的内核。使用 make menuconfig 或者 make xconfig ,转至 Code maturity level选项部分并确保启用了 Prompt for development and/or incomplete code/drivers选项。然后转至 File systems内核配置部分,查找 /dev file system support (EXPERIMENTAL) 选项。选中它。您将会看到在您刚启用的选项下方,出现了两个附加选项。第一个选项控制 devfs 在内核引导时是否自动安装到 /dev。 不要启用它,我们将用一个特殊脚本手动安装 /dev。 第二个选项, Debug devfs,也应该被禁用。

禁用 /dev/pts

当您在屏幕上看到 File systems kernel configuration 部分时,如果您碰巧启用了 /dev/pts file system for Unix98 PTYs 的支持,则禁用该支持。devfs 提供了相似的功能,所以您就不再需要 devpts 文件系统了。继续进行然后保存内核配置;我们很快就要编译并安装一个新的内核!最后,在进行下一步以前,检查一下在 /etc/fstab 中是否有 /dev/pts 项;如果有,把它注释掉,使它在启动时不再被安装。

各种配置风格

下一步,将 /etc/securetty 文件装入编辑器。该文件由 login 使用,它允许您指定允许 root 用户使用以进行登录的 tty s。通常,它包含从 tty1 到 tty12 的设备,每行一个。为了使这个文件适用于 devfs,您应当为这些 ttys 加入适当的 devfs 类型名字,并保留原有的 tty? 名字,以备日后您决定禁用 devfs 引导之需。把以下几行添加到 /etc/securetty 的最下面。
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
vc/12

安装 devfsd

接下来就是在系统上安装 devfsd ,即 devfs 助手守护进程。Devfsd 将会负责创建“旧类型”兼容性设备节点;在注册/注销设备时执行自动化操作;负责备份对根文件系统上某个目录的设备许可权和所有权的更改,以及其它更多功能。现在,我们将只安装 devfsd;在下一篇文章中,我们将使它和 devfs 一起启动和运行。为了安装 devfsd,首先需要下载最新版本的 devfsd 压缩文件。(请参阅本文后面的 参考资料),当前版本为 1.3.16。然后执行下列步骤:
# tar xzvf devfsd-1.3.16.tar.gz
# cd devfsd
# make

现在,devfsd 应该编译好并可以安装了。如果您的帮助手册页存储在 /usr/man 中,输入 make install ;如果您正在使用 FHS 兼容系统,并且您的帮助手册页存储在 /usr/share/man 中,输入 make mandir=/usr/share/man install 。现在将安装 Devfsd,但还未运行,这正是我们现在要做的。

安装注释

我们即将配置 devfsd ,以便完全支持兼容性设备,所以tty? 应该足够了。然而,小心驶得万年船,尤其在可能会影响到 login 是否允许超级用户进入系统的时候。用我们的方法,即使存在问题而且 devfsd 无法启动,超级用户在 login: 提示符下登录时也不会有问题,哪怕已经启用了 devfs。

启动新内核

现在,继续前进,编译并安装刚刚配置好的内核。这个内核应该是您现在内核的临时替代品;它应能正常引导;并且尽管它内置了 devfs 支持,您应该觉察不出它与您现在正在运行的内核有什么差别。 一旦新内核安装完毕,重新引导系统以确保到目前为止一切工作正常。

Devfs 配置方法

您的系统现在已经作好了向 devfs 转换的准备,我将在下一篇文章中详细介绍。现在,是熟悉一下我们正在使用的方法的时候了。您将看到,用 devfs 启用系统可能会很棘手,尤其当您使用到 devfs 的所有优点(如持久的许可权和所有权)的时候。

内核自动安装带来的问题

确实有很多方法来使系统 devfs 启用。其中之一就是让内核在引导时自动将 devfs 安装到 /dev;我们将不使用此选项,尽管这样 确实是可以的。乍看起来,这种方法似乎很有意义,因为它可以保证所有 devfs 类型的设备对于所有进程都是可用的,甚至对第一个进程 /sbin/init 也是如此。然而,这种方法有一个问题。尽管 devfs 提供所有“新类型”的设备,但旧类型的设备节点却是由 devfsd 守护进程创建。 devfsd 不是由内核启动的,所以即使让内核在引导时安装 devfs ,当 /sbin/init 启动时我们仍然只会得到部分而非所有的设备节点。这就意味着为了使 devfsd 能在恰当的时间启动和运行,您必须修改系统初始化脚本。这不但棘手(因为这需要对系统启动脚本有专家级的理解),而且这种方法还存在其它问题。

内核安装方法的主要的问题是, devfsd 只有在能够访问原来旧类型磁盘上的 /dev 目录下的内容时,才能最好地工作。我们允许访问原来的旧类型设备的典型办法是,在 devfs 自身被安装到 /dev 之前,绑定安装 /dev 到另一个位置(通常是 /dev-state)。

这样就确保了即使在安装了 devfs 以后,也可以在 /dev-state 中访问旧的 /dev,这就允许 devfsd 将该目录用于持久设备存储。理解这点很重要,即如果没有绑定安装的话,/dev 里的旧内容将不可访问,因为在 /dev 安装 devfs 时实际上会覆盖它们。这就是用内核安装 devfs 存在的问题。如果 kernel 在任何其它进程能够启动之前就在 /dev 安装 devfs 文件系统的话,那么我们就没有机会执行绑定安装,/dev 的最初内容也就被完全隐藏。这很不友善,是吗?(想知道更多绑定安装的内容,请参阅本系列的 第 3 部分。

最佳解决方案

理想的情况是:我们能在 /sbin/init 一启动时就能拥有完整的设备节点(新类型和兼容性设备), 并且有机会在安装 devfs 以前将 /dev 绑定安装到另一位置。但如何才能做到这点?

初始封装器

一个方法是添加一个内核补丁来执行从 /dev 到 /dev-state 的绑定安装。然而,尽管这完全可行,而且也确实很容易执行,手工为您安装的每个 Linux 内核打补丁仍是相当麻烦的。因此,解决 devfs 的“先有鸡还是先有蛋”问题的最好办法,可能就是使用 初始封装器。对于我们这个特别的应用而言,初始封装器就是一个 bash 脚本,它代替 /sbin/init ― 而 真正的 init 则已被重命名为 /sbin/init.system 。简而言之,初始封装器将做以下事情:
#!/bin/bash
mkdir -f /dev-state
mount --bind /dev /dev-state
mount -t devfs none /dev
devfsd /dev
exec /sbin/init.system

正如您所见,初始封装器所做的第一件事就是确保 /dev-state 存在。然后将 /dev 树绑定安装到 /dev-state,以便可以通过 /dev-state 目录使用 /dev 的内容。然后,在 /dev 之上安装我们的 devfs 文件,然后启动 devfsd ,以便自动在 devfs 中注册我们的兼容性设备。 最后,我们 exec 最初的 /sbin/init ,现在它已被重命名为 /sbin/init.system 。 exec 命令使 init.system 取代正在运行的 bash 进程。这意味着我们的 bash 脚本被终止,而 init.system 继承了标识符为 1 的进程,也就是 init 进程以前被占用的进程标识。当 /sbin/init.system 启动后,系统将正常引导,devfs 现在也已经 完全可操作了;通过使用初始封装器,我们不必给内核打补丁,不必修改启动脚本,也不必为只有一半可操作的 devfs 系统而伤脑筋了。

在我的下一篇文章中,我将指导您经历启动和运行完整版本的初始封装器的整个过程,并为您演示如何利用 devfsd 的众多强大特性。请继续阅读!

第 6 部分     实现 devfs(使用初始化封装器)
2001 年 10 月 01 日

Linux 发行版 2.4 中,可能有一批新的文件系统,包括 Reiserfs, XFS, GFS 等。这些文件系统听起来很酷,但它们确切能做什么呢,它们擅长于什么呢,以及您又怎样在产品 Linux 环境下安全地使用它们呢? Daniel Robbins 通过向您演示如何在 Linux 2.4 下来安装这些高级文件系统回答这些问题。在这一安装过程中,Daniel 向您演示了如何使用一个初始化封装器来(最终!)将您的系统转换到“devfs mode”。

准备好了吗?

在本文中,我们将完成把我们的 Linux 系统转换到 devfs,即设备文件系统。对于那些正在加入 devfs 系列的人来说,请阅读 本系列的第 4 部分,在那里面我解释了 devfs 是如何解决内核级设备注册这一令人头疼的问题。然后请阅读 本系列的第 5 部分,在那一部分里我谈到了所有的所需步骤,您需要采用这些步骤来使得 Linux 系统与 devfs 兼容以便将系统最终转 换到 devfs。

如果还没有阅读过第 5 部分,那么在按这里所写的去做之前现在就阅读它是很重要的。 如果跳过了第 5 部分中的步骤,那么几乎可以肯定将要安装的初始化封装器将不能正确地运行,并且将最终得到一个无法引导的、需要紧急恢复的系统。这不是一件好事。然而,如果已经读过第 5 部分,那么就可以往下做了。

初始化封装器

开始

我曾经在第 5 部分结束时,介绍了初始化封装器的概念,并且解释了初始化封装器非常适合于解决若干 devfs 初始化问题的原因。无须多说,让我们逐步来看完整的初始化封装器并且研究每一部分做什么。我们将从头开始:

初始化封装器,开始部分
#!/bin/bash
# Copyright 2001 Daniel Robbins , Gentoo Technologies, Inc.
# Distributed under the GNU General Public License, version 2.0 or later.
trap ":" INT QUIT TSTP
export PATH=/sbin:/bin:/usr/sbin:/usr/bin
umask 022
if [ $$ -ne 1 ]
then
exec /sbin/init.system $*
fi

正如您所看到的一样,由于在脚本的开始有 #!/bin/bash 语句,所以初始化封装器是一个真正的 bash 脚本。这里正好向您指出初始化封装器运行 需要 bash 2.0 或更高版本;输入 /bin/bash --version 命令来看一下 bash shell 版本是否足够新 。如果不是,可能想知道是否安装了 /bin/bash2 可执行文件。如果安装了,请将脚本的第 1 行改为 #!/bin/bash2 。

现在,让我们来阅读脚本。 trap 命令防止用户在脚本执行时中断(例如,在引导时键入 control-C)脚本。然后, export 一个合理的缺省路径并且设置缺省 umask 为 022。由于在 2.4 之前发布的一些内核中有一个会产生 umask 缺省为 0 的错误,这一错误可能会造成安全威胁,因此在引导阶段尽可能早的设置一个缺省的 umask 总不失为一个好主意。

接下来,碰到了第一个条件语句, if [ $$ -ne 1 ] 。 bash 将 $$ 扩展为当前正在运行的进程标识,因此可以发现我们真正想问的问题是“我们的进程标识根本不是 1 吗?”这样做有什么意义呢?如果是在引导期间,则 bash 是由内核启动的,由于 PID 1 是为 init 进程保留的,所以将总会得到 PID 为 1。如果 PID 不是 1,则知道在系统已经引导之后,正在从命令行方式运行。由于 /sbin/init 命令有双重用途,允许超级用户改变已经引导的系统的运行级别,因此这很正常。如果是这样的话,那么仅仅 exec 了原来的 /sbin/init (现在 改名为 /sbin/init.system ) 。通过使用 $* 变量来传递任何命令行参数给 init.system ,初始化封装器终止,并且 init.system 开始执行。

内核引导选项

然而,如果在引导期间 正在由内核启动封装器,则 bash 的 PID 将为 1 ,当 bash 继续执行封装器时,将跳过该条件语句。就这么提一下,以下是接下来的几行:

初始化封装器中的更多内容
mount -n /proc
devfs="yes"
for copt in `cat /proc/cmdline`
do
if [ "${copt%=*}" = "wrapper" ]
then
parms=${copt##*=}
#parse wrapper option
if [ "${parms/nodevfs//}" != "${parms}" ]
then
devfs="no"
fi
fi
done

如果运行到这一代码块,那就意味着在系统引导期间,正在启动;作为处理的第一条命令,将 /proc 安装到根文件系统,这个 /proc 当前为只读。在那之后,执行一个大而复杂的 bash 代码块,该代码块利用了一个非常便利的 Linux 特性。您可能不了解这一特性,内核允许查看 /proc/cmdline 的内容来弄清楚 LILO 或 GRUB 传给内核什么选项。在我们的开发机器中,/proc/cmdline 的内容如下所示:
/proc/cmdline 的内容
# cat /proc/cmdline
root=/dev/hda6 hda=89355,16,63 mem=524224K

在上面的代码中,利用已有的 /proc/cmdline,通过它来查找一个我们自己创建的、称为 wrapper 的内核引导变量。如果 wrapper=nodevfs 出现在内核引导选项中,那么该脚本知道不去启动 devfs。然而,如果这一变量没有出现在 /proc/cmdline 中,那么封装器将进行 devfs 初始化。这里的含意是说您可以通过使用 wrapper=nodevfs 内核引导选项来禁止 devfs。如果这么做的话, devfs 变量将被设置成 no ;否则它将被设置成 yes 。

封装它

下面是该封装器的剩余部分:
初始化封装器的剩余部分

if [ "$devfs" = "yes" ]
then
if [ -e /dev/.devfsd ]
then
clear
echo
echo "The init wrapper has detected that /dev has been automatically mounted by"
echo "the kernel. This will prevent devfs from automatically saving and"
echo "restoring device permissions. While not optimal, your system will still"
echo "be able to boot, but any perm/ownership changes or creation of new compat."
echo "device nodes will not be persistent across reboots until you fix this"
echo "problem."
echo
echo "Fortunately, the fix for this problem is quite simple; all you need to"
echo "do is pass the \"devfs=nomount\" boot option to the kernel (via GRUB"
echo "or LILO) the next time you boot.  Then /dev will not be auto-mounted."
echo "The next time you compile your kernel, be sure that you do not"
echo "enable the \"Automatically mount filesystem at boot\" devfs kernel"
echo "configuration option.  Then the \"devfs=nomount\" hack will no longer be"
echo "needed."
echo
read -t 15 -p "(hit Enter to continue or wait 15 seconds...)"
else 
mount -n /dev /dev-state -o bind
mount -n -t devfs none /dev
if [ -d /dev-state/compat ]
then
echo Copying devices from /dev-state/compat to /dev
cp -ax /dev-state/compat/* /dev
fi
fi
/sbin/devfsd /dev >/dev/null 2>&1;
fi
exec /sbin/init.system $*

现在我们碰到了一个大的条件语句,只有在 devfs 被设置成为 yes 时,该条件语句才会执行。如果不是这样,则完全跳过 devfs 初始化,甚至不会安装 devfs。这会导致一个常见的非 devfs 引导。

然而,如果 正在安装 devfs,则进入该条件语句。在该条件语句里,检查内核是否已经安装 devfs;通过检查 /dev/.devfsd 字符设备是否存在来实现这一目的。当安装 devfs 时,内核自动创建该设备,并且随后的 devfsd 进程将使用它来与内核通信。如果已经安装了 devfs(因为用户选择了“Automatically mount devfs at boot”内核选项),将打印一条信息告诉用户:由于只有在内核 还没有 devfs 时,才可以安装 devfs 的持久性特性,现在无法完成这一任务。

设备持久性

然而,如果一切正常,则执行了在上篇文章中所谈到的 devfs 安装:/dev 被绑定安装到 /dev-state 并且 devfs 文件系统被安装在 /dev 上。然后,执行一项在上篇文章中 没有提到的一个步骤;检查目录 /dev-state/compat 是否存在并且递归地把它的内容复制到 /dev 目录。虽然这一过程最初看起来有些多余(我们将利用 devfsd 的设备持久性特性,不是吗?),但是最终会证明这一过程是必要和有用的。需要一个 compat 目录的原因在于 devfsd 的持久性特性 仅仅只能使用支持 devfs 的驱动器。

最后,启动 devfsd ,然后退出该条件语句并且 exec 实际的 init, /sbin/init.system 来开始标准的系统引导过程。除了现在需要一个支持 devfs 的系统之外,所有东西都是标准的 :)

初始化封装器安装

下面是我们如何安装初始化封装器。首先, 获取 wrapper.sh 所需资源,并且把它保存在系统的某个地方。然后,按下面所说的做:

安装初始化封装器
# cd /sbin
# cp init init.system
# cp /path/to/wrapper.sh init
# chmod +x init

现在初始化封装器安装在正确的地方了。

调整 umount

通过使用初始化封装器,避免了编制大量复杂的启动脚本来进行调整。不过,我们可能还是不能避免 一个调整。既然,我们将 devfs 安装在 /dev,则 rc 脚本卸载根文件系统将可能会非常困难。幸运的是,有一个简便方法可以解决这一问题。只需要输入 cd /etc/rc.d; grep -r umount * 或 cd /etc/init.d; grep -r umount * 来 grep rc 脚本目录中所有出现 umount 的地方,具体输入哪条命令取决于 rc 脚本安装在什么地方。然后,在每个引用 umount 的脚本里,请确保调用时带有选项 -r 。虽然在各处使用 umount -r 仍然会起作用,但这一特定的 umount 的命令对于卸载根文件系统是十分重要的:)

-r 选项告诉 umount ,如果没能成功卸载文件系统,就以只读方式重新安装。对于把根文件系统设置到一致状态来说,这已经足够了,而且即便根文件系统由于在 /dev 上的有一个安装而无法卸载(由于无法卸载打开的设备节点),这也为根文件系统重新引导做好了准备。

现在,我们 几乎为重新引导做好了准备;但是在重新引导之前,让我们来看一下 devfsd 并且修改 /etc/devfsd.conf 以便支持兼容性设备和设备持久性。不用担心,我们离完成转换到 devfs 只有一步之遥。

devfsd.conf

用您喜爱的编辑器打开 /etc/devfsd.conf。下面是我推荐的 devfsd.conf 中的头四行:

devfsd.conf,开始部分
REGISTER        .*              MKOLDCOMPAT
UNREGISTER      .*              RMOLDCOMPAT
REGISTER        .*              MKNEWCOMPAT
UNREGISTER      .*              RMNEWCOMPAT

上面四行中的每一行都含有一个 事件( REGISTER 或 UNREGISTER ),一个正则表达式( .* )以及一项操作( *COMPAT 字符串)。那么,它们都表示什么意思呢?第 1 行告诉 devfsd ,当有内核中注册 任何设备( .* 是表示匹配 任何设备的正则表达式)时,执行 MKOLDCOMPAT 操作。 MKOLDCOMPAT 操作是 devfsd 内置的,它的含义是“创建任何与正在通过 devfs 注册的设备相对应的旧兼容设备”。正如您可能想到的一样,在删除设备时,会运行 RM*COMPAT 操作,这使得这些特定的兼容设备魔术般的消失。总的来说,这四行语句告诉 devfsd ,当设备注册时,创建兼容设备(如果有的话),当解除设备注册时,删除兼容设备。多亏了这几行,当 IDE 设备驱动器在系统中注册 /dev/ide/host0/bus0/target0/lun0/disc devfs 样式的设备时, devfs 自动创建一个匹配 /dev/hda 兼容样式的设备。这对于诸如 mount 和 fsck 命令来说,是极其有帮助的,这些命令可能会读一个包含旧样式设备的 /etc/fstab 。一般来说,创建兼容设备使得 devfs 的转换成了一个无缝转换。devfsd.conf 中的下一行是:

自动装载模块

devfsd.conf,续上
LOOKUP          .*              MODLOAD

这一项告诉 devfsd ,无论什么时侯“查看”任何设备( .* ),就执行 MODLOAD 操作,这是指当程序查找特定设备节点是否存在时所发生的操作。 MODLOAD 操作将导致执行 modprobe /dev/mydev ,这里的 /dev/mydev 是特定进程所要查找的设备名。多亏了这一特性(以及正确配置的 /etc/modules.conf),当启动音乐播放器或其它美妙的东西时,可能可以按照需要自动装入声卡驱动器。

设备持久性

以下是 devfsd.conf 中的接下来的几行:

devfsd.conf,续上
REGISTER        ^pt[sy]/.*      IGNORE
CHANGE          ^pt[sy]/.*      IGNORE
REGISTER        .*              COPY    /dev-state/$devname $devpath
CHANGE          .*              COPY    $devpath /dev-state/$devname
CREATE          .*              COPY    $devpath /dev-state/$devname

这几行告诉 devfsd 使用 /dev-state 作为用于设备许可权和所有权变更以及任何用户可以创建的兼容设备的资源库。在头两行中,显式地告诉 devfsd ,当内核中注册了任何伪终端设备或当它们的属性被更改时,不要执行任何特殊的操作。如果没有这几行,则在重引导系统之后,仍然会保留伪终端的许可权和所有权。那样做不太理想,因为应该总是在系统启动之后给予伪终端一套新的缺省许可权。

接下来的三行为所有其它设备打开 /dev-state 持久性。特别地,注册设备或 devfsd 自己启动时,将 从 /dev-state 恢复设备的任何属性(以及复制给任何现有的兼容设备),并且我们将立即 备份属性的任何更改,以及将任何新兼容设备创建到 /dev-state 中去。

CFUNCTION 和符号链接

给出以下几行,最终完成 devfsd.conf:

devfsd.conf,结束
REGISTER        ^cdrom/cdrom0$          CFUNCTION GLOBAL symlink cdroms/cdrom0 cdrom
UNREGISTER      ^cdrom/cdrom0$          CFUNCTION GLOBAL unlink cdrom
REGISTER        ^misc/psaux$            CFUNCTION GLOBAL symlink misc/psaux mouse
UNREGISTER      ^misc/psaux$            CFUNCTION GLOBAL unlink mouse

这最后四行是可选的,但它们也值得一看。虽然对于设备节点,/dev-state 持久性工作得非常好,但对符号链接却根本不起任何作用,它会忽略符号链接。因此,这就产生一个问题:人们怎么确保 /dev/mouse 或 /dev/cdrom 符号链接不仅存在,而且在重新引导系统之后它还是存在的呢?幸运的是, devfsd 可配置性非常好,这四行(或类似这样的,可以定制你的特定系统)将完成这一任务。头两行告诉 devfsd ,当注册 /dev/cdrom/cdrom() 时,使 /dev/cdrom 符号链接出现。为了做到这一点, devfsd 实际上执行指定的 libc 函数的动态调用,这里是 symlink() 和 unlink() 。该文件的最后两行使用相同的方法,在 /dev/misc/psaux(PS/2 鼠标)设备注册到 devfs 时,创建 /dev/mouse 符号链接。根据 您的系统来定制这几行,然后保存该文件。如果您愿意,可以 下载这个 devfsd.conf 文件,用在您自己的系统上。

重新引导之前的注意事项

在重新引导之前,您可能想看一下 Richard Gooch 的 devfs FAQ;您可能会找到关于 devfs 命名方案的信息,这些信息对于熟悉新风格设备名是非常有帮助的(请参阅下面的 参考资料)。我还建议您打印一份 本系列第 5 部分,以备您在解决与引导相关的问题时,能利用“紧急 bash 抢救”指导。记住,如果初始化封装器因为某种原因而崩溃,请遵循我的紧急抢救指导,重新安装根文件系统为读/写,然后执行下面步骤,这总是可以除去它的:

如果需要,请返回至使用封装器前的状态
# cd /sbin
# mv init wrapper.sh
# mv init.system init

在执行完这些步骤,并将文件系统重新安装成只读,然后,重新引导之后,系统将返回到使用预封装器前的状态。现在继续,重新引导,体验一下 devfs!

该文章最后由 阿炯 于 2012-05-07 10:15:29 更新,目前是第 3 版。