Second Version

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

@@ -12,23 +12,21 @@
 
 #### 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 文件系统最多能处理
+但是等等，这是一篇以*文件系统*为主题的文章不是吗？是的，MINIX 有自己的文件系统，早期的 Linux 版本依赖于它。就像 MINIX 一样，Linux 也可以含糊地被描述为同类的 “玩具” 示例 ———— MINX 文件系统最多能处理
 14个字符的文件名，并且只能处理 64MB 的存储空间。到了 1991 年，典型的硬盘尺寸已经达到了 40-140MB。很显然，Linux 需要一个更好的文件系统。
 
 #### ext
 
-当 Linus 开发出刚起步的 Linux 内核时，Rémy Card 开始开发第一个 ext 文件系统。 ext 文件系统在 1992 首次实现并发布 ———— 仅在 Linux 首次发布后的一年! ———— ext 解决了MINIX 
+当 Linus 开发出刚起步的 Linux 内核时，Rémy Card 开始开发第一个 ext 文件系统。 ext 文件系统在 1992 首次实现并发布 ———— 仅在 Linux 首次发布后的一年! ———— ext 解决了 MINIX 
 文件系统中最糟糕的问题。
 
 1992年的 ext 使用在 Linux 内核中的新虚拟文件系统（VFS）抽象层。与之前的 MINIX 文件系统不同的是，ext 可以处理高达 2GB 存储空间并处理 255 个字符的文件名。
@@ -37,31 +35,26 @@
 
 #### ext2
 
-Rémy 很快就意识到 ext 的局限性，所以一年后他设计出 ext2 替代它。虽然 ext 是源自 "玩具”操作系统，但 ext2 从一开始就被设计为一个商业级文件系统，沿用 BSD 的Berkeley 文件系统原则。
+Rémy 很快就意识到 ext 的局限性，所以一年后他设计出 ext2 替代它。虽然 ext 是源自 "玩具”操作系统，但 ext2 从一开始就被设计为一个商业级文件系统，沿用 BSD 的 Berkeley 文件系统原则。
 
 Ext2 提供了 TB 级的千兆字节和文件系统规格的最大文件大小，使其在 20 世纪 90 年代牢牢地位于大联盟中。很快它被广泛地使用，无论是在 Linux 内核中还是最终在 MINIX 中，且第三方模块使其可以用于 MacOs 和 Windows。
 
-但这里仍然有一些问题需要解决：ext2 文件系统与 20世纪90年代的大多数文件系统一样，如果在将要写入数据到磁盘的时候，系统发生奔溃或断电，则容易发生灾难性的数据损坏。
-随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。
+但这里仍然有一些问题需要解决：ext2 文件系统与 20 世纪 90 年代的大多数文件系统一样，如果在将要写入数据到磁盘的时候，系统发生奔溃或断电，则容易发生灾难性的数据损坏。随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。
 
 尽管存在这些问题，但今天 ext2 还是用在某些特殊的情况下 ———— 最常见的是，作为便携式 USB 拇指驱动器的格式。
 
 #### ext3
 
-1998 年, 在 ext2 被采用后的6年后，Stephen Tweedie 宣布他正在致力于改进 ext2。这成了 ext3，并于 2001 年 11 月被 2.4.15 内核版本采用进主线 Linux。
+1998 年, 在 ext2 被采用后的 6 年后，Stephen Tweedie 宣布他正在致力于改进 ext2。这成了 ext3，并于 2001 年 11 月被 2.4.15 内核版本采用进主线 Linux。
 
 
 ![Packard Bell 计算机][2]
 
 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**.
 
@@ -74,7 +67,7 @@ Ext3 和 20世纪90年代后期的其他文件系统，如微软的 NTFS ，使
 
 #### ext4
 
