Copyright © 2001 by Red Hat
翻译：刘启文
[email protected]
Copyright © 2001 by Dynasoft
概要... 1
ext3的优点... 2
可用性... 2
数据完整性... 2
速度... 2
易于迁移... 3
为什么使用ext3？... 4
为什么要信任ext3？... 5
性能调试建议... 6
调整电梯（elevator）算法设置... 6
选择日志模式... 7
速度... 7
数据完整性... 7
概要
在Red Hat Linux 7.2中，Red Hat首次支持日志文件系统ext3。ext3文件系统是对稳定的ext2文件系统的改进，有几项优点。本文概述这些优点，解释Red Hat公司对ext3进行了何种测试，略述性能调试（为高级用户）。
有数种基于Linux的日志文件系统正在开发之中。本文不言及这些日志文件系统，也不准备与这些日志文件系统进行比较。
ext3的优点
为什么你需要从ext2迁移到ext3呢？以下有四个主要原因：可用性、数据完整性、速度、易于迁移。
可用性
在非正常当机后（停电、系统崩溃），只有在通过e2fsck进行一致性校验后，ext2文件系统才能被装载使用。运行e2fsck的时间主要取决于 ext2文件系统的大小。校验稍大一些的文件系统（几十GB）需要很长时间。如果文件系统上的文件数量多，校验的时间则更长。校验几百个GB的文件系统可能需要一个小时或更长。这极大地限制了可用性。
相比之下，除非发生硬件故障，即使非正常关机，ext3也不需要文件系统校验。这是因为数据是以文件系统始终保持一致方式写入磁盘的。在非正常关机后，恢复ext3文件系统的时间不依赖于文件系统的大小或文件数量，而依赖于维护一致性所需“日志”的大小。使用缺省日志设置，恢复时间仅需一秒（依赖于硬件速度）。
数据完整性
使用ext3文件系统，在非正常关机时，数据完整性能得到可靠的保障。你可以选择数据保护的类型和级别。你可以选择保证文件系统一致，但是允许文件系统上的数据在非正常关机时受损；这是可以在某些状况下提高一些速度（但非所有状况）。你也可以选择保持数据的可靠性与文件系统一致；这意味着在当机后，你不会在新近写入的文件中看到任何数据垃圾。这个保持数据的可靠性与文件系统一致的安全的选择是缺省设置。
速度
尽管ext3写入数据的次数多于ext2，但是ext3常常快于ext2（高数据流）。这是因为ext3的日志功能优化硬盘磁头的转动。你可以从3种日志模式中选择1种来优化速度，有选择地牺牲一些数据完整性。
第一种模式，data=writeback，有限地保证数据完整，允许旧数据在当机后存在于文件当中。这种模式可以在某些情况下提高速度。（在多数日志文件系统中，这种模式是缺省设置。这种模式为ext2文件系统提供有限的数据完整性，更多的是为了避免系统启动时的长时间的文件系统校验）
第二种模式，data=orderd（缺省模式），保持数据的可靠性与文件系统一致；这意味着在当机后，你不会在新近写入的文件中看到任何垃圾数据。
第三种模式，data=journal，需要大一些的日志以保证在多数情况下获得适中的速度。在当机后需要恢复的时间也长一些。但是在某些数据库操作时速度会快一些。
在通常情况下，建议使用缺省模式。如果需要改变模式，请在/etc/fstab文件中，为相应的文件系统加上data=模式的选项。详情可参看mount命令的man page在线手册（执行man mount）。
易于迁移
你可以不重新格式化硬盘，并且很方便的从ext2迁移至ext3而享受可靠的日志文件系统的好处。对，不需要做长时间的、枯燥的、有可能失误的“备份－重新格式化－恢复”操作，就可以体验ext3的优点。有两种迁移的方法：
· 如果你升级你的系统，Red Hat Linux安装程序会协助迁移。需要你做的工作 就是为每一个文件系统按一下选择按钮。
· 使用tune2fs程序可以为现存的ext2文件系统增加日志功能。如果文件系统在转换的过程已经被装载了(mount)，那么在root目录下会出现文件”.journal”；如果文件系统没有被装载，那么文件系统中不会出现该文件。转换文件系统，只需要运行tune2fs –j /dev/hda1(或者你要转换的文件系统所在的任何设备名称)，同时把文件/etc/fstab中的ext2修改为ext3。如果你要转换自己的根文件系统，你必须使用initrd引导启动。参照mkinitrd的手册描述运行程序，同时确认自己的LILO或GRUB配置中装载了initrd（如果没有成功，系统仍然能启动，但是根文件系统会以ext2形式装载，而不是ext3，你可以使用命令cat /proc/mounts 来确认这一点。）详情可参看tune2fs命令的man page在线手册（执行man tune2fs）。
为什么使用ext3？
[1] [2] [3] 下一页
为什么Red Hat选择ext3作为我们第一个正式支持的日志文件系统？这是因为ext3具有以下优点。注意这些优点每一个都不是ext3所独有的（其它的日志文件系统同样具有以下的某些优点），但是只有ext3同时具有所有的这些优点。
· ext3全面兼容ext2，允许用户在增加日志功能时，保留现存的文件系统。任何想要去除文件系统的日志功能的用户也不需要做很多工作（我们没期望很多人这么做）。而且，只要安装了最新版的e2fsprogs程序（例如Red Hat Linux 7.2中自带的），一个ext3文件系统不需要去掉日志功能，也能以ext2形式装载。
· ext3从ext2不断增强和改进自身功能的历史中获益，并且以后还将吸收ext2的优秀特性。也就是说ext3继承了ext2许多已有的优点，同时 ext2新增加的一些特性，也会很容易的转移到ext3中。例如当扩展属性或者Htree增加到ext2中时，把这些特性加到ext3中也是很容易的（扩展属性实现访问控制列表，Htree可以提高目录操作的速度和改进大目录的可伸缩性）。
· ext3和ext2一样是由来自多家厂商的开发人员联合开发的，它的开发不依赖于任何个人或组织。
· ext3提供并使用了一个通用日志层（jbd），该层可以在其它环境中使用。Ext3不但能在文件系统中使用日志功能，而且能够应用到其它设备中，例如目前Linux开始支持的NVRAM设备，ext3就能够支持。
· ext3有多种日志模式。它可以记录所有的文件数据和（metadata）元数据（data=journal），也可以只记录元数据（data= ordered或data=writeback）。当你不记录文件数据时，你可以选择在记录元数据前修改文件系统数据（data=ordered；这样所有的元数据记录都指向了有效数据），或不特殊地处理文件数据（data=writeback；文件系统保持一致性，但是非正常关机后，文件中会有旧数据存在）。这样，管理员可以在速度和文件数据一致性两方面权衡利弊，并且可以为某些特殊的应用调整速度。
· ext3有很强的平台兼容性，它可以在little-endian和big-endian系统上，支持32和64位体系结构，。任何能够访问ext2文件系统的操作系统，都能访问ext3文件系统，目前包括各种Unix版本及其变种，BeOS，Windows。
· ext3不要求内核做大的修改，也不需要增加新的系统调用，因此目前没有什么难题能够阻止Linux Torvalds把ext3加入他正式的Linux内核版本中。Ext3已经集成到了Alan Cox的 –ac内核中，很快就会进入到Linus的正式内核中。
· 当由于软件或硬件错误导致文件系统崩溃时，文件修复程序e2fsck在修复数据方面有很好的成功记录。ext3使用了和e2fsck相同的代码来修复崩溃的文件系统，因此在出现数据崩溃错误时，ext3和ext2同样具有防止数据丢失的优点。
我们要再次声明这些优点中的每一点都不是ext3所独有的。它们中的大部分是别的文件系统也有的。我们不过是声明这些所有的优点真的是只有ext3才全具备。我们是根据用户的要求，来决定我们目前应该支持哪些特性。根据我们的测试，ext3是目前最能满足我们用户需要的。我们将继续评估其它的文件系统，以便于在以后的Red Hat Linux版本中加入这些文件系统。
为什么要信任ext3？
Red Hat为了确保ext3能够安全地处理用户数据，做了以下测试：
· 我们在各种配置下进行了大量的压力测试。这包括在各种硬件和文件系统配置上，进行数千小时的“专项”负载测试，以及许多用例（use case）测试。
· 我们在多种条件下观测ext3，包括在某一点上内存分配错误的情况。每次代码更新，我们都反复地强制性地制造错误来测试在这些条件下文件系统的一致性。
· 我们测试出ext3和虚拟内存（VM）子系统之间的交互性能较差，因而进行了改进。日志文件系统对VM子系统有更大的压力，并且我们在测试的过程中发现并修改了几个ext3和VM子系统中的错误。经过了数千个小时的这种测试，我们对ext3文件系统充满了信心。
· 从2.2内核系列一直到现在的2.4内核系统，我们对ext3进行了一年多的β测试。甚至在正式的β测试以前，ext3已经被放在产品中，在一些环境中使用了。ext3应用在一些访问量很大的服务器上超过了两年，例如rpmfind.net服务器。
· 为了处理潜在的硬件故障引起的崩溃，我们已经安排允许用户在“当机”后选择是否检测文件系统的一致性，即使文件系统被标记为“clean”。这是因为硬件故障和大部分的电力故障，几乎能在磁盘的任何地方产生“垃圾”数据。按下重起按钮可能不会产生这类问题，但是现实中由雷击或电压巨变引起的电力故障，是会破坏正在写入磁盘的数据的。IDE磁盘比SCSI磁盘更容易产生这类问题，部分原因是因为IDE磁盘通常使用松散缓存（looser cancheing） 算法。
·这种特性是使用文件/.autofsk来实现的，如果根用户在正常情况下删除了这个文件，则在引导时系统可以提供选择是否检查文件系统的一致性。如果 /.autofsk不存在了并且用户选择对文件系统进行强制检查，那么这种情况和存在文件/forcefsck的效果是一样的。
性能调试建议
调整电梯（elevator）算法设置
ext3文件系统和ext2文件系统有一些不同，这种不同表现在多方面。高级用户可以调整文件系统和I/O系统参数来改进性能。这里主要介绍性能调试的一些基本方法。当然，所有的性能调试都需要针对特定的应用程序；这里没有适合所有状况的性能调试方法。但是，我们会尽力提供一些具有普遍意义的有用信息。
Linux 的大多数块设备驱动程序都使用了“电梯式（elevator）”算法来调度块I/O操作。我们可以使用程序/sbin/elvtune调整吞吐量（throughput）和延迟时间（latency）的值，来达到最佳效果。对于给定的负载，ext3要达到和ext2文件系统同样的效果，需要提供给 /sbin/elvtune更小的延迟时间数值。
上一页 [1] [2] [3] 下一页
在某些情况下，希望牺牲延迟时间来换取最大吞吐量的企图，会导致吞吐量下降和延迟时间的增加（在这种情况下，/sbin/elvtune使用大的读延迟时间(-r)和写延迟时间(-w)）。这种结果主要是由于以下原因：
· 在ext2文件系统中，每30秒调度一次写操作；而ext3文件系统每5秒就调度一次写操作。这样做是为了防止日志操作对系统吞吐量产生明显的影响，同时也保持磁盘上数据的时效性。
· 因为ext3文件系统记录所有元数据的变化情况，所以atime（文件最后访问时间）的变化情况对文件系统的影响更大了。如果想禁止更新atime，你可以使用noatime参数来装载（mount）文件系统。虽然，atime不是元数据更新的唯一来源，但是对很多系统，尤其是那些带有大量可访问文件，同时又被大量访问的服务器来说，元数据更新大多数都是由于atime更新。在这些系统中，关闭atime更新可以明显的降低延迟时间和提高吞吐量。
为了调试我们的缺省文件系统ext3，Red Hat已经把缺省的读和写延迟时间降低了一半（从8192读和16384写降到4096读和8192写）。我们希望在普通的应用中，你可以不需要改变这些数值。在我们的测试中，我们所提供的缺省数值已经表现出很好的效果。但是，为了适应特殊的应用程序，我们建议你基于自己的应用使用多个数值来测试系统性能。一般情况下，我们建议你把读延迟时间（-r）设置为写延迟时间（-w）的一半。
例如，你可以执行命令：/sbin/elvtune –r 1024 –w 2048 /dev/sdd 来改变设备/dev/sdd（包括/dev/sdd上的所有分区）的电梯算法设置。对一个分区的电梯算法设置的改变将会影响该分区所在的设备，因为一个设备上的所有分区共享相同的电梯算法（elevator）设置参数。
一旦你发现所设置的延迟时间和吞吐量参数，最适合自己的应用程序集，你可以把对程序/sbin/elvtune的调用命令加到文件/etc/rc.d/rc.local脚本的末尾，这样系统在每次启动时都会自动设置这些参数。
选择日志模式
速度
在一些典型的情况下，使用选项data=writeback可以显著地提高速度，但是同时会降低对数据一致性的保护。在这些情况下，数据一致性的保护基本上与ext2文件系统相同，不同的是在正常操作时，系统不断地维护文件系统的完整性（这是其它日志文件系统使用的日志模式）。这包括频繁的共享写操作，还包括频繁地创建和删除大量的小文件，例如发送大量的小电子邮件信息。如果你从ext2切换到ext3，发现应用程序性能大幅度下降，选项data= writeback可能会对你提高性能有帮助。即使你没有获得昂贵的数据一致性保护措施，你仍然可以享受ext3的好处（文件系统总是保持一致）。
Red Hat还在做工作，以提高ext3某些方面的性能，所以ext3的某些方面性能在将来可以获得改善。这也意味着即使你现在选择了data= writeback，你也需要以data=journal的缺省值重新测试将来的版本，来确定新版本的改变是否与自己的工作有关。
数据完整性
在大多数情况下，用户都是在文件的末尾写入数据。仅仅在某些情况下（例如数据库），用户在现存文件的中间写入数据。甚至覆盖现存文件的操作，是通过先截断该文件，然后再从文件末尾写入数据来实现的。
在data=ordered模式中，如果正在写文件时系统崩溃，那么数据块可能被部分改写，但是写入过程并没有完成，所以系统存在不属于任何文件的不完整数据块。
在data=ordered模式中，崩溃后残存无序数据块的唯一情况是在崩溃过程中一个程序正在重写某个文件。在这种情况下，无法绝对保证写入顺序，除非该程序使用了fsync()和O_SYNC强制写操作按特定顺序进行。
（出处：http://www.sheup.com）
上一页 [1] [2] [3]
（出处：http://www.sheup.com）
上一页 [1] [2] [3] [4]