Hatena::ブログ(Diary)

Lansenの現実逃避日記 このページをアンテナに追加 RSSフィード

2010-04-18

[](1) 03:02 (1)を含むブックマーク (1)のブックマークコメント

「NANDフラッシュを利用した製品には寿命がある」という記述はあちこちで見かけますが、具体的に"寿命"とは何なのかという点についての詳しい説明は少ないのが現状です。…というより、今まで不勉強で僕がよく分かってなかったので、最近調べた内容について記しておきます。

SSDはどうなったら使えなくなる?

SSD寿命が尽きた状態とは、SSD内の予備領域が払底した状態を指します。

SSDをはじめとしたNANDフラッシュを利用するストレージには、必ず「予備領域」が設けられています。後述するように、SSDUSBメモリなどのコントローラは、ビットエラーが多数発生したセクタを含むブロックを"不良ブロック"とみなし"無効化"します。このとき、OSから認識されるストレージの容量が減ってしまうと困ったことになります。そこで、コントローラは、予備領域からブロックを補填することで、額面の容量が減らないようにしています。次々にブロックが無効化されていき、予備領域が空になってしまうと、ストレージは"寿命"を迎えることになります。東芝SSDの場合、この状態になるとSSDリードオンリーモードになるようです。他社製コントローラでは特に明言されていませんが、予備領域が無くなるとNANDフラッシュの仕組み上データの書き換えができなくなるので、おそらく同様にリードオンリーモードになると思われます。

一般的なコンシュマーSSDの予備領域は、"Binary Gigabytes"(GiB,1024x1024x1024Bytes)と、"Decimal Gigabytes"(GB,1000x1000x1000Bytes)との間の約7%の"ギャップ"を用いて捻出されています。例えば128GBのSSDの場合、NANDフラッシュは128GiB(=128x1.024x1.024x1.024≒137.4GB)搭載されています。その差分の約9.4GB分が予備領域になります。

予備領域の払底=寿命となるので、NANDフラッシュの総量が同じであれば、予備領域の割合が多い製品ほど寿命が長くなります。そのため、長寿命を目指した製品は予備領域の割合を多く取っています。例えば、X25-Eの64GB版は80GibのNANDを搭載しているので、全体の約25.5%が予備領域です。STEC社の産業用グレードのSSDに至っては、実に全体の約46.9%が予備領域になっています。

ビットエラーECCとブロックの無効化

どのような状態になったときにブロックを無効化するかは、SSDコントローラによって異なります。

NANDフラッシュには、ビットエラー(データ化け)が発生する可能性があります。特にMLCタイプのNANDの場合は、かなり高い確率でビットエラーが発生します。そのため、SSDコントローラは、ECC(Error-correcting code)という冗長データを書き込み時に付加し、読み込み時にそれを用いてエラーのあるビットを修正しています。

書き込み・消去時のエラーは、書き換え回数が多いほど起こりやすくなります。それが、「NANDフラッシュには書き換え回数の制限がある」と言われる所以です。一般的に、NANDフラッシュベンダは、MLCでは5,000から10,000回、SLCでは100,000回が書き換え回数の上限であるとしています。

実は、ここに一点重要なポイントがあります。この書き換え回数の上限は、NANDフラッシュベンダが指定した強度のECCを用いた時のものです。多くの場合、ベンダMLCの場合は512バイト中4ビット, SLCの場合は512バイト中1ビットを訂正可能なECCを想定しています(訂正 4ビットで済んでいたのは5xnm世代までで、最近の3xnm世代のNANDでは8ビットECCが想定されているようです。参考:【福田昭のセミコン業界最前線】NANDフラッシュメモリの信頼性を保つ技術 - PC Watch)。そのため、SSDコントローラベンダの想定より高い強度のECCを利用していれば、より多い回数を書き換えることが可能になります。

例えば、DailyTechの記事の記事によると、IndilinxBarefootコントローラは512バイト中12ビット以上のエラー訂正が可能であり、また、BCHリードソロモンの2種類のECCがハードウェア実装されているようです。一方、SandForceのSF-1500コントローラの場合は何と512バイト中24バイト(192ビット)を訂正可能なECCを搭載しています。これだけ強力なECCがあれば、相当な回数の書き換えを行っても正しくエラー訂正が可能になるでしょう。

もうお分かりかと思いますが、ブロックの無効化判定がコントローラごとに異なる理由は、コントローラごとに異なる強度・アルゴリズムECCを用いているためです。例えば、4ビットECCを用いるコントローラは、1セクタ内に5ビットめのエラー(=訂正不能)が出る前にそのセクタを含むブロックを無効化する必要があります。しかし、ECCの強度がより高ければ5ビットめのエラーも訂正可能なので、そのブロックを無効化する必要はなくなり、結果として寿命が長くなります。

