不正な「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つの質問は、マシンの電源を切るのではなく、保留中のディスク操作を実行しないように（ただし、どこかでそれらをダンプするように）カーネルに指示する方法があるかどうかです。 （もちろん、保留中の操作を実行しないことは危険に聞こえますが、これはとにかくマシンの電源を切るときに何が起こるかであり、場合によってはそれがあなたを救うことができます。）これはもちろん "よりクリーン"で、また興味深いでしょう例えば物理的な電源切断が簡単なオプションではないリモートサーバー。
何が起こったのか、きちんと把握しているようですね。
はい、変更がディスクにコミットされる前にシステムの電源を完全にオフにしたので、バックアップを起動したときにシステムはそこにありました。
システムは、すべての書き込みをキャッシュしてからディスクにフラッシュします。この動作を制御するいくつかのオプションがあり、すべて_/proc/sys/vm/dirty_*_にあります [ カーネルドキュメント ]。フラッシュがfsync()を介してアプリケーションによって明示的に実行されない限り [ man 2 fsync ]、データが古くなるか、書き込みキャッシュがいっぱいになると、データがコミットされます。
上記の「データ」の定義には、ファイルを削除するためのディレクトリエントリの変更が含まれます。
さて、ジャーナルに関しては、それがジャーナルの目的に関する一般的な誤解の1つです。ジャーナルの目的は、変更が確実に再生されること、またはデータが失われないことを保証することではありません。ジャーナルの目的は、ファイルシステムではなく、ファイルシステム自体の破損を防ぐことです。ジャーナルには、行われた変更に関する情報が含まれているだけで、（通常）変更自体の完全なデータは含まれていません。正確な詳細は、ファイルシステムとジャーナルモードによって異なります。 ext3/4については、_man 8 mount_のdataマウントオプションを参照してください。
再起動せずに保留中の書き込みを防ぐ方法があるかどうかに関する補足的な質問に答えるには、次のようにします。
カーネルソースコードをざっと読んでみると、魔法のsysrq uコマンドを使用できるようです （[ wikipedia ]、[ kernel doc ]） 緊急時の再マウント読み取り専用操作を実行します。これにより、同期操作なしですべてのボリュームが読み取り専用で再マウントされます。
これを使用するには、単に押します Alt+SysRq+u。
差出人： https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
commit = nrsec（*）Ext4は、すべてのデータとメタデータを「nrsec」秒ごとに同期するように指示できます。デフォルト値は5秒です。つまり、力を失うと、直近の5秒間の作業が失われます（ただし、ジャーナリングのおかげで、ファイルシステムは損傷しません）。このデフォルト値（または低い値）はパフォーマンスを低下させますが、データの安全性には優れています。 0に設定すると、デフォルト（5秒）のままにするのと同じ効果があります。非常に大きな値に設定すると、パフォーマンスが向上します。
それらをフラッシュする方法については、こちらもご覧ください： Linuxシステムでバッファーとキャッシュを空にする方法は？
上記のリンクから引用：
注：不要なもののメモリをクリーンアップします（Kernerl 2.6.16以降）。常に最初に同期を実行して、有用なものをディスクにフラッシュするようにしてください!!!
To free pagecache:
$ echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
$ echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
$ echo 3 > /proc/sys/vm/drop_caches