Linux 文件系统 - Ext4 Howto

去年就发现项目Android系统中已经用上了Ext4文件系统，当时并没有深究为什么要使用Ext4文件系统，使用ext4带来的优点和缺点。

最近有时间，正好整理下Ext4对于Ext2/Ext3带来的变化。网上关于Ext4的文章并不多，只找到了来自http://kernelnewbies.org/Ext4/的Ext4 Howto，是一篇概括性的文章。

1. 介绍

Ext4是Ext3的进化版本，而后者是Linux操作系统最常用的文件系统。Ext4在很多方面对Ext3做了改善，这种改变要远多于Ext3对Ext2做的改变。Ext3和Ext2的差别进局限于日志系统，但是Ext4修改了文件系统的大部分重要数据结构，比如文件数据的存储方式。因此改变了设计，增强了性能，稳定性和features

2 Ext4 features

2.1 大文件系统，大文件尺寸

Ext2/Ext3：

文件系统尺寸计算方法 2^32 * block_size, 如果block_size是4096的话，那么文件系统尺寸上限是16TB；

最大文件尺寸受到三个限制：

1.ext2_inode中的i_size:

乍一看i_size只有32bits，所以最大文件尺寸不能超过2^32，实际不然，Ext2/Ext3使用了一种脏方法，借用了和i_size相邻的i_dir_acl，所以可以扩展到用64bits来表示文件大小，因此这不可能成为限制。

2. 是三级间接块的寻址空间:

假定块尺寸是4096，那么三级间接块可表示1024*1024*1024*4096 = 4T

3. 最大文件尺寸不能超过(2^32 -1)*512 = 2T，也就是能文件尺寸不能超过32bits能表示的sectors数目。

因此Ext2/Ext3文件系统，最大文件限制是2TB。

 Ext2/Ext3Ext4文件系统尺寸16TB1EB最大文件尺寸2TB16TB

2.2 子目录数量

 Ext2/Ext3Ext4最大子目录数目3200065000   

2.3 Extents

Ext2/Ext3文件系统使用间接映射来管理文件数据逻辑地址到物理块的映射关系，间接映射分为一级间接，二级间接和三级间接，文件数据前面一小部分则使用直接映射。因此对于小文件来说，这种管理方式很简洁高效。但是对于大文件，特别是大文件的删除和truncate操作，因为要为每一个被删除块处理映射关系，所以对于很大的文件来说，需要花费很长的时间。此外大文件需要三阶映射，也就是说访文件的逻辑块，需要查找访问四个物理块。

现代文件系统引入了”extents“的概念，这个概念完全是为管理大文件数据引入的，一个extent包含一组连续的物理块。仅仅使用一个extent管理一组逻辑地址块到物理块的映射，而无需为每一对建立映射。考虑一个100MB的文件，理想情况下，我们只需要一个extent来记录映射关系，但是如果使用Ext2/Ext3的间接映射，则需要为25000个blocks建立映射关系。

由于extents有利于连续磁盘分配，因此extents会减少碎片，并改善文件系统性能。

2.4 多块分配

当Ext3需要写文件数据到磁盘上，块分配器决定使用哪一个空闲块来写数据。但是Ext3块分配器每次只能分配一个块 4KB。这就意味着对于100MB大小的文件，需要调用25000次块分配器。低效不仅是因为调用了25000次块分配器，而且也使得块分配器无法优化分配策略，因为块分配器无法把这25000次分配关联起来。

Ext4使用一个multiblock allocator(mballoc)，使得一次分配很多块成为可能。避免了多次分配，优化了分配策略，提高了性能，多块分配器对delayed 分配和extents特别有用。这个feature不会影响到磁盘layout。

此外，Ext4 block/inode分配器还有其他的改善，详情参见http://ols.fedoraproject.org/OLS/Reprints-2008/kumar-reprint.pdf

2.5 延迟分配

延迟分配是一个性能优化技术，好几个文件系统中都使用延迟分配技术，比如XFS，ZFS，btrfs和Resier 4。和传统文件系统Ext2/Ext3块分配相比，延迟分配尽可能的延缓块的分配。

传统的立即分配方法缺点：举例来说，对于一个写调用，文件系统代码立刻分配数据块的存放位置，甚至是数据还会在cache中存放一段时间才写回磁盘的情况。当一个进程持续的向文件内写数据，那么接下来的每次写操作都会为数据分配物理块，而不知道文件正在持续的增长。

