fast_commit看来我在大多数 ext4 文件系统上启用得太快了，从那时起我经常遇到 FS 损坏。我从来没有遇到过 ext4 的此类问题，多年来它对我来说一直坚如磐石。
没什么太糟糕的，因为e2fsck总是能够在不丢失数据的情况下修复它们，但无法启动的系统很快就会过时。
我fast_commit现在已经禁用了，tune2fs -O "^fast_commit" /dev/partitions但我想知道设置时是否遗漏了一些东西？
这是一个已知问题吗？例如，我应该尝试更改日记顺序方法吗？我没有更改它，所以我猜它们仍然处于默认ordered模式，除非fast_commit更改或使其无关？
答案1
只是想说“我也是”。我将 fast_commit 放在我的系统上，然后由于需要手动 fsck 导致系统无法启动，最终将其删除。
我思考发生的情况是 fsck 发现一些不一致，如果 fast_commit 没有机会将其内容提交到文件系统（断电、崩溃、我爸爸决定通过按住来关闭桌面），这是完全正常的电源按钮等）所以 fsck 可以可靠地修复这个问题，这不是问题，但是 fsck 尚未更新以识别这种情况并意识到这是正常情况，因此它进入“手动运行 fsck 并手动确定” “ 情况。
当 fast_commit 出现时，我查看了它的设计，它非常保守——它首先将这些提交写入一个新日志，然后在方便时将它们写入文件系统。因此，最坏的情况应该是丢失文件系统更改的最后几秒，而不是文件系统完全崩溃并丢失数据。