得到教训

Question 1

为了补充对我的问题的有用贡献，我自己做了一些研究。因为部分结果可能也具有一定的普遍意义，所以我在这个自我回答中总结了它们。

请注意：根据问题定义，以下所有内容均指e2fsck版本 1.41.1，并重点关注没有日志的 Ext2 文件系统。但这些通用术语在某种程度上也适用于程序和文件系统的当代版本。

得到教训

让我们从头条新闻开始——理由如下：

在 C 语言环境中运行e2fsck，例如如下所示：
```
LC_ALL=C e2fsck ...
```
通过这种方式，您可以获得英文消息，从而更容易在网上找到特定的帮助。
请谨慎使用该-y选项：它会自动对e2fsck出现的所有提示回答“是”。这些问题并不总是涉及“修复此错误？”之类的问题，也有一些问题的要点是“删除受影响的文件？”。
对文件系统进行e2fsck了一些更改并以状态 1（或 3）退出并不意味着存在文件系统错误（损坏）。
e2fsck句柄SIGINT(Ctrl-C)。但我会避免诉诸它。（个人想法。）

重点关注以下几点信息你从e2fsck：

如果您想知道您的文件系统可能包含哪些错误以及如何e2fsck处理它，请不要使用-p选项 (preen)。
交互式运行e2fsck（即不带选项-n、-p、-a、-y）会比只读 ( -n) 或整理 ( -p) 运行输出更多有关其发现的错误的消息。-a只是的别名-p。从“yes”运行 ( -y) 中，您可以获得与交互式运行基本相同的信息。
尽管非常接近，但该选项-n并不能产生交互式的精确试运行。
如果您不使用该-f选项，则很可能会e2fsck强制自行进行检查。这样做可以提供额外的信息来推理其决定。例子：
```
... primary superblock features different from backup, check forced.
```
如果您不想错过这一点，请在不使用该-f选项的情况下开始，仅在第二次尝试时使用它，如果e2fsck因为文件系统似乎是干净的而拒绝检查。
不要忘记查看退出代码以e2fsck了解全貌：echo $?。

支票类型

交互的：如果不使用选项-n、-p和，则-a执行交互式文件系统检查。这意味着它会在每一步中询问您要做什么。这使您可以最大程度地控制该过程。-ye2fsck

警告：根据文件系统的大小和运行状况，这可能会很快变得乏味：想象一下，您必须逐个 inode 确认修复 inode。这样的会议可能会持续几个小时甚至更糟。

此外，如果问题朝着你不熟悉的方向发展，事情可能会变得非常可怕。

打断：如果交互式检查以这种方式失控，那么知道e2fsck句柄SIGINT(Ctrl-C) 可能会更好。

事实上，有一些令人鼓舞的报告，例如通过疯帽匠和通过克里斯。但正如已经提到的，我会尽力避免此类中断。

原因很简单：检查文件系统是一个复杂的过程，修复损坏必须以连贯一致的方式完成，而处理中断则更加复杂。与任何复杂的软件一样，信号处理程序可能存在缺陷。参见示例这个帖子安德烈亚斯·迪尔格着。那么为什么要冒险呢？当然可能有充分的理由，但你自己衡量。

只读：如果您对要检查的文件系统的健康状态知之甚少，那么最好首先使用e2fsck该-n选项。正如我们将在下面看到的，这不会产生精确的试运行，但它给了您对交互式运行的期望的良好印象。

整理： e2fsck-p如果使用该选项，则整理文件系统。这手册页 e2fsck(8)听起来很有希望：

此选项将导致 e2fsck 自动修复任何无需人工干预即可安全修复的文件系统问题。

但这也意味着它只会纠正一些文件系统错误。从的来源可以看出e2fsck，-p一旦检测到无法安全处理的错误，运行就会停止，将剩下的工作留给后续运行，而不仅仅是整理。

此外，如上所述，-p将提供较少的有关错误及其更正的信息。

是的：e2fsck从选项开始-y产生与交互式运行相同的结果，交互式运行的问题全部回答为“是”。上面已经提到了这种方法的缺陷。