而延迟分配，在调用写操作时，如果数据仅仅写到cache中，并不会立即分配块，而是等到真正向磁盘写入的时候才进行分配。这就使得块分配器有机会优化，组合这些分配的块。延迟分配需要同extents和多块分配配合。因为在一些工作场景下，文件写入磁盘时是按照extents进行分配的，而此时调用的分配器也是mballoc分配器。

2.6 快速fsck

fsck操作非常耗时，特别是fsck的第一步：检查文件系统中的所有inode。Ext4中，在每一组的inode表中存放着一个未用的inode链表，所以fsck不需要检查这些未用的inodes。因此整个的fsck时间可以改善2到20倍（依赖于未用inode的数目）。必须要注意，是fsck创建的未用inode链表，而不是Ext4创建的。必须首先运行fsck来创建unused indes链表，下一次的fsck才会便快。

2.7 日志checksumming

日志是磁盘中最常用的部分，因此使得这部分的块更容易发生硬件错误。从出错的日志恢复系统可能会导致更大的错误。Ext4使用check summing来确保journal数据是否有效。此外日志checksumming还有附加的效果：它允许把ext3文件系统的两阶段提交变为一阶段提交，在某些情况下，可以得到20%的速度增加，因此可靠性和速度同时得到了改善。

2.8 非日志模式

日志确保文件系统的一致性，然而也增加了系统负载。在某些特殊场合下，数据完整性不重要时，可以运行无日志的Ext4。Ext4日志功能可以被disable掉，这样可以稍微改善性能

2.9 在线碎片整理

（这个功能正在开发当中，可能在未来的某个版本中发布），延迟分配，extents和多块分配用来减少磁盘碎片化，但是文件系统仍然可能碎片化。比如：连续写三个文件到磁盘上。某一天你想要更改第二个文件，并且修改会增加一点长度。此时只能为增加部分在其他位置分配空间，这就导致第二个文件被第三个文件隔开。

此外，文件系统有时仅关注确定类型的碎片化，比如和启动相关的文件，但是文件系统并不知道哪些文件是启动相关的。为了解决这个问题，Ext4引入了在线碎片整理。e4defrag工具可以用来整理单个文件或整个文件系统的碎片。

2.10 inode相关功能

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

• 更大inode：Ext3支持可配置的inode尺寸，缺省尺寸为128 Bytes。Ext4缺省大小为256 Bytes，这样可以容纳更多额外的成员，比如纳秒时间戳或者inode版本，其余的空间则用来存储extend attributes。这使得访问这些属性的速度更快，改善使用这些扩展属性的应用性能3~7倍。
• 当一个目录被创建时，系统会为这个目录预留几个inodes，因为在将来可能会用到它们。这可以改善性能，因为在目录中创建新文件可以使用这些预留inode。文件创建和删除操作因此更加有效。
• 纳秒级时间戳意味着inode中类似 modified time的成员可以使用纳秒级精度，而在Ext3中是秒级。

2.11 持久存储预分配

这个功能出现在最近的kernel版本中，如果文件系统不支持预分配，glibc会模拟该功能以允许应用预先分配磁盘空间。应用通知文件系统提前分配空间，文件系统则提前分配必要的块和数据结构，直到应用真正需要写入数据。P2P应用自身会为一个持续数小时或数天的下载预分配必要的空间，但是使用文件系统的预分配效率更高。这个功能有几个好处：

1. 避免应用程序通过添0方式预分配。

2. 改善碎片化，因为所有的块都是一次性分配的，会尽可能的连续。

3. 确保应用预留他们所需要的磁盘空间，这对于实时应用是非常重要的，如果没有预分配，一个重要操作执行过程中可能会出现无磁盘可分配。

应用层可以通过libc的posix_fallocate()使用这个功能。

2.12 缺省使能barries

这个选项改善文件系统完整性，但是会带来一定的性能损失(可以使用"mount -o barrier=0"关闭该功能，如果正在benchmarking推荐关闭它)。文件系统代码必须在写日志提交记录前，确保所有的事物信息都已经写入日志中。按顺序写并不够，因为物理磁盘可能包含很大的内部cache，会重新对操作排序，以便获得更好的性能。所以文件系统必须显示的通知磁盘写入所有的日志数据到介质中，然后才能写commit record；如果commit record被先写到磁盘中，日志可能变得无效。内核block子系统通过使用barriers，确保在barrier之前的所有块写入介质之前，barrier后的任何块都不会写入介质。通过barrier，文件系统可以确保文件系统在任何时候都会保持一致。