NANDフラッシュビットエラーの種類について

ビットエラーは、データの読み込み時にECCをチェックすることにより、検出・修正されます。ビットエラーの種類を細かく分類すると、以下のようになります。

いずれも、書き換え回数が多いほど発生しやすくなります。余談ですが、寿命が迫ったSSDバックアップメディアとして用いるのは危険です。なぜなら、寿命が迫ったSSDではデータ保持エラーが発生する可能性が高く、しばらく机の中にSSDを放り込んでいたらデータが壊れていた、といった悲劇が発生しうるためです。そういう用途には、おとなしくHDDを使いましょう。

これらは書き込み・読み込み時に発生するエラーですが、さらに消去時のエラーというのも存在します。これは、消去動作を行っても全てのビットが1にならない現象です。この現象が発生したときは、SSDコントローラはそのブロックを無効化することが多いようです。



長くなって来たので、続きは次回にします。

MM 2010/04/20 04:13 ビットエラーが増えてきたら無効化ではなく再書き換えしている可能性もあります。
訂正可能な範囲であれば予備領域を使わずもとに戻せますので。
あと大きな予備領域はプチフリ対策として使われている可能性もありそうです。

LansenLansen 2010/04/21 01:02 >ビットエラーが増えてきたら無効化ではなく再書き換えしている可能性もあります。
その辺のポリシー的なものはおそらく各社異なっていると思われます。
東芝さんの場合はビットエラーが増えてくるとブロックを無効にしているそうです。
http://www.ssis.gr.jp/ENCORE63.pdf
(該当の記述は13ページ)
#今回の話題とは関係ないですが、上記の資料では
> もしページ単位で論理→物理アドレス変換すれば、無駄な書き換えは減らせそうだが、変換テーブルが巨大となり、RAM容量、検索時間の観点から現実的でない。
という記述がありますね。IndilinxとIntelはページレベルのアドレス変換をすでに実現してる訳ですが、東芝はまだブロックレベルなんでしょうか…?それにしてはRW4KBのスコアはそこそこ高いですが。

>あと大きな予備領域はプチフリ対策として使われている可能性もありそうです。
プチフリまでいかなくても、物理アドレスレベルの断片化による性能低下は予備領域を増やすことで軽減できます(Over-Provisioning)。
http://cuttingedge.blogzine.jp/blog/2009/12/ssdoverprovis-1.html
STECの製品の場合は、"Zeus-IOPS"なんて名前を付けているところから、どちらかというとそっちの方の意味が大きいのかもしれません。

