悪い `rm`でファイルを保存した後、マシンの電源を切るのはなぜですか？

古典的な状況：私は悪い実行し、rmすぐに間違ったファイルを削除したことを実現しました。（重要なことは何もありませんでしたが、最近のバックアップは許容範囲内でしたが、まだ迷惑です。）

extundeleteまたはそのようなツールを使用してファイルを回復したい場合、さらなるディスクアクティビティが敵であることがわかったので、すぐに物理的にマシンの電源を切りました（つまり、haltコマンドではなく、電源ボタンで）。これは重要なタスクが実行されていない、または何も開いていないラップトップであるため、許容できる操作でした。（ところで、そのような状況で最初にすることは、プロセスhttps://unix.stackexchange.com/a/101247によって見つからないファイルがまだ開かれている可能性がある場合、最初に推定することであることをその後学びました-存在する場合、マシンの電源を切るのではなく、この方法で回復する必要があります。）

それでも、マシンの電源を切った後、しばらく考えて、ファイルが適切なフォレンジックのためにライブシステムを起動する時間投資に見合わないと判断しました。そこで、マシンの電源を入れました。そして、ファイルがまだディスクに残っていることを発見しましrmた。電源を切る前にファイルがディスクに伝播されていませんでした。私は少しダンスをし、システム管理者の神に彼の予期せぬ許しに感謝しました。

私の質問は、これがどのように可能だったか、そしてrm実際にディスクに伝播されるまでの典型的な遅延とは何かを理解することです。ディスクIOはすぐにはフラッシュされず、しばらくの間メモリ内に置かれることはわかっていますが、ディスクジャーナルにより、保留中の操作が完全に失われないようにすばやく確認できると考えました。https://unix.stackexchange.com/a/78766は、ダーティページをフラッシュし、ジャーナル操作をフラッシュする別のメカニズムを示唆しているように見えますが、ジャーナルがa 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。

別の質問は、マシンの電源を落とすのではなく、保留中のディスク操作を実行しないようにカーネルに指示する方法があるかどうかです（ただし、どこかにダンプするなど）。（もちろん、保留中の操作を実行しないのは危険に思えますが、これはとにかくマシンの電源を切ったときに起こることであり、場合によってはそれがあなたを救う可能性があります。）たとえば、物理的な電源切断が簡単なオプションではないリモートサーバーの場合。

何が起こったのかよく把握しているようです。

はい、変更がディスクにコミットされる前にシステムの電源をオフにしたため、バックアップをブートしたときに変更がそこにありました。

システムはすべての書き込みをキャッシュしてから、ディスクにフラッシュします。この動作を制御するいくつかのオプションがあり、すべて/proc/sys/vm/dirty_* ^{[ kernel doc ]にあり}ます。フラッシュがfsync() ^{[ man 2 fsync ]}を介してアプリケーションによって明示的に実行されない限り、データは十分に古いか、書き込みキャッシュがいっぱいになったときにコミットされます。
上記で使用される「データ」の定義には、ファイルを削除するためのディレクトリエントリの変更が含まれます。

さて、ジャーナルに関しては、それがジャーナルの目的に関するよくある誤解の一つです。ジャーナルの目的は、変更が確実に再生されるようにすることや、データが失われないようにすることではありません。ジャーナルの目的は、その中のファイルではなく、ファイルシステム自体の破損を防ぐことです。ジャーナルには、行われた変更に関する情報が含まれているだけで、（通常）変更自体の完全なデータは含まれていません。正確な詳細は、ファイルシステムとジャーナルモードに依存します。ext3 / 4については、のdataマウントオプションを参照してくださいman 8 mount。

再起動せずに保留中の書き込みを防ぐ方法があるかどうかの補足質問に答えるには：

カーネルソースコードをすばやく読むことから、魔法のsysrq uコマンド^{（[ wikipedia ]、[ kernel doc ]）}を使用して、緊急時の再マウント専用操作を実行できるようです。これにより、同期操作なしですべてのボリュームが読み取り専用ですぐに再マウントされるようです。

これを使用するには、単にAlt+ SysRq+を押しuます。

From：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