为什么在错误的“rm”保存我的文件后关闭我的机器？

Question

经典情况：我跑得不好rm，之后立即意识到我删除了错误的文件。（没什么重要的，我最近的备份还算可以，但还是很烦人。）

知道如果我想使用extundelete或此类工具恢复文件，进一步的磁盘活动是我的敌人，我立即关闭了机器的物理电源（即，使用电源按钮，而不是使用halt或任何此类命令）。这是一台没有运行重要任务或任何打开的笔记本电脑，所以这是一个可以接受的操作。（顺便说一下，从那时起我了解到在这种情况下要做的第一件事是首先估计丢失的文件是否仍然可以被进程打开https://unix.stackexchange.com/a/101247 --如果是，您应该通过这种方式恢复它们，而不是关闭机器。）

尽管如此，一旦机器断电，我想了一会儿，并认为这些文件不值得花时间启动实时系统进行适当的取证。所以我重新启动了机器。然后我发现我的文件仍然位于磁盘上：rm在我关闭电源之前还没有传播到磁盘。我跳了一小段舞，感谢系统管理员之神出人意料的宽恕。

我现在的问题是要了解这是如何可能的，以及rm实际传播到磁盘之前的典型延迟是多少。我知道磁盘 IO 不会立即刷新，而是在内存中停留了一段时间，但我认为磁盘日志会很快确保挂起的操作不会完全丢失。https://unix.stackexchange.com/a/78766似乎暗示了一种单独的机制来刷新脏页和刷新日志操作，但没有提供足够的细节来说明日志将如何参与 arm以及之前的预期延迟操作被刷新。

更多细节：数据位于 LUKS 卷内的 ext4 分区中，在启动机器备份时，我看到以下内容syslog：

Sep 24 10:24:58 gamma kernel: [   11.457007] EXT4-fs (dm-0): 1 orphan inode deleted
Sep 24 10:24:58 gamma kernel: [   11.458393] EXT4-fs (dm-0): recovery complete
Sep 24 10:24:58 gamma kernel: [   11.482475] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

但我不相信它与rm.

另一个问题是是否有办法告诉内核不要执行任何挂起的磁盘操作（而是将它们转储到某处），而不是关闭机器电源。（当然，不执行挂起的操作听起来很危险，但这就是在关闭机器电源时会发生的情况，并且在某些情况下它可以拯救您。）当然，这将是“更干净”，也很有趣例如，对于物理断电不是一个简单选择的远程服务器。

Answer 1

听起来你对发生的事情已经有了很好的了解。

是的，因为您在将更改提交到磁盘之前硬关闭了系统，所以当您重新启动时它们就在那里。

系统会在将所有写入刷新到磁盘之前缓存所有写入。有几个选项可以控制此行为，所有选项都位于/proc/sys/vm/dirty_* ^{[内核文档] 中}。除非应用程序通过fsync() ^{[ man 2 fsync ]}显式执行刷新，否则在数据足够旧或写入缓存已满时提交数据。
上面使用的“数据”的定义包括修改目录条目以删除文件。

现在，至于期刊，这是对期刊用途的常见误解之一。日志的目的不是确保更改被重播，或者数据不会丢失。日志的目的是防止损坏文件系统本身，而不是其中的文件。该日志仅包含有关所做更改的信息，而不是（通常）更改本身的完整数据。确切的细节取决于文件系统和日志模式。在ext3 / 4，请data在安装选项man 8 mount。

要回答您的补充问题，即是否有办法在不重启的情况下防止挂起的写入：

通过快速阅读内核源代码，您似乎可以使用神奇的 sysrqu命令^{（[维基百科]，[内核文档]）}来执行紧急重新挂载只读操作。看起来这将立即以只读方式重新安装所有卷，而无需同步操作。

要使用它，只需按Alt+ SysRq+ u。