MM 2010/04/22 00:23 東芝さんの資料は文脈からすると書き換え回数が多くなってECCで救済不能になる前に無効化するということなんでしょうね。ビットエラー数だけで見てるかどうかは微妙です。
ビットエラーは書き換え回数以外にも、経年や読み出しでも増えるので単にビットエラーだけ見て無効化するとはまりそうです。(http://www.hscjpn.co.jp/ssd/Flash.php データ・リテンションの項とリードディスターブの項)

>IndilinxとIntelはページレベルのアドレス変換をすでに実現してる
完全なページレベルのアドレス変換なんて無理でしょう。
アドレス変換テーブルのサイズを見積もればありえない数値になることが分かります。
例えば100GBで1ページ2KBとして完全な変換テーブルを持つと、26bitx52428800=163GBで自分の容量超えちゃいます。
東芝さんが言っているのはこういうのは無理だよねという話だけ思います。
部分的な変換テーブルにすればいくらでもやりようがあるので、各社で色々な取り組みをしているのでしょう。

>プチフリまでいかなくても、物理アドレスレベルの断片化による性能低下は予備領域を増やすことで軽減できます
それはプチフリ対策と言えるのではないかと思います。

LansenLansen 2010/04/23 02:54 > 東芝さんの資料は文脈からすると書き換え回数が多くなってECCで救済不能になる前に無効化するということなんでしょうね。
お、僕には逆の感じに読み取れました。
「書き換え可能回数にしてもアナログ的な量であり、明確な限界がある訳ではない」というのは、例えば書き換え回数が10,000 回を越えた途端に"正常"→"故障"というデジタルな変化を起こす訳ではない、という意味ではないでしょうか。だとすると、書き換え回数を見て無効化してしまうのはちょっと考えにくいです。
まあ、東芝の場合はNANDも自社生産なので、一般には出回ってないデータも持っているはずです。もしかすると書き換え回数と現在のビットエラーレートの両方から"不良寸前"の状態を見分けるような手法を実装してるかもしれません。

>ページレベルのアドレス変換
多分ですが、並列ないしインターリーブをばらして使うことは無いんじゃないかと思います。なので、例えば Intelの場合、ページサイズ4KBx並列数10ch=40KBがアドレス変換の単位になるのではないでしょうか。この場合、160GB版であっても、 160GB/40KB=4Mの領域にしかなりません。アドレスも1つ当たり3Byteですむので、合計12MBですね。これなら現実的です。

> プチフリ対策
もしMさんが"プチフリ"を"GCやブロックコピーで時々書き込みが遅い現象"を指しているなら、それはその通りだと思います。 IntelのG2でも300ms以上待たされるときもありますから、その現象を抑制するには予備領域の増加が有効な筈です。
僕は"プチフリ"を" ディスクが遅すぎてOSの反応が悪くなる現象"の意味で使っていました。このプチフリ現象は上記のページレベルのアドレス変換の導入でまず間違いなく発生しなくなります。Vertexの場合、完全に性能が劣化した場合でも300〜400IOPS程度は出るので、ワーストケースでは3〜4IOPS程度にまで落ち込むJMF602とは比較になりません。

ひよひよひよひよ 2010/04/23 21:00 SSD は内部で色々な工夫がされていて面白いですね。私は、表面から見ているだけなので、こういった記事は大変勉強になります。

次回も楽しみにしています。

MM 2010/04/24 00:11 同じことを言っているのに食い違うのはなんでだろう・・・
前コメントでは、
東芝さんの資料は、
(条件1):書き換え回数が多くなる
(条件2):ECCで救済不能になる
の両者が満たされたら無効化するということを意味しているのであり、
(条件2)だけで無効化判断をしているという意味には取らない方が良いのではないか、ということを言ったつもりでした。

>ページレベルのアドレス変換
これは、東芝さんの資料は、ページ単位のアドレス変換は無理だというあたりまえの話をしているだけであり、
他の方法(例えばLansenさんが述べたような方法)が無理であるということまでは言っていないのではないか、
ということを言ったつもりでした。

別の話として12MBが現実的かどうかは意見が分かれるかもしれませんが。

>プチフリ対策
ページレベルのアドレス変換は予備領域がそれなりに大きくないと機能しません。
消去単位がブロックなのでページ単位の書き換えができるわけではないからです。
予備領域が1ブロックしかないときにページレベルのアドレス変換をしたときの書き込み手順を考えてみれば、ページレベルのアドレス変換がまったく機能しないことが分かると思います。
最初に予備領域はプチフリ対策として使われている可能性もありそうですと言ったのは、
予備領域がこうしたページレベルのアドレス変換を生かすための作業領域などに使われていると思ったからです。

nitrogasnitrogas 2010/04/25 20:22 携帯用の SDメモリを買ったので offsetの違いを試してみた。
メーカー:Kingston 2Gbyte microSD 価格:680円ぐらい
USBアダプタ:IOデータのUSB2-C8RWPに、SDアダプタで接続

メーカー出荷状態にて FATフォーマット済みで、offset:137セクタ(何この半端な数字?)
--------------------------------------------------
CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------
<<< offset = 70,144byte >>>
Sequential Read : 12.201 MB/s
Sequential Write : 5.315 MB/s
Random Read 512KB : 12.221 MB/s
Random Write 512KB : 1.360 MB/s
Random Read 4KB : 1.560 MB/s
Random Write 4KB : 0.018 MB/s

Test Size : 50 MB
Date : 2010/04/25 19:51:06


で、Blockサイズ8Mと想像して、offset=16384セクタとした。
#リムーバブルUSBメモリを offset指定でパーティション作るのに難儀しました。
 イロイロ試した結果、Win2Kリソースキットの diskpar.exe(末尾t無し)で、
XP64bit環境から上手い具合にできました。

<<< offset = 8,388,608byte >>>
Sequential Read : 12.018 MB/s
Sequential Write : 3.627 MB/s
Random Read 512KB : 12.041 MB/s
Random Write 512KB : 1.168 MB/s
Random Read 4KB : 1.641 MB/s
Random Write 4KB : 0.018 MB/s

Test Size : 50 MB
Date : 2010/04/25 19:58:55

なぜだぁ〜、Seq.Wの数字が落ちてる〜〜、、、

想像するに、工場出荷時の137セクターってのは何か意味がある?
それとも、FATエントリを細工して、FLASHのブロック境界と
FATのクラスタ境界を整合させる工夫でもしてるのだろか?

邦衛邦衛 2010/04/26 10:15 ちょっと見落としがちですが、CFカードのコントローラを調べてみると面白いかもしれません。
今話題になっている様な事はCFカードでは随分前から行われているので。
日立やTDKなどのコントローラはよくできてますよ。

nitrogasnitrogas 2010/04/26 13:02 別の USBアダプタで試してみた。USBコネクタサイズの ELECOM MR-SMC03

<<< offset 137SEC >>>初期状態を再現する為に一個買い足し B-)
Sequential Read : 14.481 MB/s
Sequential Write : 7.629 MB/s
Random Read 512KB : 14.234 MB/s
Random Write 512KB : 1.231 MB/s
Random Read 4KB : 3.291 MB/s
Random Write 4KB : 0.011 MB/s

