ECCのないプラットフォーム用のソフトウェアメモリビットフリップ検出
利用可能なほとんどのデスクトップ（安価な）x86プラットフォームは、ECCメモリをサポートしていません（ エラーチェックと修正 ）。しかし、メモリビットフリップエラーの割合は依然として増加しています（ 最良ではないSOスレッド 、 大規模CERN 2007調査「データ整合性」 =： "ビットエラーレート10-12 それらのメモリモジュールの場合...観測されたエラー率は予想よりも4桁低い "; 2009 Googleの "野生のDRAMエラー：大規模なフィールド調査 " ）。データ集約型の負荷（8 GB/sの読み取り）を備えた現在のハードウェアの場合、これは1分ごとにシングルビットフリップが発生する可能性があることを意味します（10-12 CERN07のベンダーBER）または2日に1回（10-16 CERN07からのBER）。 Google09によると、1メガビットあたり最大25000〜75000の1ビットFIT（10億時間あたりの時間の障害）が発生する可能性があります。これは、8GBのRAM）の場合、1時間あたり1〜5ビットのエラーに相当します。 （ "は、1 GBあたり年間2000〜6000の修正可能なエラー率を意味します"）。
だから、私は知りたいのですが、システム全体の方法で何らかのソフトウェアエラー検出を追加することは可能ですか（ユーザーとカーネルメモリの両方をチェックしてください）。たとえば、Linuxカーネルやシステムコンパイラのパッチを作成して、すべてのメモリページのチェックサムを追加し、チェックサムを定期的に再計算してサイレントメモリ破損（ビットフリップ）を検出しようとしますか？
たとえば、メモリへのすべての書き込み（ユーザー空間とカーネル空間の両方から）を確認して、意図したメモリの変更とメモリ内のビットフリップを区別できますか？または、何らかのヘルパーを使用してすべてのコードをインストルメント化できますか？
どんな種類のソフトウェアメモリECCもパフォーマンスが高く、すべてのエラーをキャッチできるわけではないことは理解していますが、後で計算に再利用したり保存したりする前に、少なくとも一部のメモリビットフリップを早期に検出すると便利だと思います。ハードドライブに。
また、メモリビットフリップからのデータ保護のより良い方法はECCハードウェアに切り替えることであることも理解していますが、ほとんどのPCにはまだECCがありません。
質問への答えはイエスであり、その証拠はソフトウェアです SoftECC コメントに投稿されています！
SoftECCはカーネルレベルのソリューションであることに注意してください。ユーザーランドアプリを使用する場合、冗長性の第3段階になりますが、これは必要ないようです。