-Theodore Ts'o (是当时 ext3 主要开发人员) 在2006年宣布了 ext4 ,并于两年后在2.6.28内核版本中加入到了 Linux 主线。
+Theodore Ts'o (是当时 ext3 主要开发人员) 在 2006 年宣布了 ext4 ,并于两年后在 2.6.28 内核版本中加入到了 Linux 主线。
 Ts’o 将 ext4 描述为一个显著扩展 ext3 的临时技术，但它仍然依赖于旧技术。他预计 ext4 终将会被真正的下一代文件系统所取代。
 
 ![](https://opensource.com/sites/default/files/styles/panopoly_image_original/public/u128651/dell_precision_380_workstation.jpeg?itok=3EjYXY2i)
@@ -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`。相反，他们可能会写入一个新文件，关闭它，然后将其重命名为旧文件名：
@@ -145,14 +134,14 @@ Ext3 为每一个新分配的块调用一次块分配器。当多个编写器同
 
 #### 无限制的子目录
 
-Ext3 仅限于 32000 个子目录；ext4 允许w无限数量的子目录。从 2.6.23内核版本开始，ext4 使用 HTree 索引来减少大量子目录的性能损失。
+Ext3 仅限于 32000 个子目录；ext4 允许 w 无限数量的子目录。从 2.6.23内核版本开始，ext4 使用 HTree 索引来减少大量子目录的性能损失。
 
 #### 日志校验
 
 Ext3 没有对日志进行校验，这给内核直接控制之外的磁盘或控制器设备带来了自己的缓存问题。如果控制器或具有子集对缓存的磁盘确实无序写入，则可能会破坏 ext3 的日记事务顺序，
 从而可能破坏在崩溃期间（或之前一段时间）写入的文件。
  
-理论上，这个问题可以使用 write barriers—— 在安装文件系统时，你在挂载选项设置`barrier=1` ，然后将设备 `fsync` 一直向下调用直到 metal。通过实践，可以发现存储设备和控制器经常不遵守 write barriers —— 提高性能（和 benchmarks，跟竞争对手比较），但
+理论上，这个问题可以使用 write barriers—— 在安装文件系统时，你在挂载选项设置 `barrier=1` ，然后将设备 `fsync` 一直向下调用直到 metal。通过实践，可以发现存储设备和控制器经常不遵守 write barriers —— 提高性能（和 benchmarks，跟竞争对手比较），但
 增加了本应该防止数据损坏的可能性。
 
 对日志进行校验和允许文件系统奔溃后意识到其某些条目在第一次安装时无效或无序。因此，这避免了即使部分存储设备不存在 barriers ，也会回滚部分或无序日志条目和进一步损坏的文件系统的错误。rolling back partial or out-of-order journal entries and further damaging the filesystem—even if the storage devices lie and don't honor barriers.
@@ -166,12 +155,12 @@ Ext3 没有对日志进行校验，这给内核直接控制之外的磁盘或控
 
 Ext3提供粒度为一秒的时间戳。虽然足以满足大多数用途，但任务关键型应用程序经常需要更严格的时间控制。Ext4 通过提供纳秒级的时间戳，使其可用于那些企业，科学以及任务关键型的应用程序。
 
-Ext3文件系统也没有提供足够的位来存储 2038年1月18日以后的日期。Ext4 在这里增加了两位，将 [the Unix epoch][5] 扩展了 408年。如果你在公元 2446 年读到这篇文章，
+Ext3文件系统也没有提供足够的位来存储 2038 年 1 月 18 日以后的日期。Ext4 在这里增加了两位，将 [the Unix epoch][5] 扩展了 408 年。如果你在公元 2446 年读到这篇文章，
 你有希望已经转移到一个更好的文件系统 - 但是如果你还在测量 UTC 00:00，1970年1月1日以来的时间，它会让我非常非常高兴。
 
 #### 在线碎片整理
 
-ext2 和 ext3 都不直接支持在线碎片整理 —— 即在挂载时会对文件系统进行碎片整理。Ext2有一个包含的实用程序，**e2defrag**，它的名字暗示 —— 但它需要在文件系统未挂载时脱机运行。
+ext2 和 ext3 都不直接支持在线碎片整理 —— 即在挂载时会对文件系统进行碎片整理。Ext2 有一个包含的实用程序，**e2defrag**，它的名字暗示 —— 但它需要在文件系统未挂载时脱机运行。
 （显然，这对于根文件系统来说非常有问题。）在 ext3 中的情况甚至更糟糕 - 虽然 ext3 比 ext2 更不容易受到严重碎片的影响，但 ext3 文件系统运行 **e2defrag** 可能会导致灾难性损坏
 和数据丢失。
 
@@ -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 
 但无法知道使用它是否对你有利。虽然理论上可以在离散层中分离文件系统和存储卷管理系统而不会丢失自动损坏检测和修复功能，但这不是当前存储系统的设计方式，
 并且它将给新设计带来重大挑战。
-+++++++++++++++++++++++++++++++++=
 
 ### 备用文件系统
 在我们开始之前，提醒一句：要非常小心这是没有内置任何备用的文件系统，并直接支持为您分配的主线内核的一部分！
@@ -261,10 +244,10 @@ ZFS 由 Sun Microsystems 开发，以 zettabyte 命名 —— 相当于 1 万亿
 
 #### BTRFS
 
-Btrfs 是 B-Tree Filesystem 的简称，通常发音为“butter” —— 由 Chris Mason 于 2007 年在 Oracle 任职期间宣布。BTRFS 旨在跟 ZFS 有大部分相同的目标，
+Btrfs 是 B-Tree Filesystem 的简称，通常发音为 “butter” —— 由 Chris Mason 于 2007 年在 Oracle 任职期间宣布。BTRFS 旨在跟 ZFS 有大部分相同的目标，
 提供多种设备管理，每块校验、异步复制、直列压缩等，[还有更多][8]。
 
-截至2018年，btrfs 相当稳定，可用作标准的单磁盘文件系统，但可能不应该依赖于卷管理器。与许多常见用例中的 ext4，XFS 或 ZFS 相比，它存在严重的性能问题，
+截至 2018 年，btrfs 相当稳定，可用作标准的单磁盘文件系统，但可能不应该依赖于卷管理器。与许多常见用例中的 ext4，XFS 或 ZFS 相比，它存在严重的性能问题，
 其下一代功能 —— 复制，多磁盘拓扑和快照管理 —— 可能非常多，其结果可能是从灾难性地性能降低到实际数据的丢失。
 
 btrfs 的持续状态是有争议的; SUSE Enterprise Linux 在 2015 年采用它作为默认文件系统，而 Red Hat 宣布它将不再支持从 2017 年开始使用 RHEL 7.4 的 btrfs。