Ext4 Howto

原文

说明

Ext4文件系统作为一个功能完整的和稳定文件系统的伴随着Linux 2.6.28出现，大多数的现代Linux发行版本都支持Ext4（在某些发行版本中，Ext4作为默认的文件系统），所以如果你使用的是一个现代的Linux发行版本，很可能你的系统就已经内置了对于Ext4的支持，你并不需要修改操作系统去运行Ext4。

在生产环境下使用Ext4是安全的，但是跟任何的软件一样，它也会有Bug（这些Bug很可能在第1个稳定版本中出现并被利用）。任意已知的严重bug都会很快地被修复。如果你发现了bug，你可以在ext4 邮件列表中联系Ext4的开发者。他们有时也会在IRC。

EXT4 特性

兼容性

任何现有的Ext3文件系统可以不经过任何的磁盘格式的修改就作为Ext4挂载。然而，可以通过在只读模式下运行一串指令将Ext3文件系统升级到Ext4文件系统，从而享受Ext4带来的好处。这意味着你可以提升性能、存储限制和你现有的文件系统而不用重新格式化和／或者重新安装你的操作系统和软件环境。在生产环境下，如果你需要Ext4带来的优势，你可以升级你的文件系统。这个（升级）过程是安全的，不会对你的数据带来任何风险（当然，建议对关键数据的进行备份，即使你没有更新你的文件系统：）。Ext4对于新的数据将会使用新的数据组织方式，而对于已存在的老的数据组织方式不会做任何的修改，当需要的时候，可以正常进行读取或修改。这意味着如果你把你的文件系统转换成Ext4，你将无法回到Ext3。

更大的文件系统和文件大小

目前Ext3支持最大16TiB的文件系统和最大2TiB的单文件。Ext4使用48位的块地址，所以可能支持最大1**EiB**的文件系统和最大16TiB的单文件。为什么是48位而不是64位？（因为）在把Ext4变成完全64位使能之前还有一些限制因素需要解决。Ext4的数据组织方式在设计时就保持这种想法，所以将来有一天Ext4会更新成完全支持64位的文件系统。在那一天到来之前，1EiB已经足够了（真的：））。

注意：在写这篇文章的时候，用于创建大于16TiB的文件系统的代码还没有出现在任何e2fsprogs的稳定版本中，会在将来的版本中出现。

注：1Eib 或者 Exbibyte(艾字节)是2⁶⁰个字节或者1,048,576FiB。
1EiB=1024PiB
1PiB=1024TiB
1TiB=1024GiB

In order to map blocks beyond 2^32 to a file, extents must be enabled since block maps only know about 32-bit block numbers. As of e2fsprogs 1.42.9, this requirement is enforced by mke2fs.（没看明白这句说的什么）

更多的子目录

目前在Ext3中一个目录可能最多拥有32000个子目录。Ext4把这个限制翻了一番，允许64000个子目录。

Extents

传统的Unix派生的文件系统，比如Ext3，使用间接块映射机制去追踪和文件的数据相关的每一个块。这对于大文件来说是效率非常低下的，特别当一个大文件删除或截断时，因为映射保存了每一个块的入口，大文件通常有很多块，大量的映射使得处理过程变慢。现代文件系统使用一种不同的方法，称为”extents”。一个extent本质上是一串连续的物理块。它表明“数据在后面的n个块中”。比如，1个100MiB的文件可以分配为一个有那样大小的单一的extent，而不需要为25600个块（每个块4KiB）去创建间接的映射。非常大的文件会被分割成几个extent。Extents不仅提升了性能还有利于减少磁盘碎片，因为extent在磁盘上通常是连续的。

多块分配

当Ext3需要向磁盘写入新的数据时，块分配器需要决定哪些空闲块将被用于写入这些数据。但是Ext3的块分配器每次只分配一个块(4Kib)。这意味着如果系统需要写入先前提到的100MiB的数据，它将需要调用块分配器25600次（这仅仅是100MiB）。这种做法不仅是效率低下的，而且不允许块分配器去优化分配策略因为它不知道总共需要分配多少数据，它仅仅知道一个单一的块。Ext4使用一个”多块分配器”(mballoc)，每次系统调用将会分配多个块而不是每调用一次分配一个块，减少了很大的开销。这种做法提升了性能，而且对于延迟分配和extent是非常有用的。这种特性并不影响磁盘格式。当然，Ext4的块/inode分配器还有其它方面的提升，在这篇论文里有详细描述。

延迟分配

延迟分配是一个在少数的现代文件系统比如XFS，ZFS，btrfs或者Reiser4中可以找到的性能特性（它不会改变磁盘格式），它在于尽可能地延迟块的分配，而不像一些传统的文件系统（比如Ext3, reiser3等等）所做的那样：尽可能早地分配块。比如，一个进程调用write()，文件系统将会立即分配将要写入数据的块，即使数据没有马上被写入磁盘中，而且数据有可能还会在缓存（cache）中保留一段时间。这种做法有很多缺点。比如当一个进程持续地向一个文件写入，这个文件就会一直在变大，连续的write()调用会为数据分配许多块，但它们并不知道这个文件是否会继续变大。延迟分配正好相反，当进程调用write()的时候并不会立即分配块，而是延迟块的分配，当文件还在缓存中的时候，直到它真的要被写入到磁盘的时候才分配。这就让块分配器有机会按照实际情况去优化，但是老的系统无法做到。延迟分配和先前提到的两个特性，extents和多块分配协作得非常好，因为在大多数情况下，当文件最终被写入磁盘的时候，它会被分配在一个由mballoc分配器所分配的多个块组成的extents。这样做的话，性能会更好，磁盘碎片问题在某种程度上将会被有效改善。

