シンプロシリーズ5回目。今回はFlash/SSD編
以下、第1回目の投稿で、FlashSystem 900にはシンプロがないのになぜUNMAPに対応している必要があるのだろう？と思われた方もいるかも知れません。
それは、Flashメモリーの特性と関連します。
Flashは図1のように、データの書き込みはページ単位で行われますが、上書きを行う際は既に書き込んである領域へ直接上書きは出来ずに、別の空き領域へ有効データが入ったブロックを移動させた上でその空き領域にページを書き込みます。
まだ空き領域があるうちは、新規データを空いているブロック内のページに書き込んでいけば良いですが、空き領域がなくなってくると元のブロックを消してブロック全体を上書きするというオペレーションが発生します。ページのサイズは通常4KB～16KB、ブロックのサイズは数MBのオーダーが多く、最小の512バイトの書き込みでも1ページの書き込みは行われますし、ブロック単位での消去、書き込みが発生することもあります。実際の書き込みサイズの何倍も大きなサイズを書き込むことになるため、大きなムダが発生します。これをWrite Amplificationと呼びます。
また、空きがない時のブロックの消去には数msかかったりすることもあるため、書き込みのパフォーマンスが極端に落ちることもあります(Write Cliff)。
図1.データの書き込み方
書き込みの際にWrite Amplificationとブロックの消去が発生することを避けるためには、空き領域を多くすることですが、ブロックを消去するには、その中のページ全て無効な領域である必要があります。
このため、FlashではGarbage Collectionという機能により、無効となっているブロックを消去するとともに、有効なページだけを統合することで、より多くの無効なブロックを消去していきます(図2)。
図2.Garbage Collection
Garbage Collectionはデータ領域が無効となっていることが条件です。しかし、これまでに述べてきたようにOS上でデータを削除したとしても、それがストレージ上では無効なデータとならないケースが出てきます。
そうすると、Flash上ではデータが削除されないため、より多くのWrite Amplificationとブロックの消去のオペレーションが発生してしまいます。
ここで、無効なデータ領域を「無効である」としてくれるのがSCSI UNMAPです。Flashの世界だと、TRIMと呼ばれますが、SCSI UNMAPとほぼ同じ意味合いです。
このTRIMによりデータ領域が無効化され、Garbage Collectionによって領域が解放されるということになります。
Flash/SSDを使用する書き込みが多い環境では、SCSI UNMAP(TRIM)が使用可能かも少しは意識しておいたほうが良いでしょう。
書き込みが少ないような環境はあまり意識しなくて良いでしょう。
なお、IBM FlashSystemは圧縮や重複排除の技術により書き込み量を減らしている点と、Garbage Collection用にユーザーが使用できない余剰な容量を持たせているため、書き込みのパフォーマンスへの影響はかなり軽減されていますので、極端に気にする必要はないでしょう(今までそこに至ったというのは聞いたことがありません)。
なお、以下のBlogにあるように、FS900 AE3に関してはOOPSにご注意ください。
FlashSystem 900 AE3のOOPSに注意！
#flashsystem#scsi-unmap