MACH XTREME Tech MX-DSのSecureEraseについて
SandForceのSF-1200を採用しているMACH XTREME TechのMX-DSシリーズをちょっとだけですが、使う機会がありました。そのときに気がついた点を今回はレポートします。
まず、SF-1200を採用したMX-DSですが、先に登場したG-Monster2 SFV1とは異なるファームウェアを使っているようです。(G-Monster2は、「232A11F0」ですが、本製品は、「302A13F0」です)このためか、初期状態のベンチーマーク速度は、SF-1500採用のG-Monster2 SFV1とほぼ遜色ありません。(ベンチマークを見る限りでは、大きな差はない感じでした。PCMark Vantage HDD Test Suiteの結果は、逆にSF-1200の方がよいぐらいです)
ただし、ファームウェアが変わったためか、「SecureErase」を行うと、少なくとも僕の環境では、問題が発生しました。それは、SAMRTがおなしな挙動をするようになったことです。この製品も、SecureEraseを行えますが、その手順は、G-Monster2 SFV1と同じ方法でしか行えません。具体的に説明すると、HDDEraseを使う場合は、システム起動後に本製品を接続することでSecureEraseを行え、LunixのHDPARMを使う場合は、途中でホットスワップすることで行えます。
問題は、その後です。まず、最初に起きたのが、BIOSのSMARTチェックで常にエラーが表示されるようになりました。最初は、いきなりエラーが表示されてびっくりしましたが、じっくりと画面をみているとSMARTでエラーがでていることがわかりました。そこで、色々なツールを使ってSMARTがちゃんと動作していないかチェックしてみましたが、コマンドそのものは、普通にEnableに設定されており、問題なく動作しているようです。問題は、その内容です。
Crystal Disk Infoで内容をみてみると、G-Monster2 SFV1で、リードエラーレート(01)とECC回数(C3)と表示されている情報の内容が同じになっていました。しかも、この数値、電源をOFFにすると0に元に戻り、しばらく使っているとどんどん数値が上がっていき、Crystal Disk Infoの情報を更新するだけで上がります。もちろん同じ数値で。加えて、不良ブロック数(05)の生の値が540になっています。
このような現象が起きるとは思っていなかったので、初期がどうだったかはみていません。しかし、そもそもBIOSでSMARTのエラーが表示されること自体はなかったので、おそらく、SecureEraseしたことによって、情報がおかしくなったのではないかと思っております。
というのも、この状態でOSをインストールして使ってみましたが、特に問題がでることなく使用できていますし、ベンチマークを実行しても速度が落ちたなどの現象は発生していません。数値どおりのリードエラーレートなら何かしらでてもおかしくないと思いますが、サラッと使ってみた限りでは特に問題はでていないような感じでした(もっとハードな使い方をすれば違うかもしれませんが)。 個人的な印象では、SSD自体の動作自体に問題はないような感じで、SMARTの数値のみがおかしくなっているという印象です。
これが僕の環境のみで発生した現象なら、テストしたSSD固有の現象ということで問題はないのですが、SSDに問題がないとしたら、他の方でも同じような現象がでる可能性もあります。このため、とりあえず、本製品でSecureEraseを行うことは推奨しません。もし、怖いもの見たさでSecureEraseを行い僕と同じ現象が出たという方がいたら、報告していただけたらと思います。
まず、SF-1200を採用したMX-DSですが、先に登場したG-Monster2 SFV1とは異なるファームウェアを使っているようです。(G-Monster2は、「232A11F0」ですが、本製品は、「302A13F0」です)このためか、初期状態のベンチーマーク速度は、SF-1500採用のG-Monster2 SFV1とほぼ遜色ありません。(ベンチマークを見る限りでは、大きな差はない感じでした。PCMark Vantage HDD Test Suiteの結果は、逆にSF-1200の方がよいぐらいです)
ただし、ファームウェアが変わったためか、「SecureErase」を行うと、少なくとも僕の環境では、問題が発生しました。それは、SAMRTがおなしな挙動をするようになったことです。この製品も、SecureEraseを行えますが、その手順は、G-Monster2 SFV1と同じ方法でしか行えません。具体的に説明すると、HDDEraseを使う場合は、システム起動後に本製品を接続することでSecureEraseを行え、LunixのHDPARMを使う場合は、途中でホットスワップすることで行えます。
問題は、その後です。まず、最初に起きたのが、BIOSのSMARTチェックで常にエラーが表示されるようになりました。最初は、いきなりエラーが表示されてびっくりしましたが、じっくりと画面をみているとSMARTでエラーがでていることがわかりました。そこで、色々なツールを使ってSMARTがちゃんと動作していないかチェックしてみましたが、コマンドそのものは、普通にEnableに設定されており、問題なく動作しているようです。問題は、その内容です。
Crystal Disk Infoで内容をみてみると、G-Monster2 SFV1で、リードエラーレート(01)とECC回数(C3)と表示されている情報の内容が同じになっていました。しかも、この数値、電源をOFFにすると0に元に戻り、しばらく使っているとどんどん数値が上がっていき、Crystal Disk Infoの情報を更新するだけで上がります。もちろん同じ数値で。加えて、不良ブロック数(05)の生の値が540になっています。
このような現象が起きるとは思っていなかったので、初期がどうだったかはみていません。しかし、そもそもBIOSでSMARTのエラーが表示されること自体はなかったので、おそらく、SecureEraseしたことによって、情報がおかしくなったのではないかと思っております。
というのも、この状態でOSをインストールして使ってみましたが、特に問題がでることなく使用できていますし、ベンチマークを実行しても速度が落ちたなどの現象は発生していません。数値どおりのリードエラーレートなら何かしらでてもおかしくないと思いますが、サラッと使ってみた限りでは特に問題はでていないような感じでした(もっとハードな使い方をすれば違うかもしれませんが)。 個人的な印象では、SSD自体の動作自体に問題はないような感じで、SMARTの数値のみがおかしくなっているという印象です。
これが僕の環境のみで発生した現象なら、テストしたSSD固有の現象ということで問題はないのですが、SSDに問題がないとしたら、他の方でも同じような現象がでる可能性もあります。このため、とりあえず、本製品でSecureEraseを行うことは推奨しません。もし、怖いもの見たさでSecureEraseを行い僕と同じ現象が出たという方がいたら、報告していただけたらと思います。
http://www.behardware.com/news/10962/sandforce-amp-trim-listen-up.html
返信削除上記の記事によると、MicrosoftのAHCIドライバはTrimコマンドに問題を抱えていて
SandforceコントローラだとTrimがうまく機能しないということがある模様。
関係者が協議しているとのことですが、検証する際は注意した方がよさそうです。
機種が違うので別な問題かもしれませんが、GMonster2 SFV1 では電源投入時の Read Error Rate における現在値は 0, しきい値は 50 となるため、電源投入時のチェックで S.M.A.R.T. STATUS は BAD となります。
返信削除データをちょっと読み書きすると普通の表示になったのでファームウェアのバグかと思うのですが。そのため、CrystalDiskInfo では"異常"と判定しないように対策をしています。
詳細は以下のページで検証しております。ひょっとすると参考になるかもしれません。
http://crystalmark.info/bbs/c-board.cgi?cmd=one;no=3534;id=report#3534
ひよひよさん
返信削除コメントありがとうございます。
物はすでに返却してしまっているので、何ともいえませんが、当時の状況は、SecureEraseをするまでは特にBIOSでエラーがでてはいませんでした。
また、エラーがでるようになったあとも何か記録したあと、リブートした場合でも必ずBIOSでエラーが表示されるという症状でした。
とりあえず、その後、別な機体を使う機会があったので、ファームアップして恐る恐るSecureEraseを行ってみましたが、特に問題がでることはありませんでした。何が原因だったのか原因は不明のままです。
どうも僕は、SandForceとは相性が悪いらしく、短期間の検証ですでに2台ほど困ったことになりました。1台は、前述のMX-DSで、もう1台は、VertexLEです。VertexLEもSecureEraseして、取り外し、次に電源を入れたときはBIOSにすら認識されないという状況でした(笑)