为什么要信任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更小的延迟时间数值。
在某些情况下，希望牺牲延迟时间来换取最大吞吐量的企图，会导致吞吐量下降和延迟时间的增加（在这种情况下，/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强制写操作按特定顺序进行。