幸いなことに、一部のディスクアクセス時間の測定中に、すべてゼロで書かれたSSDのファイルにゼロ以外のバイトが1つ含まれていることがわかりました。
ファイルをアーカイブし、新しいファイルで同じ実験を試しましたが、ゼロ以外のバイトが見つかりませんでした。
その後、すべてのファイルを削除して再起動しましたが、いずれかのファイルでゼロ以外のバイトだけが再び見つかりました。
それから私は走ったsmartctl -t long。完全な「表面」をテストするという内容を読んだので、SSDの場合、これはすべてのバイトを書くか読んで、どこかに記載されているエラーを予想することを意味すると仮定しましたが、何も見つかりませんでした。
私は記録されたすべてのバイトがRAMを通過するので、最終的にはまだRAMのバグであると思います。
ビットが不安定なRAMではなくディスク上にあることを確認したい場合は、smartctlどういうわけか証明できますか？
答え1
私の質問は削除できますが、@likkachuがコメントで提案したように、以下に説明する方法は答えです。そして他の人に私のように急いで結論を出さないでください。
それはチップラムコメントで示唆したように、SSDに欠陥があることを証明するよりもメモリテスタを実行する方が簡単です。使った
- memtester（Ubuntuや他のディストリビューションで利用可能）は、RAMの問題をすばやく表示できます。 memtesterを使用して物理アドレスを見つけることができません。
- memtest86+はUEFIの起動により起動が難しく、
ddmemtest86イメージをUSBに挿入して実行しようとしました。それは私に実際の住所を与えます。しかし、実際に最も簡単なものは次のとおりです。 - memtest（またはmemtest = n、ここでnは[1..17]にあります）パラメータをカーネルブートパラメータとして追加します。たとえば、単一のブートに対してgrubのブートパラメータを編集します（メニューは通常スキップされました）。
カーネルがフレークアドレスを見つけました。/var/log/kern.log次の内容を確認してください。
bad mem addr 0x00000000a31b7320 - 0x00000000a31b7328 reserved
それから追加しました。
GRUB_BADRAM="0x0a31b7320,0xffffffff0"
ただ逃げ/etc/default/grubましたupdate-grub。マスクには9桁の数字があります。 8ビット数の場合、これは各4 GB RAMブロックに適用されます。
起動後、次の/var/log/kern.log内容が含まれます。
reserve setup_data: [mem 0x00000000a31b7000-0x00000000a31b7fff] unusable
これは、グラブまたはカーネルがマスクを4096バイトの全ページに丸めることを意味します。これは、マスクにあまりにも具体的に指定しても害にならないことを意味しますGRUB_BADRAM。やり直しmemtesterても問題は見つかりません。