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