预计：据我了解本节的 ”Ext2fs 目录结构取消删除迷你 HOWTO”，可以使用该程序自动更细粒度地回答 e2fsck 的问题预计。在那里，e2fsck使用以下包装脚本：

#!/usr/bin/expect -f
set timeout -1
spawn /sbin/e2fsck -f $argv
expect {
    "Clear<y>? " { send "n" ; exp_continue }
    "<y>? "      { send "y" ; exp_continue }
}

这将自动回答所有使用“Clear？”提示的问题（使用“n”），以及所有其他使用“y”的问题。有关详细信息，请参阅 Expect 的文档。看这个问题作者：Wrothgarr，这是使用 Expect for 的另一个示例e2fsck。

澄清一下：我不建议盲目使用这些脚本。此处引用它们只是出于“教育目的”。

对于那些想要采用这个想法并根据自己的需要进行定制的人：在e2fsck源文件 e2fsck/problem.c 的开头附近，prompt定义了该数组来保存总共 20 个e2fsck使用的提示。其中一些仅在内部使用。下面详细介绍了提示和文件系统错误之间的相互关系。

从消息来源得知

对话：对于在文件系统中找到的大多数错误，请查阅文件 e2fsck/problem.c 中定义的e2fsck函数。fix_problem此函数根据给定的选项，针对各个错误与用户进行适当的对话e2fsck。

为此，在先前在同一文件 e2fsck/problem.c 中定义的fix_problem数组中查找当前错误代码。problem_table该数组为每个错误代码赋予错误消息模板、询问用户问题的提示以及控制错误处理细节的位掩码。（对于某些错误，还引用了进一步的错误代码，称为“后代码”，其对话框随后执行。但这对我们来说并不重要。）

此位掩码中偶尔会使用两个对我们的问题很重要的标志：PR_PREEN_NOMSG和PR_NO_NOMSG。设置后，它们将分别抑制-p运行和运行的错误消息-n。因此，这些定义了错误，您可以在交互式运行或-y运行中获得更多信息。

的定义problem_table指定了 292 个错误代码，其中标记了 23 个PR_PREEN_NOMSG，仅标记了 1 个PR_NO_NOMSG。它们中没有一个同时带有PR_PREEN_NOMSG和的标志PR_NO_NOMSG。

另一个有趣的标志是PR_PREEN_OK：带有该标志的错误可以通过 preen(runs) 安全地处理-p。 preen 还可以处理其他错误，请参阅下面的“特殊情况”，但这些是其中的大多数。阵列中的 82 个错误problem_table被标记PR_PREEN_OK。

开始：对于版本 1.41.1 的 Linux 版本，从文件 e2fsck/unix.c 中的e2fsck函数开始执行。main

通过0：在初始化和检查日志（与此问题无关）之后，将对文件系统执行一些基本检查和清理。这也被称为 pass 0。其中的主要部分是由check_super_block源文件 e2fsck/super.c 中的函数完成的。

尽管名称如此，但该函数不仅负责超级块，还检查块组描述符。这样做时，它会总结每个块组的空闲块和空闲 inode 计数，并将结果与超级块中的全局值进行比较。

如果这些值不一致，会发生什么情况取决于e2fsck命令行选项：对于-n运行，文件系统被视为无效，并且稍后会强制进行完整检查。在所有其他情况下（-p、-y、交互式运行），超级块中的总计数会默默更新，而不强制进行完整检查。事实上，如果后者运行时没有发现其他错误，它们会报告文件系统干净，尽管有这种静默更正。

该函数check_super_block还执行其他操作，例如检查调整大小 inode、清理孤立 inode、围绕日志进行一些内务处理，但这对于我们的问题似乎并不重要。

跳过：如果该选项尚未强制执行完整的文件系统检查-f，e2fsck我决定自行强制执行完整的检查。众所周知的标准是自上次检查以来的安装次数、没有干净卸载、已知文件错误等。

但它还应用了另一个标准，但前提是-n未使用该选项：超级块及其备份之间在以下数量方面的差异：

