- SSD・ゼロスピ化・ストライピング 7台目
959 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 11:22:01 ID:MpOGl530 - 俺はそれ以外の原因は知らないな。
実際、Intel・東芝・C300あたりはプチフリとは一切無縁だし。
|
- SSD・ゼロスピ化・ストライピング 7台目
961 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 13:40:42 ID:MpOGl530 - 数秒フリーズする奴はあるみたいだぞ
|
- SSD・ゼロスピ化・ストライピング 7台目
964 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 20:31:52 ID:MpOGl530 - SSDはよっぽどウェアレベリングのアルゴリズムが優れてない限り、
使用していく内にある程度は速度低下する。
IntelでもC300でも多少は速度低下するし、JMF602だと酷い事になる。
そういう場合でもあくまで煩雑なウェアレベリングにSSDコントローラが手一杯なだけで
故障しかけているという訳ではなく、一旦SecureEraseして全てのセルを0にする事で速度は回復する。
故障直前にもそういう現象が起きるかも知れないが、
東芝64GBですら880TB、Intel X25-V(40GB)では600TB以上の書き込み寿命があるので
仮にここ一年間に販売されたSSDにプチフリが発生したとしても今の時点で寿命を迎えたとは到底考えられない。
|
- SSD・ゼロスピ化・ストライピング 7台目
966 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 20:59:32 ID:MpOGl530 - JMF602が速度低下しないとか…
それこそ酷い出鱈目だな
|
- SSD・ゼロスピ化・ストライピング 7台目
969 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 21:18:23 ID:MpOGl530 - ちなみに、SecureEraseのQ&Aにはユーザーデータを消すとは書いてあっても
管理情報をリセットするとは欠片も書いてないな。
＞Secure erase is a positive easy-to-use data destroy command,
＞amounting to “electronic data shredding.”
＞It completely erases all possible user data areas by overwriting,
>>968
ID:9PguVLv8がID:wiPY6RAに見えるんだが…
|
- SSD・ゼロスピ化・ストライピング 7台目
971 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 21:22:12 ID:MpOGl530 - >>967
SSDはファイルシステムを認識できないし、フォーマットではtrimコマンドも発行されないので
フォーマットでは何も改善しないよ。
フォーマットしても実際に書き換えられるのはパーティションの管理領域のみで、
生データは残ったままだ。だからこそファイル復元ソフトでファイルを復元出来るわけなのだが。
|
- SSD・ゼロスピ化・ストライピング 7台目
974 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 21:37:13 ID:MpOGl530 - >>972
シーケンシャルが200を超えるような今時のSSDで数十GBをゼロフィルしても数分で終わるのだが。
そもそもプログラム作者自身が言っている事を根拠も無く否定するとは恐れ入る。
その上ソースがブログとは恐れ入るね。そこのブログ主、以前アホな事書いて叩かれてた奴じゃないか。
プロフィール画像変えてスミマセンしてたような奴だぞ。
http://d.hatena.ne.jp/Lansen/about
|
- SSD・ゼロスピ化・ストライピング 7台目
977 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 21:55:34 ID:MpOGl530 - >>976
現実云々言うならプログラムの作者によるQ&Aくらい熟読するべきだな。
|
- SSD・ゼロスピ化・ストライピング 7台目
978 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 21:58:38 ID:MpOGl530 - >>976
ちょっと待て、LBA領域？
君、LBAの意味わかってるか？
|
- SSD・ゼロスピ化・ストライピング 7台目
981 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 22:18:25 ID:MpOGl530 - とりあえず疑問に思った事を書いておこう。
まず>>965では
>JMF602は物理アドレス上の断片化は起きない。（＝速度低下しない）
と書いている。にもかかわらず、
>>972で張ったブログでは明らかにJMF602採用のSSDで速度低下が起きている…
この時点でもう何を主張したいのかさっぱりわからん。
＞ここで見られる速度低下はフォーマットで改善する。
とも書いてるが、そのブログで行われた実験は空き領域のデフラグであって
パーティション削除＆作成とかパーティションのフォーマットではない。
>>972で書いた「フォーマット」も「空き領域のデフラグ」に訂正するのか？
言いたい事があったらもう少し整理してから書き込んだ方がいいんじゃないのか？
|
- SSD・ゼロスピ化・ストライピング 7台目
984 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 22:59:12 ID:MpOGl530 - >>983
君こそ>>971を読んだ方がいいな。
デフラグはファイルが移動される、つまり元々ファイルがあった位置のデータが別の位置にコピーされて、
それに合わせてファイルシステム上のファイルの位置情報も書き換えられるが、
元々ファイルがあった位置にあるデータはゼロフィルされる訳ではないので残骸として、上書きされるまで残り続ける。
これはファイルシステム上既に不要な残骸データだが、SSDはそれを認識できないし
そのデータを必要なデータとして上書きされるまで保持し続ける。
だからデフラグしようとフォーマットしようと、物理的にフラッシュメモリ上にはゴミデータが残り続けるし
フラッシュメモリ上の断片化したまま残った残骸データをどうこうできる訳じゃない。
だからこそそういった不要な残骸データをSSDに不要だと通知するためにTrimコマンドが生まれたり、
ファイル復元ソフトで復元できないようにデータ完全削除ソフトが生まれたわけだ。
んで、なんだって？
|
- SSD・ゼロスピ化・ストライピング 7台目
986 ：[Fn]＋[名無しさん][sage]：2010/10/18(月) 23:30:49 ID:MpOGl530 - >>985
それは良かった。その程度は理解してくれたか。
で、まさかJMF602がウェアレベリングしてないなんて思ってるんじゃないよな？
>>965でJMF602で物理アドレス上の断片化は起こらないとか書いちゃってるけど、
ブロック単位でのアドレス変換もしてないとでも思ってるのか？
ウェアレベリングなんて大昔のCFでもやってる事だ。
JMF602だってゼロフィルで速度低下は回復するし、
IntelのX25-Mだってファイルシステムに対して行うデフラグで僅かに速度低下は回復する。
両者のアルゴリズムには世代差があるが、速度低下する原因が根本的に違うと主張したいのかな？
|