2008-07-31

_ SSDの神話

私もHDDのシークの遅さには辟易しているので、 SSDに期待する気持ちが強いのはよくわかるのですけど、 ちょっと熱狂しすぎで、本当によく考えているのかなあ?と思うこともしばしばです。

OCZ Core Series のような廉価な製品が出回りはじめたおかげで、ますますこの傾向に拍車がかかっているのでしょうけれど、 個人的には、耐性の低さを考慮すると、私のようなヘビーユーザにはとても無理だろうと感じています。 SSD Write Limit には、Eee PCでどうなるかを計算してみた結果がのっていますが、 1、2年程度で壊れるのではちょっと無理です。

技術的な情報は、英語版のWikipediaの Solid-state driveFlash memoryFlash drive 辺りによくまとまっているので、詳細は割愛します。 しかし、ときどき Wear levelling のことをわかっていない人が見受けられるので、ちょっと書いておくと、

  • 論理ブロックと物理ブロックは現代のFlash memoryでは必ずしも一致しません。同じところに書き込むと、すぐ壊れるからです。
  • よって、同じところに書き込むタイプのプログラム(ジャーナリング・ファイルシステムとかトランザクショナル・データベースとか)が相性が悪いなんてことはありません。どうせソフトウェアから見て同じ位置でも、物理的には違うわけですから。
  • しかし、基本的にWear levellingは未使用のブロックを再割り当てする機構ですから、残りが少なくなればなるほど、機能しなくなります。だから、ディスクが一杯に近い状態にしてしまうと、急激に劣化しますし、一旦ブロックの破損が始まると、加速度的に壊れていきます。

残念ながら、その先にあることで、私もよくわかっていないことがあります。 識者の方にご教授いただければありがたいと思っています。 次の二点です。

  1. 未使用かどうかというのはどうやって判定するのでしょうか。今までに一度でもソフトウェア側から使ったことがある位置について、最後に使われた物理位置を記憶しておく? 仮にそうだとすると、ソフトウェア的にはもう使っていない状態のブロックも使用中ということになってしまうわけですよね。私の知る限りでは、「ここはもう使っていない」と伝達する手段はないようでしたから。そうすると、一度でもディスクを一杯にしてしまうと、その後はWear levellingが全然効かなくなってしまう?
  2. 上と微妙に繋がるのですが、セキュリティに関することです。あるファイルが絶対見られたくないとします。HDDだと、論理位置と物理位置の対応が変化することはない(LVMだとそうでもないか)ので、そのファイルだけshredすれば済みます。しかしFlash memoryだと、今までに書いたことのあるデータがあっちこっちの未使用ブロックに残っている可能性があるので、そうはいかないですよね? すると、デバイス全体を全面的にshredするしかありません。しかし、shredを全部のブロックに適用するってことは、全部使用済みに変化するってことですよね? じゃあ、一体消去対象になったSSDは、二度とWear levellingが機能しない、つまり、すぐ壊れるってことになりませんか?

SSDをHDDの代わりに使うのは、寿命がもっと長くならない限り、かなり用途を選ぶんじゃないかなあと想像します。

本日のツッコミ(全3件) [ツッコミを入れる]
_ tarosuke (2008-08-05 19:07)

スマメの仕様からの類推による一例ですが、データ領域の他に論理セクタやそのブロックの状態を記録している領域があり、使用中かどうかはそれを見て判断するようです。で、書き込むときにブロックの再配置をするので元の場所は消去されて未使用に戻されます。新しい領域は順繰りに未使用の領域を使います(最後迄行ったら最初に戻る)。あと、書き込む時には元の領域は消去される(このとき一緒にブロックが未使用=消去状態になる)のでそのファイルだけ0書きでもすれば論理的には読めないはずです。これだとタンパープルーフではありませんが。

_ 通りすがり (2008-08-15 20:56)

その管理領域が一番書き込み回数が多くなるからすぐ壊れてどういしようもなくなるって意見もよく見ますよね

_ tarosuke (2008-08-18 11:18)

いやいや、管理領域はセクタ毎に付いてて書き込みも消去もデータと同時なので回数はデータ部と同じです。スマメではね。SDとかでも同じじゃないでしょうか。単にSSDと言った場合はモノによってはアフォな実装をしている可能性もありますが。

[]

トップ «前の日記(2008-06-30) 最新 次の日記(2008-08-01)»