启用的文件系统功能，除了large_file、dir_nlink、extent、
总块数，
总索引节点数，
文件系统 UUID。

从该标准中排除某些文件系统功能的原因是，内核可以根据需要动态设置此类功能，并且仅在超级块中执行此操作，而不会在备份中执行此操作。对于例外的功能，此类差异不被认为重要到足以强制进行全面检查。相反，该ext_attr功能也可以由内核动态设置，但在这种情况下，备份的更新至关重要，这就是为什么该功能也不例外。

如果e2fsck决定强制由自己进行全面检查，它会打印一条消息来解释造成的不便。如果这是由于超级块及其备份之间的指定差异之一造成的，则该消息将显示：

... primary superblock features different from backup, check forced.

请注意，消息中的术语“功能”比纯粹的“文件系统功能”具有更广泛的含义：例如，它还涵盖总块数。也可以看看这个帖子作者：埃里克·桑丁和这个Theodore Tso 在这方面。

无论如何，您永远不会在运行中看到此消息-n，因为如上所述，在这种情况下不考虑超级块备份。

如果未强制执行完整检查，无论是 by-f还是 by e2fsck，都会跳过检查（e2fsck字典）。在这种情况下，e2fsck将文件系统报告为干净结束退出，状态为 0。如果在第 0 遍中进行了一些修复（例如对超级块中的总空闲块计数进行更正），情况也是如此。

通过 1 至 6：在全面检查中，e2fsck至少对文件系统进行五次完整检查，每一次都有不同的重点。这些分别由源文件 e2fsck/pass1.c 至 e2fsck/pass5.c 中定义的e2fsck_pass1函数执行。e2fsck_pass5

如果需要处理特殊的文件系统损坏，可能会有其他通道来补充通道 1。这些被标记为pass 1B 到pass 1D，相应的函数pass1b都pass1d定义在e2fsck/pass1b.c 中。

目录的重新哈希是第 3 遍的一部分，由文件 e2fsck/rehash.c 中的函数执行，e2fsck_rehash_directories被视为第 3A 遍。

此外，PR_6_RECREATE_JOURNAL当必须重新创建日志时，还会使用一个错误代码。显然，这被认为构成了一个单独的传递：传递 6。它在函数中执行main。

problem_table在这些遍中检查数组中定义的大多数错误。对于每个错误，可以从其错误代码的名称中看到它所经历的传递次数：该数字位于代码名称中的第一个下划线之后。因此，例如错误PR_1_TOO_MANY_BAD_BLOCKS在第 1 遍中处理，并PR_3A_OPTIMIZE_DIR_ERR在第 3A 遍中处理。

对于这个问题特别感兴趣的是，在第 5 遍开始时再次检查空闲块和空闲 inode 的总数：与第 0 遍的快速检查不同，其中仅检查来自块组描述符的相应值总而言之，这次计数是根据e2fsck在整个文件系统过程中彻底收集的数据来计算的，其中每个块和每个索引节点的角色都被单独分析。这是由文件 e2fsck/pass5.c 中定义的函数check_block_bitmaps和完成的。check_inode_bitmaps

结果值与超级块中的值相比的差异被视为错误PR_5_FREE_BLOCK_COUNT和PR_5_FREE_INODE_COUNT。顺便说一句，这些错误已被标记PR_PREEN_NOMSG，因此在整理 () 时不会明确报告它们-p。

特别案例：有一些更正e2fsck可以在文件系统上执行，而无需调用fix_problem或查阅中的错误目录problem_table。这些更正仅在没有选项的情况下执行-n，并且不会在输出中发出通知，但可能在退出状态下执行。我在来源中找到了其中三个：

-n在传递 0 期间（不带），对超级块中的总空闲块和空闲 inode 计数进行更正。这已经在上面讨论过。
在第 1 遍期间，如果设置了超级块中的最后一个孤立字段（不带-n），则该字段将被静默清除。
如果存储在索引目录的 inode 中的链接计数值表明它之前超出了其上限，而当前的真实计数低于此限制，则 inode 中的值将在第 4 步中静默更正（无需-n）。