Test Size : 50 MB
Date : 2010/04/26 12:29:03

<<< offset 16384SEC >>>
Sequential Read : 18.654 MB/s
Sequential Write : 5.021 MB/s
Random Read 512KB : 18.452 MB/s
Random Write 512KB : 1.397 MB/s
Random Read 4KB : 4.475 MB/s
Random Write 4KB : 0.019 MB/s

Test Size : 50 MB
Date : 2010/04/25 22:30:22

アダプタの変換チップの性能差が結構大きいですねぇ。
それにしても、offsetの違いによる 性能差がさっぱり理解できません。

 Seq.Wに関しては 奇数境界の初期状態の方が 5割方早い
だが、Seq.Rに関しては 偶数境界に整合させた方が 29%ほど早い

一体、どういう事なんでしょ?

nitrogasnitrogas 2010/04/26 13:15 参考までに、Seq.R/Wのみサイズを変えてみた。

offset -> 137 16384 Ratio
Seq.R
50MB 14.481 18.658 0.78
100MB 14.725 18.666 0.79
500MB 14.799 18.683 0.79

Seq.W
50MB 7.629 5.273 1.45
100MB 8.245 6.128 1.35
500MB 8.974 6.956 1.29

う〜む、ますます和歌欄、、、

asukaasuka 2010/04/26 15:11 >nitrogasさん
Kingstonとの事ですが、OEM元は東芝あたりですか?
OEM元はMIDが読めれば比較的簡単に判るのですが、Windows環境で簡単に読める方法って無さそうですね
SDIO経由でならば読めそうですけど…

SDの場合、MBR,BPB,FAT等の領域と、Userdataの領域ではControllerが細工をしているらしくpage境界が変わっているみたいというか、そんな製品が存在しています。
これは、SD規格がファイルシステムまで含めた規格になっているから可能なんでしょうね。
そんな訳で、単にLBAで考えてPartition offsetを指定しただけでは速度は出ないかと思います。
SD,SDHCの頭0x2000sec程度をddあたりで保存しつつ、各種SDロゴ取得機でformatを行って比較していけば、それなりに判るのではないかと思います。

参考までに手元に有ったSONYブランドMicroSD(SEC製)で調べた所、こんな感じでした
SDAに貢げば詳細まで判るんだろうなというか、公開情報だけでももうちっと判るのかしら???

SONY P/N:SR-2A1
SCE P/N:MMAGR02GUDCA-DB
16Gb MLC SKYMEDI

0 partition table
251 Partition1 BPB
252(242) FAT1
494(242) FAT2
736(32) DIR
800 Userdata

以下余談
JMF602 128GBのFWを090928Sに書き換えるついでに、System Block countを通常の2倍程度(3796)確保してみました
手抜きな性能確認する限り、初期状態では特に優位性は無さそうでした
今後使い続けて、どれだけPerformanceが落ちるか確認してみたいと思います

というか、MLC 4kb 8Channelなので、Partition offsetを64の倍数にしてから確認するべきかと思いつつ、お手軽リカバリーソフトが見つからないのでしばらくはOffset 8のまま使う予定です

さらに余談
JSMonitor 0.4cのlog fileは、値が戻ると固まる様ですね
FW書き換え時にS.M.A.R.T. dataまで初期化されて、Power cycleやErace countまで初期化されたdataと、以前のdataをAppendしてたら、見事に固まりました
通常だったらあり得ないので無視しても良いような気はしますが、taskmgrのお世話にはあまりなりたくないなとも思います

nitrogasnitrogas 2010/04/26 17:44 話かわりますが、JSMonitorの表示の事で、、、

単機能の表示装置として使っていて、注意深く SSDへの書き込みを
RAM-DISKに逃がして使っている積もりです。↓

TECが 2431年というのは納得できるのですが、(2.1GB/day)と表示されます。
どう考えても 2.1GB/dayは使って無いと思うのですが、
書き込み量の判定式はどんな具合なんでしょうか?

