首页 > 开发 > 综合 > 正文

Red Hat日志文件系统-ext3

2024-07-21 02:37:20
字体:
来源:转载
供稿:网友

  翻译:刘启文
  
  概要
  在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?
  为什么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系统参数来改进性能。这里主要介绍性能调试的一些基本方法。当然,所有的性能调试都需要针对特定的应用程序;这里没有

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表