退出状态：对于完全（强制）检查，退出代码是main在检查完成后在分析后者结果的过程中通过函数确定的：如果检查没有中途取消，则退出状态将为零当且仅当到目前为止，文件系统没有发生任何变化。

最后的接触：如果检查没有中途取消，该函数main会重置超级块中的安装计数并更新那里的时间戳，以便e2fsck在将来的运行中知道何时必须强制执行下一次完整检查。这是在确定退出状态后的清理过程中完成的，因此此更改对状态没有影响。

信号处理程序：PRS在调用的函数中main，两者都在 e2fsck/unix.c 中定义，为、、和e2fsck生成信号处理程序。后两者可用于切换进度信息，如中所述SIGINTSIGTERMSIGUSR1SIGUSR2手册页 e2fsck(8)。

显然，前者的处理是为了允许安全中断和终止e2fsck。

从测试中得知

为了重现e2fsck问题中显示的行为，我设置了一个测试 Ext2 文件系统，用最多其容量 10% 的虚拟文件填充它，并使用十六进制编辑器引入了一些人为错误。然后使用与问题中相同的命令检查该文件系统，以比较的输出和退出状态e2fsck。

在问题的最后一次运行中，已使用块的计数发生了变化。e2fsck根据空闲块计数和总块计数以明显的方式计算该值。这就是为什么我选择这些数量作为人为误差的主题。

超级块中的空闲块计数：超级块的数据结构在这个文件。（该文档的现代版本描述了 Ext4 文件系统，可以在这里.）基于此，我使用十六进制编辑器将超级块中的空闲块数减少了 2。

这个人为错误被e2fsck -nv(without -f) 检测到，它大声抱怨，强制进行全面检查并以退出状态 4 退出。

另外，强制只读运行 ( -nfv) 报告该错误并以状态 4 退出。

随后的-pv运行（没有-f）发现文件系统干净并且没有给出任何有关错误的通知。但是，它纠正了错误并根据纠正后的值输出已使用的块数，但以状态 0 退出。

再次引入相同的错误后，强制整理运行 ( -pfv) 也没有报告该错误，而是更正了该错误并以状态 1 退出。

e2fsck从上述来源了解到的情况可以很好地理解这种行为。

这意味着，它一定是导致问题中描述的检查结果的不同错误：否则，它将由只读运行报告并由第一个（非强制）整理纠正，以便最后一次运行会找到一个干净的文件系统。

超级块中的总块数：使用十六进制编辑器，我将超级块中的总块数减少了 2。

-nv运行（不带）未检测到这一点-f，该运行将文件系统报告为干净并以状态 0 退出。

强制进行此检查（-nfv），发现了几个错误——某种意义上是错误的：e2fsck认真对待操纵的总块计数，结果发现最后一个块组和超级块中的空闲块计数错误。另外，发现块位图末尾的padding没有设置。退出状态为 4。

由于超级块与其备份之间的差异，随后的整理（-pv、不带）强制进行全面检查。-f在过程中，它纠正了之前通过强制只读运行发现的所有“错误”错误。但是，它仅报告位图填充中的（“错误”）错误，而没有给出有关空闲块计数的任何通知。最后以状态 1 退出。

再次引入相同的错误后，强制整理 ( -pfv) 的作用基本相同，只是没有告知超级块与其备份之间的差异（之前作为强制检查的原因给出）。

这种行为也e2fsck可以从上述来源的讨论中理解。然而，这与问题中描述的不同。所以那里一定是另一个错误。

备份中的空闲块计数：超级块备份的块号可以通过以下方式找到

LC_ALL=C dumpe2fs <device> | grep -i superblock

但是，第一个超级块备份中的空闲块计数完全被忽略e2fsck。事实上，即使在真正干净的文件系统中，该值似乎也与主超级块中的值不同。事实上，如果有人想一想，在所有备份中保持这个值不断同步将是一项巨大的开销。所以我认为，它根本没有任何意义。

备份中的总块数：再次使用十六进制编辑器，我将第一个超级块备份中的总块数减少了 2。

