間違った「rm」を入力してコンピュータをシャットダウンすると、ファイルが保存されるのはなぜですか？

典型的なシナリオ：実行が間違っていてrm間違ったファイルを削除したことがすぐにわかります。 （重要なことはなく、最近のバックアップがありますが、まだ迷惑です。）

そのようなツールを使用してファイルを回復したい場合は、追加のディスクアクティビティが私の敵であることを知り、すぐに物理的にシステムの電源を切った（つまり、そのようなコマンドを使用extundeleteする代わりに電源ボタンを使用する）。halt重要なタスクを実行しない、または何も開かないノートブックなので、許可されるタスクです。 （ところで、私はこの状況で最初にすべきことは、まずプロセスで欠落しているファイルを開くことができるかどうかを推定することです）。https://unix.stackexchange.com/a/101247- その場合は、マシンをシャットダウンするのではなく、この方法で復元する必要があります。 )

それでも、マシンの電源が切れたら、しばらく考えてみると、適切な法医学のためにライブシステムを起動するのに時間を費やす価値がないと判断しました。だからマシンを再起動しました。それから私のファイルがまだディスクにあることがわかりました。rm電源を切る前に、ファイルはディスクに伝播されませんでした。私は少し踊り、予期せぬ許しについてシステム管理者の神々に感謝しました。

今私の質問は、これがどのように達成され、rm実際にディスクに伝播される前に一般的な遅延が何であるかを理解することです。私はすぐにディスクIOがフラッシュされず、しばらくの間メモリに保持されることを知っていますが、保留中のタスクが完全に失われないようにディスクログをすばやく確認できると思いました。https://unix.stackexchange.com/a/78766ダーティページのフラッシュとログ操作のフラッシュのための別々のメカニズムを示唆しているように見えますが、ログがフラッシュ操作に参加する方法やフラッシュ操作の前に予想される遅延rmに関する詳細を十分に提供していません。

詳細：データは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。

もう1つの質問は、マシンの電源を切らずに保留中のディスク操作を実行せずに、代わりにどこかにダンプするようにカーネルに指示する方法があるかどうかです。 （もちろん、静止した作業を行わないことは危険ですが、これは機械をシャットダウンしたときに発生するものであり、場合によっては節約できます。）もちろん「よりきれい」であり、多くの喜びを与えます。たとえば、リモートサーバーの電源を物理的にオフにするのは簡単なオプションではありません。