快速fsck

文件系统检查(fsck)是一个非常慢的操作，特别是第一步：在文件系统中检查所有的inode。在Ext4中，每个组的尾部的inode表将会存储一个未使用的inode列表（出于安全考虑，一般会有校验和），所以fsck将不会检查这些inode。结果就是依赖于inode的使用数量（在Ext4中提升fsck的速度），fsck速度大体上提升了2到20倍不等。值得注意的是，实际上是fsck，而不是Ext4建立了未使用的inode列表。这意味着你必须运行fsck去使得未使用的inode列表的建立，而且仅仅是接下来的fsck会运行得更快（不管怎样，如果你想要把Ext3的文件系统转换成Ext4，你必须通过fsck的检验）。还有一个特性能加速fsck， “灵活的块组（flexible block groups）”也会使文件系统的操作加速。

日志校验

日志是磁盘中最经常使用的部分，它也更容易发生硬件故障。从一个错误的日志中恢复会引起很严重的错误。Ext4使用校验和对日志数据进行校验，去发现日志块是否失效或者损坏。日志校验有这样的好处：它允许把Ext3的两阶段提交系统转换成1阶段的，在某些情况下能够最多加速文件系统的操作20%，所以可靠性和性能同时提高了。（注意：这部分关于性能的提升、异步记录在现在是默认关闭的，在以后可靠性提高之后，可能会开启）

“无日志”模式

日志通过对持续的磁盘变化进行记录去确保文件系统的完整性。然而，很明显这会带来一些开销。对于某些有特殊需求和工作量的人，可以在无日志、无完整性优点的模式下运行。在Ext4中日志特性可以被关闭，借此获得小的性能提升。

在线碎片整理

（这个特性正在开发过程中，并且会包含在将来的版本中）。虽然延迟分配、extents和多块分配有利于减少磁盘碎片的问题，但是随着文件系统的使用仍然会有磁盘碎片。比如你持续地在一个目录中写入3个文件。有一天你需要更新中间的那个文件，但是更新后的文件将会变得很大，以至于没有足够的空间去存放。你没有别的选择，只能把文件中超出的那些数据弄成碎片放到磁盘的别的位置，这就会引发一个寻道了，或者为更新后的文件在其它位置分配一个连续的空间，和当前目录的其它两个文件相距较远，结果就是当一个应用程序读取目录下的所有文件时（比如一个文件管理器需要对全是图片的目录做一个缩略图）需要寻道。此外，文件系统可以只关注特定类型的磁盘碎片，它无法知道。比如，它必须保持所有跟引导相关的文件是相邻的，因为他并不知道哪些文件是跟引导相关的。为了解决这个问题，Ext4将会支持在线磁盘碎片整理，而且有一个e4defrag工具可以对单个文件或整个文件系统进行磁盘碎片整理。

Inode相关的特性

更大的inode，纳秒级的时间戳，快的扩展属性，inode预留…

• 更大的inode：Ext3支持配置inode的大小（通过-l mkfs参数），但是默认的inode大小是128字节。Ext4默认将会是256字节。这对于为额外的域（比如纳秒级的时间戳或者inode变体）提供空间是必须的，inode的剩余空间将会被用于存储一些足够小的扩展属性。这将会使得访问这些属性更快，而且在某种程度上提升使用这些扩展属性的程序的性能3到7倍。
• 当新建一个目录的时候，Inode为它保留了一些inode，预计它们将来会被使用。这样做提升了性能，因为当在这个目录里新建文件时，将可以使用这些保留的inode。文件的创建和删除变得更有效率。
• 纳秒级的时间戳意味着inode中的“modified time”之类的域将可以使用纳秒级的分辨率，而不是秒级的分辨率。

持久性预分配

这个特性在最新版的内核中的Ext4中可用，但在glibc的模拟文件系统中并不支持，允许应用程序预分配磁盘空间：应用程序向文件系统申请预分配空间，然后文件系统预分配了必要的块和数据结构，但是并没有存储任何数据，直到将来应用程序真的需要写入数据。这也是P2P应用程序所在做的，它们为将会持续几个小时或几天的下载“预分配”了必要的空间，但是在文件系统上实现会更有效率和拥有更通用的API。这样做有许多好处：首先，避免了应用程序(比如P2P)自己低效率地使用0去填充一个文件。其次，改善了磁盘碎片的问题，因为这些块将会被一次性分配而且尽可能的连续。最后，确保应用程序总是拥有它们将需要的空间，这需要RT-ish应用程序来说是重要的，如果在文件系统中没有预分配，一些重要的操作可能比较费时。这个特性通过libc的posix_fallocate()接口提供。

默认的屏障

这是一个提升文件系统完整性的选项，但会牺牲一些性能（你可以使用mount -o barrier=0去关闭它，当你在基准的时候建议去尝试使用）。根据这篇LWN文章：“文件系统的代码必须在写（日志）提交记录之前，必须确保所有的事务信息都被写入到日志中。以一定的顺序执行写操作是低效率的，同类设备会维护一个很大的内部缓存而且将会对操作重新排序来获得更好的性能。所以文件系统必须明确指示磁盘在写提交记录之前把所有日志数据写入到介质上，如果提交先写入了提交记录，日志可能会损坏。内核的块I/O子系统使用屏障以完成这样的功能；本质上，屏障禁止对屏障后面的任何块的写入直到屏障前的所有写入的块都被提交到介质上。通过使用屏障，文件系统可以确保它们的磁盘结构总是保持一致。

Ext4 code implements discard/TRIM

Requires mounting with “discard” flag. See howto and Verfying TRIM.

获得Ext4代码