e2fsck在只读模式下，这个人为错误被完全忽略：-nv和-nfv。

清理运行（-pv, without -f）强制进行完整检查，给出消息

... primary superblock features different from backup, check forced.

在此过程中，它纠正了错误，没有进一步的相关消息，并以状态 1 退出。

再次引入相同的错误后，强制整理（-pfv）做了同样的事情，但没有任何错误提示。

同样，从上述来源的讨论中可以很好地理解这种行为；这与问题中观察到的情况不同。

此外，e2fsck问题中描述的非强制运行和更新 1 中描述的后续执行的检查报告了相同的总块计数。因此，该值在任何一次运行中都没有更改，因此不可能成为所需错误的主题。

这能得出问题的答案吗？

简而言之：不。

对于问题中描述的每个单独运行，我发现可能导致观察到的行为的错误e2fsck。但我没有发现任何错误会导致序列中所有运行的行为。

中的所有错误problem_table都被排除，因为它们可能是由运行-nfv或由-pfv运行或由两者报告的。

考虑到上面的“特殊情况”，只读运行会报告错误的空闲块或空闲 inode 计数。此情况并非如此。

其他“特殊情况”不会导致上次运行中观察到的已用块计数发生变化。

但毕竟e2fsck是一个复杂的软件，所以很可能是我疏忽了一些东西。

结果

面对这些发现，似乎以下工作流程可用于安全地检查健康状态未知的未挂载的 Ext2 文件系统，同时避免交互部分中出现令人不快的意外情况并从e2fsck.

这假设硬件健康！特别是如果驱动器在这方面不值得信赖，则无条件地从步骤 3（备份文件系统）开始，然后按所述顺序继续执行其余步骤：

做一次-nv跑步：
```
LC_ALL=C e2fsck -nv <device>; echo $?
```
如果e2fsck跳过将文件系统报告为干净的完整检查，请使用强制重复步骤 1 的检查-f。
根据发现的损坏，使用备份文件系统dd。如果接下来的步骤出现问题，这允许恢复当前状态。
如果根据只读运行的结果看来可行，请使用以下命令进行交互式检查
```
LC_ALL=C e2fsck -v <device>; echo $?
```
如果需要的话强制它-f以获得完整的检查。
如果交互式运行不可行该怎么办取决于迄今为止的发现。

附录：检查文件系统功能

转储2fs：该程序dumpe2fs可用于找出文件系统中启用了哪些功能。

这也适用于未知功能。在这种情况下，dumpe2fs使用唯一标识超级块的特征字段中的相应位的通用特征名称。例如FEATURE_R16对应于超级块的只读兼容特征字段中的位16（从0开始计数）。类似地，FEATURE_I31对应于不兼容特征字段的最高有效位。

如果compression设置了该功能，则dumpe2fs必须使用该-f选项启动。

然而，该程序的 1.41.1 版本似乎有点错误，因为它在启用和禁用功能的某些组合（例如启用64bit和禁用）上因浮点异常而崩溃journal_dev。

调试：对于启用的文件系统功能，命令show_super_stats产生debugfs与类似的输出。dumpe2fs该程序还告知未知功能。

该程序的 1.41.1 版本似乎也存在某种错误：如果启用或，该命令show_super_stats会因分段错误而崩溃。与此类似，如果该功能在禁用时启用，则整个程序会因浮点异常而崩溃。compressionjournal_devdumpe2fsdebugfs64bitjournal_dev

调2fs：如果仅启用已知的文件系统功能，则它们可以列为tune2fs -l.但是，如果启用了任何未知的文件系统功能，即使-f使用了该选项，该程序也将拒绝启动。

Answer

为了补充对我的问题的有用贡献，我自己做了一些研究。因为部分结果可能也具有一定的普遍意义，所以我在这个自我回答中总结了它们。

请注意：根据问题定义，以下所有内容均指e2fsck版本 1.41.1，并重点关注没有日志的 Ext2 文件系统。但这些通用术语在某种程度上也适用于程序和文件系统的当代版本。

得到教训

让我们从头条新闻开始——理由如下：

