bsod - コードを書いているときにPCが故障したとしましょう。後のソースコードを汚染したくない場合、完全なスキャンを実行する必要はありますか？

Question

たとえば、Ruby on Railsプログラムを作成していて、ファイルの編集中にマシンがブルースクリーンになっているとします。この場合、将来のファイルを損傷させたくない場合は、ハードドライブ全体を再スキャンする必要がありますか？

コンピューターがクラッシュしたときにOSがtmpファイルを削除していて、ハードドライブ上のセクターへのポインターがまだ残っている場合を考えてみましょう。新しく作成したファイルがたまたまそれらのセクターにあり、次にOSがファイルを再度クリーンアップした場合、「残った」セクターが前回クリーンアップされなかったと考えて、ソースコードに損傷を与える可能性があります。 。（特にRuby on Railsの場合、ソースコードは私たちではなくRailsによって生成される可能性があり、ファイルが影響を受ける場合、Railsサーバーが機能しない理由がわからない場合があります）。SVNに頼ることはできますが、チェックインする前にファイルが影響を受けた場合はどうなりますか？

公式の答えは「クラッシュや停電後は常にディスクをスキャンして、データやスペースを探し、不良セクタを修正する試みを示してください」と思いますが、最近のハードドライブは非常に大きいので、すべてをスキャンするのに2時間かかる場合があります。そして、特に職場では、真昼の場合は2時間待つことはできません。

XP、Vista、Mac OS、Linuxなどの最新のOS（電源コードが緩んでいて、正しくシャットダウンせず、0％のバッテリーでシャットダウンした場合）がこれらの最新のOSであるかどうかを誰かが知っていますか？私たちのソースコードは安全ですか？彼らは、セクターに書き込むように構造化して、重複するセクターではなく、せいぜいセクターを浪費するようにする方法を知っていますか？

Answer 1

私はいくつかの情報を見ます

http://en.wikipedia.org/wiki/Journaling_file_system

ジャーナル化されたファイルシステム

ファイルシステムはジャーナリングを提供する場合があり、システムがクラッシュした場合に安全に回復できます。ジャーナルファイルシステムは、いくつかの情報を2回書き込みます。最初はファイルシステム操作のログであるジャーナルに、次に通常のファイルシステムの適切な場所に書き込みます。ジャーナリングはファイルシステムドライバによって処理され、ディスクの内容を変更する各操作が実行されていることを追跡します。クラッシュが発生した場合、システムはジャーナルの一部を再生することで一貫した状態に回復できます。多くのUNIXファイルシステムは、ReiserFS、JFS、Ext3などのジャーナリングを提供します。

対照的に、ジャーナリングされていないファイルシステムは、通常、fsckやchkdskなどのユーティリティによって、クリーンでないシャットダウン後に不整合がないか全体を調べる必要があります。ソフト更新は、更新操作を注意深く順序付けることによって冗長な書き込みを回避するジャーナリングの代替手段です。ログ構造化ファイルシステムとZFSは、データの新しいコピーを常に書き込み、インプレース更新を回避することで不整合を回避するという点でも、従来のジャーナルファイルシステムとは異なります。