除了与 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 文件装入文本编辑器时，文件的部分或全部包含乱码 ― 在系统锁定之前来不及初始化的数据块。