在 C 语言环境中运行e2fsck，例如如下所示：
```
LC_ALL=C e2fsck ...
```
通过这种方式，您可以获得英文消息，从而更容易在网上找到特定的帮助。
请谨慎使用该-y选项：它会自动对e2fsck出现的所有提示回答“是”。这些问题并不总是涉及“修复此错误？”之类的问题，也有一些问题的要点是“删除受影响的文件？”。
对文件系统进行e2fsck了一些更改并以状态 1（或 3）退出并不意味着存在文件系统错误（损坏）。
e2fsck句柄SIGINT(Ctrl-C)。但我会避免诉诸它。（个人想法。）

重点关注以下几点信息你从e2fsck：

如果您想知道您的文件系统可能包含哪些错误以及如何e2fsck处理它，请不要使用-p选项 (preen)。
交互式运行e2fsck（即不带选项-n、-p、-a、-y）会比只读 ( -n) 或整理 ( -p) 运行输出更多有关其发现的错误的消息。-a只是的别名-p。从“yes”运行 ( -y) 中，您可以获得与交互式运行基本相同的信息。
尽管非常接近，但该选项-n并不能产生交互式的精确试运行。
如果您不使用该-f选项，则很可能会e2fsck强制自行进行检查。这样做可以提供额外的信息来推理其决定。例子：
```
... primary superblock features different from backup, check forced.
```
如果您不想错过这一点，请在不使用该-f选项的情况下开始，仅在第二次尝试时使用它，如果e2fsck因为文件系统似乎是干净的而拒绝检查。
不要忘记查看退出代码以e2fsck了解全貌：echo $?。

支票类型

交互的：如果不使用选项-n、-p和，则-a执行交互式文件系统检查。这意味着它会在每一步中询问您要做什么。这使您可以最大程度地控制该过程。-ye2fsck

警告：根据文件系统的大小和运行状况，这可能会很快变得乏味：想象一下，您必须逐个 inode 确认修复 inode。这样的会议可能会持续几个小时甚至更糟。

此外，如果问题朝着你不熟悉的方向发展，事情可能会变得非常可怕。

打断：如果交互式检查以这种方式失控，那么知道e2fsck句柄SIGINT(Ctrl-C) 可能会更好。

事实上，有一些令人鼓舞的报告，例如通过疯帽匠和通过克里斯。但正如已经提到的，我会尽力避免此类中断。

原因很简单：检查文件系统是一个复杂的过程，修复损坏必须以连贯一致的方式完成，而处理中断则更加复杂。与任何复杂的软件一样，信号处理程序可能存在缺陷。参见示例这个帖子安德烈亚斯·迪尔格着。那么为什么要冒险呢？当然可能有充分的理由，但你自己衡量。

只读：如果您对要检查的文件系统的健康状态知之甚少，那么最好首先使用e2fsck该-n选项。正如我们将在下面看到的，这不会产生精确的试运行，但它给了您对交互式运行的期望的良好印象。

整理： e2fsck-p如果使用该选项，则整理文件系统。这手册页 e2fsck(8)听起来很有希望：

此选项将导致 e2fsck 自动修复任何无需人工干预即可安全修复的文件系统问题。

但这也意味着它只会纠正一些文件系统错误。从的来源可以看出e2fsck，-p一旦检测到无法安全处理的错误，运行就会停止，将剩下的工作留给后续运行，而不仅仅是整理。

此外，如上所述，-p将提供较少的有关错误及其更正的信息。

是的：e2fsck从选项开始-y产生与交互式运行相同的结果，交互式运行的问题全部回答为“是”。上面已经提到了这种方法的缺陷。

预计：据我了解本节的 ”Ext2fs 目录结构取消删除迷你 HOWTO”，可以使用该程序自动更细粒度地回答 e2fsck 的问题预计。在那里，e2fsck使用以下包装脚本：

#!/usr/bin/expect -f
set timeout -1
spawn /sbin/e2fsck -f $argv
expect {
    "Clear<y>? " { send "n" ; exp_continue }
    "<y>? "      { send "y" ; exp_continue }
}