-------JSMonitor Version 0.4c-------
Copyright (C) Lansen 2008-2009
<Drive #0>
Controller: JMicron JMF601/602 Family
Model: BUFFALO SHD-NPUM32G
Drive Size: 32.3GB
Serial Number: 04032022010012200025
Firmware Version: 04.90331
Firmware Date: 09/03/31
Flash Vendor: Samsung
Flash Type: MLC
Flash Name: K9GAG08U0D
Block Size: 4MB
Flash ID: 0xEC 0xD5 0x94 0x29 0x34 0x41 0xEC
Channels: 8
Banks: 2
Power Cycle Count: 85
Average Erase Count: 7
Maximum Erase Count: 59
Good Block Count: 8120
System Block Count: 416
Error Correction Count: 0
Last EC Channel: 0
Last EC Bank: 0
Last EC Address: 0x00 0x00 0x00
Expected T.E.C.: 2431/07/11
T.E.C. Calculated using: Average Erase Count (Last 100 Data)

LansenLansen 2010/04/27 02:02 皆様、返信が遅く申し訳ありません。

>Mさん
Mさんの仰りたいことは理解いたしました。
既に認識に差があるところはないと思います。
どっかで「"SSDのページサイズ"とは、NANDのページサイズに並列化の数を掛けたサイズになる」と読んだような気がしていたのですが、ソースが見つからないので妄想だった気がしてきました…

>nitrogasさん
offsetに関しては謎度が高いですね…
正確な測定のためには、まず高性能なリーダが必要かもです。

JSMonitorの使用量表示が多く感じる理由は、JMF602のWrite Amplificationが非常に大きいためです。コントローラのアルゴリズムがあまりよろしくない証拠です。
他の方の結果と比較すると2.1GB/Dayは相当少ないです。このくらいなら、実質的に寿命を気にする必要はないと思います。

>邦衛さん
SanのExtreme Proは42ビットECC搭載だそうですね。
http://www.sandisk.co.jp/Corporate/PressRoom/PressReleases/PressRelease.aspx?ID=4347
並のSSDより遥かに高いECC強度ですね。まあお値段も並のSSDよりずっと高いですが…

>asukaさん
もし可能でしたら、不具合が生じるログデータをどこかにアップロードしていただくか、メールで送付していただけませんか?
ちょっと現実生活が忙しくて、すぐに対応できるかどうかは分からないのですが…

asukaasuka 2010/04/27 22:46 >Lansenさん
固まるlogを以下にuploadしました。1週間程度は保存されているらしいです
http://firestorage.jp/download/76fc918037bc8c4453662750ab7ea4b9650138d7
FW書き換え前後のLogをtexteditorで繋げた奴で、実際にはあり得ない様なdataですので、無理に対応する必要はないかと
不正な形式としてrejectしてくれれば、ありがたいですが

LansenLansen 2010/04/28 01:11 >asukaさん
ありがとうございました。ダウンロードできました。
なんかリセットした後に不良ブロックが復活しちゃってますね。
使用前にランダムパターンを何度か書き込んで、不良ブロックを探しておいた方がいいかもしれません。

asukaasuka 2010/04/29 18:10 >Lansenさん
単純にFWをupdateするだけの場合は、不良ブロック等の値は受け継いでいたのですが、
System Blockを増やす所でやらかした時に、完全に初期化されてしまいました
製品名やシリアルナンバーまで手入力する事になりました
完全な煉瓦にならなかったのが不幸中の幸いです

不良ブロックの検出って、どの様なアルゴリズムで行われているでしょうか?
書き込み時にベリファイの様な処理が有るとも思えないので、readして初めてeccで検出あたりでしょうか?
ddで、0x55,0xAAあたりのパターンを読み書きすればそれなりに検出できるかな?
NAND MLCの場合、もうちっと深く考えた方が良いのかというか、多値cellをどうbit割り当てているのかという事まで考慮する場合、まじめに検出するには結構複雑な手順が必要かしら?

以前の話になりますが、TestDiskでMBRの修復は試していませんでしたので、機会を見て試してみたいと思います
USB経由で覗いた時は、fileは復元できていた様なので、TrueImageと併用でうまくいくかもしれません

LansenLansen 2010/04/30 00:52 不良ブロックの検出方法はこのエントリの本文に書いてある以上のことはちょっと分からないですが、読み込み時にECCをチェックして見分けているのは間違いなさそうです。
エラービットの出方はかなりランダム性が高いので、確実に検出するのは無理な予感もします…

トラックバック - http://d.hatena.ne.jp/Lansen/20100418/1271613736