Seagate Momentus XTハイブリッドハードドライブがLinux上のファイルを破損しています。だれからも助けていただければ幸いですが、他のMomentus XTユーザーがこの問題を再現できるかどうか、特に知りたいです。Seagate Community Forumsでこの問題を再現するための手順を説明しました。
これまでのところ、4人のユーザーが次のラップトップとOS /ディストリビューションでこの問題を再現しています。
- 5つのラップトップ:Lenovo Thinkpad T60、T61、T510、MSI MS-1656-ID1、およびMacBook Pro(15インチ2009年後半)。
- 4つのOS /ディストリビューション:Ubuntu 11.04、Fedora 15、openSUSE、Mac OSX。
問題を再現するための手順は簡単です。これは簡単な口頭の説明です:
- 大きなテストファイルを作成し、別のストレージデバイス(Momentus XTではない)に保存して、SHA-1チェックサムを計算します。
- テストファイルをMomentus XTに書き込みます。
- Momentus XTからテストファイルを読み取り、SHA-1を計算し、このチェックサムを元のチェックサムと比較します。一致する必要があります。一致しない場合は、問題を再現したと考えられます。(他の問題が原因で不一致が発生する可能性があるため、「おそらく」のみです
cmp -l
。ファイルをと比較してこの特定の問題を特定する方法については、Seagateスレッドを参照してください。) - 手順(2)から繰り返します。
Seagateのスレッドは、より多くの詳細を持っています。ここに私のテストからのいくつかのメモがあります(私はこの問題を3つの連続したMomentus XTドライブで再現することができました。
- 起こっているように見えるのは、Momentus XTがドライブへのデータの書き込みを時々無視するため、ドライブから読み取ったときに、セクターに元々あったものであり、正しいデータではないということです。これは、サイズの異なるブロックで発生します。典型的なサイズは1 MiBと512 KiBです。
- 問題はext2、ext4、Btrfs、NTFS、およびFAT32で発生します。不思議なことに、私はext3でこの問題を再現できませんでした。
- で
oflag=direct
出力フラグを使用して書き込むと、dd
この問題を回避できます。でディスクにデータを迅速にコミットすることでwhile true; do sync; sleep 0.01; done
も問題を防ぎます。 - 私は、SATAおよびeSATAインターフェースを介してのみこの問題を再現できました。USB接続で問題が回避されているようです。(これが転送速度によるものかどうかは不明です。)
- 大きなファイル(> 2 GB)で問題がより頻繁に発生します。約85 MB未満のファイルでは問題を生成できませんでした。
- NTFSを使用するWindows XPで問題を再現できませんでした。
- SeagateフォーラムのGazoiは、UFS2を使用するFreeBSD 8.2で問題を再現できませんでした。
- Momentus XTは、拡張SMARTテストの両方に
badblocks -w
問題なく合格します。 - 私のラップトップ(MS-1656-ID1)は、Memtest86 +、Memtest86、memtester、およびMPrimeをそれぞれ24時間正常に通過しました。
- 他の2つのストレージデバイス(Seagate Momentus 7200.4とIntel 320シリーズSSD)を同じ手順でテストしましたが、どちらも問題なくパスしました。
Momentus XTをお持ちの場合は、この問題を再現してみてください。
問題を診断するために他に何ができますか?
iflag=direct
入力フラグをddで読み取ることにより、ページキャッシュをバイパスしています。私がddを使用していないときは、キャッシュをフラッシュしますsudo sh -c "sync && echo 1 > /proc/sys/vm/drop_caches"