Second Version

sources/talk/20180402 Understanding Linux filesystems- ext4 and beyond.md

@@ -12,15 +12,13 @@
 
 #### MINIX 文件系统
 
-在有 ext之前, 使用的是 MINIX 文件系统。如果你不熟悉 Linux 历史, 那么可以理解为 MINIX 相对于 IBM PC/AT 微型计算机来说是一个非常小的类 Unix 系统。Andrew Tannenbaum
-为了教学的目的而开发了它并于1987年发布了源代码（印刷版！）。
+在有 ext之前, 使用的是 MINIX 文件系统。如果你不熟悉 Linux 历史, 那么可以理解为 MINIX 相对于 IBM PC/AT 微型计算机来说是一个非常小的类 Unix 系统。Andrew Tannenbaum 为了教学的目的而开发了它并于 1987 年发布了源代码（印刷版！）。
 
 
 ![](https://opensource.com/sites/default/files/styles/panopoly_image_original/public/u128651/ibm_pc_at.jpg?itok=Tfk3hQYB)
 
 
-虽然你可以读阅 MINIX 的源代码，但实际上它并不是免费的来源软件（FOSS）。Tannebaum 书的出版商要求你花69美元的许可费来操作 MINIX，而这笔费用包含在书籍的费用中。尽管 如此，在那时来说
-非常便宜，并且 MINIX 的使用得到迅速发展，很快超过了 Tannebaum 当初使用它来教授操作系统编码的意图。在整个 20 世纪 90 年代，你可以发现 MINIX 安装在世界各个大学里面非常流行。
+虽然你可以读阅 MINIX 的源代码，但实际上它并不是免费的来源软件（FOSS）。Tannebaum 书的出版商要求你花69美元的许可费来操作 MINIX，而这笔费用包含在书籍的费用中。尽管 如此，在那时来说非常便宜，并且 MINIX 的使用得到迅速发展，很快超过了 Tannebaum 当初使用它来教授操作系统编码的意图。在整个 20 世纪 90 年代，你可以发现 MINIX 安装在世界各个大学里面非常流行。
 而此时，年轻的 Lius Torvalds 使用 MINIX 来开发原始 Linux 内核，并于 1991 年首次公布。而后在 1992 年 12 月在 GPL 下发布。
 
 但是等等，这是一篇以*文件系统*为主题的文章不是吗？是的，MINIX 有自己的文件系统，早期的 Linux 版本依赖于它。就像 MINIX 一样，Linux 也可以含糊地被描述为同类的 “玩具” 示例 ———— MINX 文件系统最多能处理
@@ -41,8 +39,7 @@ Rémy 很快就意识到 ext 的局限性，所以一年后他设计出 ext2 替
 
 Ext2 提供了 TB 级的千兆字节和文件系统规格的最大文件大小，使其在 20 世纪 90 年代牢牢地位于大联盟中。很快它被广泛地使用，无论是在 Linux 内核中还是最终在 MINIX 中，且第三方模块使其可以用于 MacOs 和 Windows。
 
-但这里仍然有一些问题需要解决：ext2 文件系统与 20世纪90年代的大多数文件系统一样，如果在将要写入数据到磁盘的时候，系统发生奔溃或断电，则容易发生灾难性的数据损坏。
-随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。
+但这里仍然有一些问题需要解决：ext2 文件系统与 20 世纪 90 年代的大多数文件系统一样，如果在将要写入数据到磁盘的时候，系统发生奔溃或断电，则容易发生灾难性的数据损坏。随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。
 
 尽管存在这些问题，但今天 ext2 还是用在某些特殊的情况下 ———— 最常见的是，作为便携式 USB 拇指驱动器的格式。
 
@@ -55,13 +52,9 @@ Ext2 提供了 TB 级的千兆字节和文件系统规格的最大文件大小
 
 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** , and **writeback**.
 
@@ -93,12 +86,9 @@ Ext4 特地设计为尽可能地向后兼容 ext3。这不仅允许 ext3 文件
 
 #### 大文件系统
 
-Ext3 文进系统使用 32 为寻址，将它们限制为 2 个 TiB 文件系统和16个TiB文件系统
+Ext3 文进系统使用 32 为寻址，将它们限制为 2 个 TiB 文件系统和 16 个 TiB 文件系统（假设一个 4 KiB 块大小；一些 ext3 文件系统使用较小的块大小，因此对其进一步做了限制）。
 
-（假设一个 4 KiB 块大小；一些 ext3 文件系统使用较小的块大小，因此对其进一步做了限制）。
-
-Ext4 使用48位的内部寻址，理论上可以在文件系统上分配高达 16TiB 的文件，其中最高可达 1000 000 TiB（1EiB）。
-有些用户区实用程序仍然将 ext4 早期实现限制为 16TiB文件系统，但截至2011年，e2fsprogs 已经直接支持 >16TiB ext4文件系统。例如，红帽企业 Linux 合同上仅支持最高 50TiB 的 ext4 文件系统，并建议不超过 100TiB的卷。
+Ext4 使用48位的内部寻址，理论上可以在文件系统上分配高达 16TiB 的文件，其中最高可达 1000 000 TiB（1EiB）。有些用户区实用程序仍然将 ext4 早期实现限制为 16TiB 文件系统，但截至 2011 年，e2fsprogs 已经直接支持 >16TiB ext4 文件系统。例如，红帽企业 Linux 合同上仅支持最高 50TiB 的 ext4 文件系统，并建议不超过 100TiB 的卷。
 
 #### 分配改进
 
@@ -110,7 +100,7 @@ Ext4 在将存储快写入磁盘之前对存储块的分配方式进行了大量
 
 ##### 多块分配
 
-Ext3 为每一个新分配的块调用一次块分配器。当多个编写器同时打开时，这很容易导致严重的碎片。然而，ext4 使用延迟分配，这允许它合并写入并更好地决定如何为尚未提交的写入分配快
+Ext3 为每一个新分配的块调用一次块分配器。当多个编写器同时打开时，这很容易导致严重的碎片。然而，ext4 使用延迟分配，这允许它合并写入并更好地决定如何为尚未提交的写入分配块。
 
 ##### 持续的预分配
 
@@ -127,8 +117,7 @@ Ext3 为每一个新分配的块调用一次块分配器。当多个编写器同
 
 `fd=open("file" ,O_TRUNC); write(fd, data); close(fd);`
 
-使用旧的文件系统, `close(fd);` 足以保证 `file` 中的内存刷新到磁盘。即使严格来说，写不是事务性的，但如果文件关闭后发生崩溃，则丢失数据的风险很小。
-如果写入不成功（由于程序上的错误、磁盘上的错误、断电等），文件的原始版本和交新版本都可能丢失数据或损坏。如果其他进程在写入文件时访问文件，则会看到损坏的版本。
+使用旧的文件系统, `close(fd);` 足以保证 `file` 中的内存刷新到磁盘。即使严格来说，写不是事务性的，但如果文件关闭后发生崩溃，则丢失数据的风险很小。如果写入不成功（由于程序上的错误、磁盘上的错误、断电等），文件的原始版本和交新版本都可能丢失数据或损坏。如果其他进程在写入文件时访问文件，则会看到损坏的版本。
 如果其他进程打开文件并且不希望其内容发生更改 —— 如果其他进程在写入文件时访问该文件，则会看到损坏的版本。入股其他进程打开文件并且不希望其内容大声更改 —— 例如，隐射到多个正在运行的程序的共享库 —— 它们可能会崩溃。
 
 为了避免这些问题，一些程序员完全避免使用 `O_TRUNC`。相反，他们可能会写入一个新文件，关闭它，然后将其重命名为旧文件名：
@@ -180,7 +169,6 @@ ext2 和 ext3 都不直接支持在线碎片整理 —— 即在挂载时会对
 
 Ext4通过 **e4defrag** 解决了这个问题，且是一个在线、内核模式、文件系统感知、块和范围级别的碎片整理实用程序。
 
-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ### 正在进行的ext4开发
 
 正如 Monty Python （ plague victim？？）曾经说过的那样，Ext4 “还没完全死！” 虽然它的[主要开发人员][7]认为它只是一个真正的[下一代文件系统][8]的权宜之计，但是在一段时间内，没有任何可能的候选人准备好（由于技术或许可问题）部署为根文件系统。
@@ -189,13 +177,10 @@ Ext4通过 **e4defrag** 解决了这个问题，且是一个在线、内核模
 
 #### 元数据校验和
 
-由于 ext4 具有冗余超级块，因此为文件系统校验其中的元数据提供了一种方法，可以自行确定主超级块是否已损坏并需要使用备用块。可以在没有校验和的情况下
-从损坏的超级块恢复 —— 但是用户首先需要意识到它已损坏，然后尝试使用备用方法手动挂载文件系统。由于在某些情况下，使用损坏的主超级块安装文件系统读写
+由于 ext4 具有冗余超级块，因此为文件系统校验其中的元数据提供了一种方法，可以自行确定主超级块是否已损坏并需要使用备用块。可以在没有校验和的情况下，从损坏的超级块恢复 —— 但是用户首先需要意识到它已损坏，然后尝试使用备用方法手动挂载文件系统。由于在某些情况下，使用损坏的主超级块安装文件系统读写
 可能会造成进一步的损坏，即使是经验丰富的用户也无法避免，这也不是一个完美的解决方案！
 
-与 btrfs 或 zfs 等下一代文件系统提供的极其强大的每块校验和相比，ext4 的元数据校验和功能非常弱。但它总比没有好。
-
-虽然校验和所有的事情都听起来很简单！—— 事实上，将校验和连接到文件系统有一些重大的挑战； 请参阅[设计文档][9]了解详细信息。
+与 btrfs 或 zfs 等下一代文件系统提供的极其强大的每块校验和相比，ext4 的元数据校验和功能非常弱。但它总比没有好。虽然校验和所有的事情都听起来很简单！—— 事实上，将校验和连接到文件系统有一些重大的挑战； 请参阅[设计文档][9]了解详细信息。
 
 #### 一流的配额支持
 
@@ -207,7 +192,6 @@ Ext4通过 **e4defrag** 解决了这个问题，且是一个在线、内核模
 较大的存储块可以显着减少碎片并提高性能，代价是增加“松弛”空间（当您只需要块的一部分来存储文件或文件的最后一块时留下的空间）。
 
 您可以在[设计文档][11]中查看详细说明。
-+++++++++++++++++++++++++++++++++++++++++++++==
 
 ### ext4的实际限制
 
@@ -222,7 +206,6 @@ Ext4 也不足以保证数据的完整性。随着日志记录的重大进展又
 在最后两个项目的基础上，ext4 只是一个纯文件系统，而不是存储卷管理器。这意味着，即使你有多个磁盘 —— 因此也就是奇偶校验或冗余，理论上你可以恢复损坏的数据从 —— ext4 
 但无法知道使用它是否对你有利。虽然理论上可以在离散层中分离文件系统和存储卷管理系统而不会丢失自动损坏检测和修复功能，但这不是当前存储系统的设计方式，
 并且它将给新设计带来重大挑战。
-+++++++++++++++++++++++++++++++++=
 
 ### 备用文件系统
 在我们开始之前，提醒一句：要非常小心这是没有内置任何备用的文件系统，并直接支持为您分配的主线内核的一部分！