mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-25 00:50:15 +08:00
PRF:20180402 Understanding Linux filesystems- ext4 and beyond.md
部分
This commit is contained in:
Xingyu.Wang
parent
40ac803166
commit
09f73b9566
@ -1,43 +1,46 @@
|
||||
|
||||
理解 Linux 文件系统：ext4 以及更多文件系统
|
||||
==========================================
|
||||
理解 Linux 文件系统：ext4 等文件系统
|
||||
=======
|
||||
|
||||
> 了解 ext4 的历史，包括其与 ext3 和之前的其它文件系统之间的区别。
|
||||
|
||||
|
||||
|
||||
目前的大部分 Linux 文件系统都默认采用 ext4 文件系统, 正如以前的 Linux 发行版默认使用 ext3、ext2 以及更久前的 ext。对于不熟悉 Linux 或文件系统的朋友而言，你可能不清楚 ext4 相对于上一版本 ext3 带来了什么变化。你可能还想知道在一连串关于可替代文件系统例如 btrfs、xfs 和 zfs 不断被发布的情况下，ext4 是否仍然能得到进一步的发展 。
|
||||
|
||||
在一篇文章中，我们不可能讲述文件系统的所有方面，但我们尝试让您尽快了解 Linux 默认文件系统的发展历史，包括它的产生以及未来发展。我仔细研究了维基百科里的各种关于 ext 文件系统文章、kernel.org‘s wiki 中关于 ext4 的条目以及结合自己的经验写下这篇文章。
|
||||
目前的大部分 Linux 文件系统都默认采用 ext4 文件系统, 正如以前的 Linux 发行版默认使用 ext3、ext2 以及更久前的 ext。
|
||||
|
||||
对于不熟悉 Linux 或文件系统的朋友而言，你可能不清楚 ext4 相对于上一版本 ext3 带来了什么变化。你可能还想知道在一连串关于替代的文件系统例如 btrfs、xfs 和 zfs 不断被发布的情况下，ext4 是否仍然能得到进一步的发展。
|
||||
|
||||
在一篇文章中，我们不可能讲述文件系统的所有方面，但我们尝试让您尽快了解 Linux 默认文件系统的发展历史，包括它的产生以及未来发展。我仔细研究了维基百科里的各种关于 ext 文件系统文章、kernel.org 的 wiki 中关于 ext4 的条目以及结合自己的经验写下这篇文章。
|
||||
|
||||
### ext 简史
|
||||
|
||||
#### MINIX 文件系统
|
||||
|
||||
在有 ext 之前, 使用的是 MINIX 文件系统。如果你不熟悉 Linux 历史, 那么可以理解为 MINIX 相对于 IBM PC/AT 微型计算机来说是一个非常小的类 Unix 系统。Andrew Tannenbaum 为了教学的目的而开发了它并于 1987 年发布了源代码（印刷版！）。
|
||||
|
||||
在有 ext 之前, 使用的是 MINIX 文件系统。如果你不熟悉 Linux 历史, 那么可以理解为 MINIX 是用于 IBM PC/AT 微型计算机的一个非常小的类 Unix 系统。Andrew Tannenbaum 为了教学的目的而开发了它，并于 1987 年发布了源代码（以印刷版的格式！）。
|
||||
|
||||
|
||||
|
||||
*IBM 1980 中期的 PC/AT，[MBlairMartin](https://commons.wikimedia.org/wiki/File:IBM_PC_AT.jpg)，[CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.en)*
|
||||
|
||||
虽然你可以读阅 MINIX 的源代码，但实际上它并不是免费的开源软件（FOSS）。出版 Tannebaum 著作的出版商要求你花 69 美元的许可费来获得 MINIX 的操作权，而这笔费用包含在书籍的费用中。尽管如此，在那时来说非常便宜，并且 MINIX 的使用得到迅速发展，很快超过了 Tannebaum 当初使用它来教授操作系统编码的意图。在整个 20 世纪 90 年代，你可以发现 MINIX 的安装在世界各个大学里面非常流行。
|
||||
而此时，年轻的 Lius Torvalds 使用 MINIX 来开发原始 Linux 内核，并于 1991 年首次公布。而后在 1992 年 12 月在 GPL 开源协议下发布。
|
||||
虽然你可以细读 MINIX 的源代码，但实际上它并不是自由开源软件（FOSS）。出版 Tannebaum 著作的出版商要求你花 69 美元的许可费来运行 MINIX，而这笔费用包含在书籍的费用中。尽管如此，在那时来说非常便宜，并且 MINIX 的使用得到迅速发展，很快超过了 Tannebaum 当初使用它来教授操作系统编码的意图。在整个 20 世纪 90 年代，你可以发现 MINIX 的安装在世界各个大学里面非常流行。而此时，年轻的 Lius Torvalds 使用 MINIX 来开发原始 Linux 内核，并于 1991 年首次公布。而后在 1992 年 12 月在 GPL 开源协议下发布。
|
||||
|
||||
但是等等，这是一篇以*文件系统*为主题的文章不是吗？是的，MINIX 有自己的文件系统，早期的 Linux 版本依赖于它。跟 MINIX 一样，Linux 的文件系统也如同玩具那般小 —— MINX 文件系统最多能处理 14 个字符的文件名，并且只能处理 64MB 的存储空间。到了 1991 年，一般的硬盘尺寸已经达到了 40-140MB。很显然，Linux 需要一个更好的文件系统。
|
||||
但是等等，这是一篇以*文件系统*为主题的文章不是吗？是的，MINIX 有自己的文件系统，早期的 Linux 版本依赖于它。跟 MINIX 一样，Linux 的文件系统也如同玩具那般小 —— MINIX 文件系统最多能处理 14 个字符的文件名，并且只能处理 64MB 的存储空间。到了 1991 年，一般的硬盘尺寸已经达到了 40-140MB。很显然，Linux 需要一个更好的文件系统。
|
||||
|
||||
#### ext
|
||||
|
||||
当 Linus 开发出刚起步的 Linux 内核时，Rémy Card 从事第一代的 ext 文件系统的开发工作。 ext 文件系统在 1992 首次实现并发布 —— 仅在 Linux 首次发布后的一年! —— ext 解决了 MINIX 文件系统中最糟糕的问题。
|
||||
|
||||
1992年的 ext 使用在 Linux 内核中的新虚拟文件系统（VFS）抽象层。与之前的 MINIX 文件系统不同的是，ext 可以处理高达 2GB 存储空间并处理 255 个字符的文件名。
|
||||
1992 年的 ext 使用在 Linux 内核中的新虚拟文件系统（VFS）抽象层。与之前的 MINIX 文件系统不同的是，ext 可以处理高达 2GB 存储空间并处理 255 个字符的文件名。
|
||||
|
||||
但 ext 并没有长时间占统治地位，主要是由于它的原始时间戳（每个文件仅有一个时间戳，而不是今天我们所熟悉的有 inode 、最近文件访问时间和最新文件修改时间的时间戳。）仅仅一年后，ext2 就替代了它。
|
||||
但 ext 并没有长时间占统治地位，主要是由于它原始的时间戳（每个文件仅有一个时间戳，而不是今天我们所熟悉的有 inode 、最近文件访问时间和最新文件修改时间的时间戳。）仅仅一年后，ext2 就替代了它。
|
||||
|
||||
#### ext2
|
||||
|
||||
Rémy 很快就意识到 ext 的局限性，所以一年后他设计出 ext2 替代它。当 ext 仍然根植于 "玩具” 操作系统时，ext2 从一开始就被设计为一个商业级文件系统，沿用 BSD 的 Berkeley 文件系统的设计原理。
|
||||
Rémy 很快就意识到 ext 的局限性，所以一年后他设计出 ext2 替代它。当 ext 仍然根植于 “玩具” 操作系统时，ext2 从一开始就被设计为一个商业级文件系统，沿用 BSD 的 Berkeley 文件系统的设计原理。
|
||||
|
||||
Ext2 提供了 GB 级别的最大文件大小和 TB 级别的文件系统大小，使其在 20 世纪 90 年代的地位牢牢巩固在文件系统大联盟中。很快它被广泛地使用，无论是在 Linux 内核中还是最终在 MINIX 中，且利用第三方模块可以使其应用于 MacOs 和 Windows。
|
||||
Ext2 提供了 GB 级别的最大文件大小和 TB 级别的文件系统大小，使其在 20 世纪 90 年代的地位牢牢巩固在文件系统大联盟中。很快它被广泛地使用，无论是在 Linux 内核中还是最终在 MINIX 中，且利用第三方模块可以使其应用于 MacOS 和 Windows。
|
||||
|
||||
但这里仍然有一些问题需要解决：ext2 文件系统与 20 世纪 90 年代的大多数文件系统一样，如果在将数据写入到磁盘的时候，系统发生奔溃或断电，则容易发生灾难性的数据损坏。随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。
|
||||
但这里仍然有一些问题需要解决：ext2 文件系统与 20 世纪 90 年代的大多数文件系统一样，如果在将数据写入到磁盘的时候，系统发生崩溃或断电，则容易发生灾难性的数据损坏。随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。
|
||||
|
||||
尽管存在这些问题，但今天 ext2 还是用在某些特殊的情况下 —— 最常见的是，作为便携式 USB 拇指驱动器的文件系统格式。
|
||||
|
||||
@ -45,21 +48,19 @@ Ext2 提供了 GB 级别的最大文件大小和 TB 级别的文件系统大小
|
||||
|
||||
1998 年, 在 ext2 被采用后的 6 年后，Stephen Tweedie 宣布他正在致力于改进 ext2。这成了 ext3，并于 2001 年 11 月在 2.4.15 内核版本中被采用到 Linux 内核主线中。
|
||||
|
||||
|
||||
![Packard Bell 计算机][2]
|
||||
|
||||
20世纪90年代中期的 Packard Bell 计算机, [Spacekid][3], [CC0][4]
|
||||
*20 世纪 90 年代中期的 Packard Bell 计算机，[Spacekid][3]，[CC0][4]*
|
||||
|
||||
在大部分情况下，Ext2 在 Linux 发行版中做得很好，但像 FAT、FAT32、HFS 和当时的其他文件系统一样 —— 在断电时容易发生灾难性的破坏。如果在将数据写入文件系统时候发生断电，则可能会将其留在所谓 *不一致* 的状态 —— 事情只完成一半而另一半未完成。这可能导致大量文件丢失或损坏，这些文件与正在保存的文件无关甚至导致整个文件系统无法卸载。
|
||||
在大部分情况下，Ext2 在 Linux 发行版中工作得很好，但像 FAT、FAT32、HFS 和当时的其他文件系统一样 —— 在断电时容易发生灾难性的破坏。如果在将数据写入文件系统时候发生断电，则可能会将其留在所谓*不一致*的状态 —— 事情只完成一半而另一半未完成。这可能导致大量文件丢失或损坏，这些文件与正在保存的文件无关甚至导致整个文件系统无法卸载。
|
||||
|
||||
Ext3 和 20 世纪 90 年代后期的其他文件系统，如微软的 NTFS ，使用*日志*来解决这个问题。 日志是磁盘上的一种特殊分配，其写入存储在事务中；如果事务完成写入磁盘，则日志中的数据将提交给文件系统它本身。如果文件在它提交操作前崩溃，则重新启动的系统识别其为未完成的事务而将其进行回滚，就像从未发生过一样。这意味着正在处理的文件可能依然会丢失，但文件系统本身保持一致，且其他所有数据都是安全的。
|
||||
Ext3 和 20 世纪 90 年代后期的其他文件系统，如微软的 NTFS ，使用*日志*来解决这个问题。日志是磁盘上的一种特殊的分配区域，其写入被存储在事务中；如果该事务完成磁盘写入，则日志中的数据将提交给文件系统自身。如果系统在该操作提交前崩溃，则重新启动的系统识别其为未完成的事务而将其进行回滚，就像从未发生过一样。这意味着正在处理的文件可能依然会丢失，但文件系统*本身*保持一致，且其他所有数据都是安全的。
|
||||
|
||||
在使用 ext3 文件系统的 Linux 内核中实现了三个级别的日志记录方式:**日记（journal）** , **顺序（ordered）** , 和 **回写（writeback）**。
|
||||
|
||||
* **日记（Journal）** 是最低风险模式，在将数据和元数据提交给文件系统之前将其写入日志。这可以保证正在写入的文件与整个文件系统的一致性，但其显著降低了性能。
|
||||
* **顺序（Ordered）** 是大多数 Linux 发行版默认模式；ordered 模式将元数据写入日志且直接将数据提交到文件系统。顾名思义，这里的操作顺序是固定的：首先，元数据提交到日志；其次，数据写入文件系统，然后才将日志中关联的元数据更新到文件系统。这确保了在发生奔溃时，与未完整写入相关联的元数据仍在日志中，且文件系统可以在回滚日志时清理那些不完整的写入事务。在 ordered 模式下，系统崩溃可能导致在崩溃期间文件被主动写入或损坏，但文件系统它本身 —— 以及未被主动写入的文件 —— 确保是安全的。
|
||||
* **回写（Writeback）** 是第三种模式 —— 也是最不安全的日志模式。在 writeback 模式下,像 ordered 模式一样，元数据会被记录，但数据不会。与 ordered 模式不同，元数据和数据都可以以任何有利于获得最佳性能的顺序写入。这可以显著提高性能，但安全性低很多。尽管 wireteback 模式仍然保证文件系统本身的安全性，但在奔溃或之前写入的文件很容易丢失或损坏。
|
||||
在使用 ext3 文件系统的 Linux 内核中实现了三个级别的日志记录方式：<ruby>日记<rt>journal</rt></ruby>、<ruby>顺序<rt>ordered</rt></ruby>和<ruby>回写<rt>writeback</rt></ruby>。
|
||||
|
||||
* **日记** 是最低风险模式，在将数据和元数据提交给文件系统之前将其写入日志。这可以保证正在写入的文件与整个文件系统的一致性，但其显著降低了性能。
|
||||
* **顺序** 是大多数 Linux 发行版默认模式；顺序模式将元数据写入日志而直接将数据提交到文件系统。顾名思义，这里的操作顺序是固定的：首先，元数据提交到日志；其次，数据写入文件系统，然后才将日志中关联的元数据更新到文件系统。这确保了在发生崩溃时，那些与未完整写入相关联的元数据仍在日志中，且文件系统可以在回滚日志时清理那些不完整的写入事务。在顺序模式下，系统崩溃可能导致在崩溃期间文件的错误被主动写入，但文件系统它本身 —— 以及未被主动写入的文件 —— 确保是安全的。
|
||||
* **回写** 是第三种模式 —— 也是最不安全的日志模式。在回写模式下，像顺序模式一样，元数据会被记录到日志，但数据不会。与顺序模式不同，元数据和数据都可以以任何有利于获得最佳性能的顺序写入。这可以显著提高性能，但安全性低很多。尽管回写模式仍然保证文件系统本身的安全性，但在崩溃或崩溃之前写入的文件很容易丢失或损坏。
|
||||
|
||||
跟之前的 ext2 类似，ext3 使用 16 位内部寻址。这意味着对于有着 4K 块大小的 ext3 在最大规格为 16TiB 的文件系统中可以处理的最大文件大小为 2TiB。
|
||||
|
||||
@ -67,101 +68,99 @@ Ext3 和 20 世纪 90 年代后期的其他文件系统，如微软的 NTFS ，
|
||||
|
||||
Theodore Ts'o (是当时 ext3 主要开发人员) 在 2006 年发表的 ext4 ,于两年后在 2.6.28 内核版本中被加入到了 Linux 主线。
|
||||
|
||||
Ts’o 将 ext4 描述为一个显著扩展 ext3 的临时技术，但它仍然依赖于旧技术。他预计 ext4 终将会被真正的下一代文件系统所取代。
|
||||
Ts’o 将 ext4 描述为一个显著扩展 ext3 但仍然依赖于旧技术的临时技术。他预计 ext4 终将会被真正的下一代文件系统所取代。
|
||||
|
||||
|
||||
|
||||
Ext4 在功能上与 Ext3 在功能上非常相似，但大大支持文件系统、提高了对碎片的抵抗力，有更高的性能以及更好的时间戳。
|
||||
*Dell Precision 380 工作站，[Lance Fisher](https://commons.wikimedia.org/wiki/File:Dell_Precision_380_Workstation.jpeg)，[CC BY-SA 2.0](https://creativecommons.org/licenses/by-sa/2.0/deed.en)*
|
||||
|
||||
### Ext4 vs ext3
|
||||
Ext4 在功能上与 Ext3 在功能上非常相似，但支持大文件系统、提高了对碎片的抵抗力，有更高的性能以及更好的时间戳。
|
||||
|
||||
Ext3 和 Ext4 有一些非常明确的差别，在这里集中讨论下。
|
||||
### ext4 vs ext3
|
||||
|
||||
ext3 和 ext4 有一些非常明确的差别，在这里集中讨论下。
|
||||
|
||||
#### 向后兼容性
|
||||
|
||||
Ext4 特地设计为尽可能地向后兼容 ext3。这不仅允许 ext3 文件系统升级到 ext4；也允许 ext4 驱动程序在 ext3 模式下自动挂载 ext3 文件系统，因此使它无需单独维护两个代码库。
|
||||
ext4 特地设计为尽可能地向后兼容 ext3。这不仅允许 ext3 文件系统原地升级到 ext4；也允许 ext4 驱动程序以 ext3 模式自动挂载 ext3 文件系统，因此使它无需单独维护两个代码库。
|
||||
|
||||
#### 大文件系统
|
||||
|
||||
Ext3 文进系统使用 32 为寻址，这限制它仅支持 2TiB 文件大小和 16TiB 文件系统系统大小（这是假设在块大小为 4KiB 的情况下，一些 ext3 文件系统使用更小的块大小，因此对其进一步做了限制）。
|
||||
ext3 文件系统使用 32 位寻址，这限制它仅支持 2TiB 文件大小和 16TiB 文件系统系统大小（这是假设在块大小为 4KiB 的情况下，一些 ext3 文件系统使用更小的块大小，因此对其进一步被限制）。
|
||||
|
||||
Ext4 使用 48 位的内部寻址，理论上可以在文件系统上分配高达 16TiB 大小的文件，其中文件系统大小最高可达 1000 000 TiB（1EiB）。在早期 ext4 的实现中 有些用户空间的程序仍然将其限制为最大大小为 16TiB 的文件系统，但截至 2011 年，e2fsprogs 已经直接支持大于 16TiB 大小的 ext4 文件系统。例如，红帽企业 Linux 合同上仅支持最高 50TiB 的 ext4 文件系统，并建议 ext4 卷不超过 100TiB。
|
||||
ext4 使用 48 位的内部寻址，理论上可以在文件系统上分配高达 16TiB 大小的文件，其中文件系统大小最高可达 1000000 TiB（1EiB）。在早期 ext4 的实现中有些用户空间的程序仍然将其限制为最大大小为 16TiB 的文件系统，但截至 2011 年，e2fsprogs 已经直接支持大于 16TiB 大小的 ext4 文件系统。例如，红帽企业 Linux 在其合同上仅支持最高 50TiB 的 ext4 文件系统，并建议 ext4 卷不超过 100TiB。
|
||||
|
||||
#### 分配改进
|
||||
#### 分配方式改进
|
||||
|
||||
Ext4 在将存储块写入磁盘之前对存储块的分配方式进行了大量改进，这可以显著提高读写性能。
|
||||
ext4 在将存储块写入磁盘之前对存储块的分配方式进行了大量改进，这可以显著提高读写性能。
|
||||
|
||||
##### 区段（extent）
|
||||
##### 区段
|
||||
|
||||
extent 是一系列连续的物理块大小 (最多达 128 MiB，假设块大小为 4KiB），可以一次性保留和寻址。使用区段可以减少给定未见所需的 inode 数量，并显著减少碎片并提高写入大文件时的性能。
|
||||
<ruby>区段<rt>extent</rt></ruby>是一系列连续的物理块 (最多达 128 MiB，假设块大小为 4KiB），可以一次性保留和寻址。使用区段可以减少给定文件所需的 inode 数量，并显著减少碎片并提高写入大文件时的性能。
|
||||
|
||||
##### 多块分配
|
||||
|
||||
Ext3 为每一个新分配的块调用一次块分配器。当多个块调用同时打开分配器时，很容易导致严重的碎片。然而，ext4 使用延迟分配，这允许它合并写入并更好地决定如何为尚未提交的写入分配块。
|
||||
ext3 为每一个新分配的块调用一次块分配器。当多个写入同时打开分配器时，很容易导致严重的碎片。然而，ext4 使用延迟分配，这允许它合并写入并更好地决定如何为尚未提交的写入分配块。
|
||||
|
||||
##### 持续的预分配
|
||||
##### 持久的预分配
|
||||
|
||||
在为文件预分配磁盘空间时，大部分文件系统必须在创建时将零写入该文件的块中。Ext4 允许使用 `fallocate()`，它保证了空间的可用性（并试图为它找到连续的空间），而不需要县写入它。
|
||||
这显著提高了写入和将来读取流和数据库应用程序的写入数据的性能。
|
||||
在为文件预分配磁盘空间时，大部分文件系统必须在创建时将零写入该文件的块中。ext4 允许替代使用 `fallocate()`，它保证了空间的可用性（并试图为它找到连续的空间），而不需要先写入它。这显著提高了写入和将来读取流和数据库应用程序的写入数据的性能。
|
||||
|
||||
##### 延迟分配
|
||||
|
||||
这是一个耐人嚼味而有争议性的功能。延迟分配允许 ext4 等待分配将写入数据的实际块，直到它准备好将数据提交到磁盘。（相比之下，即使数据仍然在写入缓存，ext3 也会立即分配块。）
|
||||
这是一个耐人寻味而有争议性的功能。延迟分配允许 ext4 等待分配将写入数据的实际块，直到它准备好将数据提交到磁盘。（相比之下，即使数据仍然在往写入缓存中写入，ext3 也会立即分配块。）
|
||||
|
||||
当缓存中的数据累积时，延迟分配块允许文件系统做出更好的选择。然而不幸的是，当程序员想确保数据完全刷新到磁盘时，它增加了在还没有专门编写调用 ‘fsync（）’方法的程序中的数据丢失的可能性。
|
||||
当缓存中的数据累积时，延迟分配块允许文件系统对如何分配块做出更好的选择，降低碎片（写入，以及稍后的读）并显著提升性能。然而不幸的是，它*增加*了还没有专门调用 `fsync()` 方法（当程序员想确保数据完全刷新到磁盘时）的程序的数据丢失的可能性。
|
||||
|
||||
假设一个程序完全重写了一个文件：
|
||||
|
||||
`fd=open("file" ,O_TRUNC); write(fd, data); close(fd);`
|
||||
```
|
||||
fd=open("file" ,O_TRUNC); write(fd, data); close(fd);
|
||||
```
|
||||
|
||||
使用旧的文件系统, `close(fd);` 足以保证 `file` 中的内存刷新到磁盘。即使严格来说，写不是事务性的，但如果文件关闭后发生崩溃，则丢失数据的风险很小。如果写入不成功（由于程序上的错误、磁盘上的错误、断电等），文件的原始版本和较新版本都可能丢失数据或损坏。如果其他进程在写入文件时访问文件，则会看到损坏的版本。
|
||||
如果其他进程打开文件并且不希望其内容发生更改 —— 例如，映射到多个正在运行的程序的共享库。这些进程可能会崩溃。
|
||||
使用旧的文件系统, `close(fd);` 足以保证 `file` 中的内容刷新到磁盘。即使严格来说，写不是事务性的，但如果文件关闭后发生崩溃，则丢失数据的风险很小。
|
||||
|
||||
如果写入不成功（由于程序上的错误、磁盘上的错误、断电等），文件的原始版本和较新版本都可能丢失数据或损坏。如果其他进程在写入文件时访问文件，则会看到损坏的版本。如果其他进程打开文件并且不希望其内容发生更改 —— 例如，映射到多个正在运行的程序的共享库。这些进程可能会崩溃。
|
||||
|
||||
为了避免这些问题，一些程序员完全避免使用 `O_TRUNC`。相反，他们可能会写入一个新文件，关闭它，然后将其重命名为旧文件名：
|
||||
|
||||
`fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");`
|
||||
```
|
||||
fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");
|
||||
```
|
||||
|
||||
在没有延迟分配的文件系统下，这足以避免上面列出的潜在的损坏和崩溃问题：因为`rename()` 是原子操作，所以它不会被崩溃中断；并且运行的程序将引用旧的。现在 `file` 的未链接版本主要有一个打开的文件文件句柄即可。
|
||||
但是因为 ext4 的延迟分配会导致写入被延迟和重新排序，`rename("newfile","file")` 可以在 `newfile` 的内容实际写入磁盘内容之前执行，这打开了并行进行再次获得 `file` 坏版本的问题。
|
||||
在*没有*延迟分配的文件系统下，这足以避免上面列出的潜在的损坏和崩溃问题：因为`rename()` 是原子操作，所以它不会被崩溃中断；并且运行的程序将继续引用旧的文件。现在 `file` 的未链接版本只要有一个打开的文件文件句柄即可。但是因为 ext4 的延迟分配会导致写入被延迟和重新排序，`rename("newfile","file")` 可以在 `newfile` 的内容实际写入磁盘内容之前执行，这出现了并行进行再次获得 `file` 坏版本的问题。
|
||||
|
||||
|
||||
为了缓解这种情况，Linux 内核（自版本 2.6.30 ）尝试检测这些常见代码情况并强制立即分配。这减少但不能防止数据丢失的可能性 —— 并且它对新文件没有任何帮助。如果你是一位开发人员，请注意：
|
||||
|
||||
保证数据立即写入磁盘的方法是正确调用 `fsync()` 。
|
||||
为了缓解这种情况，Linux 内核（自版本 2.6.30 ）尝试检测这些常见代码情况并强制立即分配。这会减少但不能防止数据丢失的可能性 —— 并且它对新文件没有任何帮助。如果你是一位开发人员，请注意：保证数据立即写入磁盘的唯一方法是正确调用 `fsync()` 。
|
||||
|
||||
#### 无限制的子目录
|
||||
|
||||
Ext3 仅限于 32000 个子目录；ext4 允许无限数量的子目录。从 2.6.23 内核版本开始，ext4 使用 HTree 索引来减少大量子目录的性能损失。
|
||||
ext3 仅限于 32000 个子目录；ext4 允许无限数量的子目录。从 2.6.23 内核版本开始，ext4 使用 HTree 索引来减少大量子目录的性能损失。
|
||||
|
||||
#### 日志校验
|
||||
|
||||
Ext3 没有对日志进行校验，这给内核直接控制之外的磁盘或控制器设备带来了自己的缓存问题。如果控制器或具有子集对缓存的磁盘确实无序写入，则可能会破坏 ext3 的日记事务顺序，
|
||||
从而可能破坏在崩溃期间（或之前一段时间）写入的文件。
|
||||
ext3 没有对日志进行校验，这给处于内核直接控制之外的磁盘或带有自己的缓存的控制器设备带来了问题。如果控制器或具有自己的缓存的磁盘脱离了写入顺序，则可能会破坏 ext3 的日记事务顺序，从而可能破坏在崩溃期间（或之前一段时间）写入的文件。
|
||||
|
||||
理论上，这个问题可以使用 write barriers —— 在安装文件系统时，你在挂载选项设置 `barrier=1` ，然后将设备 `fsync` 一直向下调用直到 metal。通过实践，可以发现存储设备和控制器经常不遵守 write barriers —— 提高性能（和 benchmarks，跟竞争对手比较），但增加了本应该防止数据损坏的可能性。
|
||||
理论上，这个问题可以使用写入<ruby>障碍<rt>barrier</rt></ruby> —— 在安装文件系统时，你在挂载选项设置 `barrier=1` ，然后设备就会忠实地执行 `fsync` 一直向下到底层硬件。通过实践，可以发现存储设备和控制器经常不遵守写入障碍 —— 提高性能（和跟竞争对手比较的性能基准），但增加了本应该防止数据损坏的可能性。
|
||||
|
||||
对日志进行校验和允许文件系统奔溃后意识到其某些条目在第一次安装时无效或无序。因此，这避免了即使部分存储设备不存在 barriers ，也会回滚部分或无序日志条目和进一步损坏的文件系统的错误。
|
||||
对日志进行校验和允许文件系统崩溃后第一次挂载时意识到其某些条目是无效或无序的。因此，这避免了回滚部分条目或无序日志条目的错误，并进一步损坏的文件系统——即使部分存储设备假做或不遵守写入障碍。
|
||||
|
||||
#### 快速文件系统检查
|
||||
|
||||
在 ext3 下，整个文件系统 —— 包括已删除或空文件 —— 在 `fsck` 被调用时需要检查。相比之下，ext4 标记了未分配块和 inode 表的小部分，从而允许 `fsck` 完全跳过它们。
|
||||
这大大减少了在大多数文件系统上运行 `fsck` 的时间，并从内核 2.6.24 开始实现。
|
||||
在 ext3 下，在 `fsck` 被调用时会检查整个文件系统 —— 包括已删除或空文件。相比之下，ext4 标记了 inode 表未分配的块和扇区，从而允许 `fsck` 完全跳过它们。这大大减少了在大多数文件系统上运行 `fsck` 的时间，它实现于内核 2.6.24。
|
||||
|
||||
#### 改进的时间戳
|
||||
|
||||
Ext3 提供粒度为一秒的时间戳。虽然足以满足大多数用途，但任务关键型应用程序经常需要更严格的时间控制。Ext4 通过提供纳秒级的时间戳，使其可用于那些企业，科学以及任务关键型的应用程序。
|
||||
ext3 提供粒度为一秒的时间戳。虽然足以满足大多数用途，但任务关键型应用程序经常需要更严格的时间控制。ext4 通过提供纳秒级的时间戳，使其可用于那些企业、科学以及任务关键型的应用程序。
|
||||
|
||||
Ext3文件系统也没有提供足够的位来存储 2038 年 1 月 18 日以后的日期。Ext4 在这里增加了两位，将 [the Unix epoch][5] 扩展了 408 年。如果你在公元 2446 年读到这篇文章，
|
||||
你很有可能已经转移到一个更好的文件系统 —— 如果你还在测量 UTC 00:00，1970 年 1 月 1 日以来的时间，这会让我非常非常高兴。
|
||||
ext3 文件系统也没有提供足够的位来存储 2038 年 1 月 18 日以后的日期。ext4 在这里增加了两个位，将 [Unix 纪元][5] 扩展了 408 年。如果你在公元 2446 年读到这篇文章，你很有可能已经转移到一个更好的文件系统 —— 如果你还在测量自 1970 年 1 月 1 日 00:00（UTC）以来的时间，这会让我死后得以安眠。
|
||||
|
||||
#### 在线碎片整理
|
||||
|
||||
ext2 和 ext3 都不直接支持在线碎片整理 —— 即在挂载时会对文件系统进行碎片整理。Ext2 有一个包含的实用程序，**e2defrag**，它的名字暗示 —— 它需要在文件系统未挂载时脱机运行。（显然，这对于根文件系统来说非常有问题。）在 ext3 中的情况甚至更糟糕 —— 虽然 ext3 比 ext2 更不容易受到严重碎片的影响，但 ext3 文件系统运行 **e2defrag** 可能会导致灾难性损坏和数据丢失。
|
||||
ext2 和 ext3 都不直接支持在线碎片整理 —— 即在挂载时会对文件系统进行碎片整理。ext2 有一个包含的实用程序，**e2defrag**，它的名字暗示 —— 它需要在文件系统未挂载时脱机运行。（显然，这对于根文件系统来说非常有问题。）在 ext3 中的情况甚至更糟糕 —— 虽然 ext3 比 ext2 更不容易受到严重碎片的影响，但 ext3 文件系统运行 **e2defrag** 可能会导致灾难性损坏和数据丢失。
|
||||
|
||||
尽管 ext3 最初被认为“不受碎片影响”，但对同一文件（例如 BitTorrent）采用大规模并行写入过程的过程清楚地表明情况并非完全如此。一些用户空间攻击和解决方法，例如 [Shake][6]，
|
||||
以这种或那种方式解决了这个问题 —— 但它们比真正的、文件系统感知的、内核级碎片整理过程更慢并且在各方面都不太令人满意。
|
||||
尽管 ext3 最初被认为“不受碎片影响”，但对同一文件（例如 BitTorrent）采用大规模并行写入过程的过程清楚地表明情况并非完全如此。一些用户空间的手段和解决方法，例如 [Shake][6]，以这样或那样方式解决了这个问题 —— 但它们比真正的、文件系统感知的、内核级碎片整理过程更慢并且在各方面都不太令人满意。
|
||||
|
||||
Ext4通过 **e4defrag** 解决了这个问题，且是一个在线、内核模式、文件系统感知、块和范围级别的碎片整理实用程序。
|
||||
ext4通过 **e4defrag** 解决了这个问题，且是一个在线、内核模式、文件系统感知、块和区段级别的碎片整理实用程序。
|
||||
|
||||
### 正在进行的ext4开发
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user