ライトアンプリフィケーション
ライトアンプリフィケーション(書き込みの増幅) (WA:Write Amplification) は、フラッシュメモリやソリッドステートドライブ(SSD)において、実際に書き込んだデータの量よりも、フラッシュチップに対する書込量が増加すると言う、好まざる現象の事を言う。
フラッシュメモリに再書き込みを行うためには前もってその領域の消去が必要である。そのためにはデータやメタデータの移動や再書き込みが一度以上必要となる。 この動作増加作用は書込回数を増やし、SSDが信頼性を持って動作することのできる期間を短縮する。 書込回数増加はまたフラッシュメモリへの帯域を消費し、SSDの主にランダムライトの性能を低下させる。多くの要因がSSDのライトアンプリフィケーションに影響する。一部はユーザーによるコントロールが可能であり、一部は書き込まれるデータやSSDの使用法そのものが原因となる。
インテルとシリコンシステムズ(ウェスタンデジタルが2009年に買収)は2008年迄には論文や出版物にライトアンプリフィケーションという単語を使用していた。ライトアンプリフィケーション値(WA値)は普通ホストよりの書込データ量とフラッシュメモリへ渡される書込データ量の比によって計られ、圧縮無しにはWA値は1を下回ることはない。サンドフォースは圧縮を用いることで通常のWA値0.5、SF-2281コントローラーを使用し最善の状況で0.14を達成したと主張した。
フラッシュメモリの特質として、メモリにあるデータを直接「書き換える」こと(オーバーライト)が原理上不可能であり、これはハードディスクドライブとは異なっている。SSDにデータが書き込まれるとき、該当するフラッシュメモリのセルはすべて「消去」されており、そのようなページ(通常サイズは4KiB)に対して一度にデータが書き込まれる。
SSD内に存在する、フラッシュメモリとインターフェースをホストシステムとともに管理するSSDコントローラはフラッシュトランスレーションレイヤー(FTL)に付随するロジカルブロックアドレッシング(LBA)と呼ばれる方法を使用する。
新しいデータが既に書き込まれた古いデータと置き換わって入ってくるとSSDコントローラは新しいデータを新しい場所に書き込み、新しい物理的な場所を指すように論理マッピングを更新する。古い場所にあるデータは既に有効ではないため、その場所を再び書き込む前に消去する必要がある。
フラッシュメモリは、限られた回数しかプログラム・削除できない。これは、フラッシュメモリの寿命を通じて維持できる最大プログラム/消去サイクル数 (P/E サイクル) と呼ばれることがある。シングルレベルセル (SLC) フラッシュは、より高い性能とより長い耐久性を目指して設計されており、通常、5万~10万サイクルの間で動作させることができる。2011年現在、マルチレベル・セル(MLC)フラッシュは低コスト・アプリケーション向けに設計されており、サイクル数は通常3,000~5,000と大幅に削減されている。書き込み増幅率が低ければ低いほど、フラッシュメモリのP/Eサイクルが減少し、SSDの寿命が延びるため、より望ましいとされている。
ライト・アンプリフィケーション(WA)は、その用語が定義されるよりも以前から知られていた事実であるが、2008年にはインテルとシリコンシステムズが、この用語を資料や広報に使い始めた。
SSDはWA値を持ち、それは次のような式で表される。
あるSSDにおいてWA値を正確に測定するためには、ドライブが「安定状態」に達するために十分な時間、テスト書込が行われるべきである。
WA…WA値
NAND…フラッシュメモリへの書込データ量
HOST…ホスト側からの書込データ量
多くの要素が、SSDのWA値に影響を及ぼす。次の表は、その主要要素がどのように影響するかを列挙している。変量的要素については、表において「比例」または「反比例」の関係を示している。例えばオーバー・プロビジョニングが増大すれば、WA値が減少する(反比例の関係)。要素が二値的(有効または無効)の場合、「正」または「負」の関係を示す。
上記の要素のほか、リード・ディスターブ(en:Read_disturb)などの不良モード管理もWA値に影響を及ぼす可能性がある(→#SSDにおけるガベージコレクション(GC))。
なお、SSDに対するデフラグメンテーション処理については、「SSDでのデフラグ」を参照。
データは、複数の記憶セルで構成される「ページ」と言う単位でフラッシュメモリーに書き込まれる。しかし消去は、複数のページで構成される、より大きい「ブロック」と言う単位でのみ可能となる。もしあるブロック内のあるページのデータが不要になった場合("stale"ページと呼ばれる)、そのブロック内の必要なデータがあるページのみ、他の消去済みブロックに転送(書込)される。 そして"stale"ページは転送(書込)されないため、転送先のブロックでフリーなページとして新しい別のデータを書き込むことができる。ここまでの処理を「ガベージコレクション(以下GC)」と呼ぶ。全てのSSDは何らかのGCの仕組みを備えているが、GCをいつ、どのように処理するかはそれぞれ異なっている。GCはSSDのライト・アンプリフィケーションに大きな影響がある。
読み込み動作については、フラッシュメモリーを消去する必要はないため、通常はライトアンプリフィケーションに関連付けられることはない。しかしリード・ディスターブ(Read_disturb)などの不良モードが発生する前に、そのブロックは書き直しが行われる。もっとも、この事は、ドライブのライトアンプリフィケーション対する実質的な影響度は低いと見られている。
GCのプロセスはフラッシュメモリーの読込と再書込動作を伴う。つまりホストからの新しい書込指令によって、1ブロック全体の読込と、そのブロックのうち有効なデータを含む部分の書込、そして新しいデータの書込がまず必要となる。これはシステムの性能を著しく低減させる。
SSDのコントローラーには「バックグラウンドGC(BGC)」、「アイドル時GC(ITGC)」などと呼ばれる機能を備えるものがある。これは、コントローラーがSSDのアイドル時に、ホスト側から新しい書込データが来るよりも前に、フラッシュメモリーの複数のブロックを統合するものである。これによりデバイスの性能の低下を防ぐ事ができる。
If the controller were to background garbage collect all of the spare blocks before it was absolutely necessary, new data written from the host could be written without having to move any data in advance, letting the performance operate at its peak speed. The trade-off is that some of those blocks of data are actually not needed by the host and will eventually be deleted, but the OS did not tell the controller this information. The result is that the soon-to-be-deleted data is rewritten to another location in the flash memory increasing the write amplification. In some of the SSDs from OCZ the background garbage collection only clears up a small number of blocks then stops, thereby limiting the amount of excessive writes. Another solution is to have an efficient garbage collection system which can perform the necessary moves in parallel with the host writes. This solution is more effective in high write environments where the SSD is rarely idle. The SandForce SSD controllers and the systems from Violin Memory have this capability.
→ もしSSDコントローラが、絶対に必要になる前に、予備ブロックをすべてバックグラウンドでGCしていれば、ホストから書き込まれる新しいデータは事前に元々あったデータを移動する必要がなく、性能を最高のスピードで動作させることができる。
そのトレードオフとして、それらのデータブロックの中には、実はホストが必要とせず、"いずれ削除されるもの"もあるのだが、OSはいずれ削除されるデータもあるということをSSDコントローラには伝えなかった場合、"すぐに削除されるデータ"は、フラッシュメモリ内の別の場所に書き直され、書き込み増幅率が上昇してしまう。OCZが販売する一部のSSDでは、バックグラウンドのGCが少数のブロックのみを削除して停止するため、過剰な書き込みの量が抑えられる。
もう一つの解決策として、ホストからの書き込みと並行して必要な移動を実行できる、効率的なGCシステムを持つことが挙げられる。この方法は、SSDがほとんどアイドル状態でない、書き込み量の多い環境においてより効果的である。SandForce SSDコントローラやViolin Memoryのシステムには、この機能が搭載されている。
In 2010, some manufacturers (notably Samsung) introduced SSD controllers that extended the concept of BGC to analyze the  used on the SSD, to identify recently deleted files and unpartitioned space. The manufacturer claimed that this would ensure that even systems (operating systems and SATA controller hardware) which do not support TRIM could achieve similar performance. The operation of the Samsung implementation appeared to assume and require an NTFS file system. It is not clear if this feature is still available in currently shipping SSDs from these manufacturers. Systematic data corruption has been reported on these drives if they are not formatted properly using MBR and NTFS.
→ 2010年、一部のメーカー(特にSamsung)は、BGCの概念を拡張してSSD上で使用されているファイルシステムを分析し、最近削除されたファイルや未パーティションの領域を特定するSSDコントローラを発表した。メーカーは、これにより、TRIMをサポートしていないシステム(OSやSATAコントローラのハードウェア)でも、同様の性能を達成できると主張している。Samsungの実装の動作は、NTFSファイルシステムを前提とし、それを必要とするように見えた。だが現在出荷されているこれらのメーカーのSSDで、この機能がまだ利用可能かどうかは不明である。MBRとNTFSを使用して適切にフォーマットされていない場合、これらのドライブで体系的なデータ破損が報告されている。
Over-provisioning (sometimes spelled as OP, over provisioning, or overprovisioning) is the difference between the physical capacity of the flash memory and the logical capacity presented through the operating system (OS) as available for the user. During the garbage collection, wear-leveling, and bad block mapping operations on the SSD, the additional space from over-provisioning helps lower the write amplification when the controller writes to the flash memory.
The first level of over-provisioning comes from the computation of the capacity and the use of units for gigabyte (GB) where in fact it should be written as gibibyte (GiB). Both HDD and SSD vendors use the term GB to represent a decimal GB or 1,000,000,000 (10^9)bytes. Flash memory (like most other electronic storage) is assembled in powers of two, so calculating the physical capacity of an SSD would be based on 1,073,741,824 (230) per binary GB. The difference between these two values is 7.37% (=(230-109)/109). Therefore a 128 GB SSD with 0% over-provisioning would provide 128,000,000,000 bytes to the user. This initial 7.37% is typically not counted in the total over-provisioning number.
The second level of over-provisioning comes from the manufacturer. This level of over-provisioning is typically 0%, 7%, or 28% based on the difference between the decimal GB of the physical capacity and the decimal GB of the available space to the user. As an example, a manufacturer might publish a specification for their SSD at 100 GB, 120 GB or 128 GB based on 128 GB of possible capacity. This difference is 28%, 7% and 0% respectively and is the basis for the manufacturer claiming they have 28% of over-provisioning on their drive. This does not count the additional 7.37% of capacity available from the difference between the decimal and binary GB.
The third level of over-provisioning comes from end users to gain endurance and performance at the expense of capacity. Some SSDs provide a utility that permit the end user to select additional over-provisioning. Furthermore, if any SSD is set up with an OS partition smaller than 100% of the available space, that unpartitioned space will be automatically used by the SSD as over-provisioning as well. Over-provisioning does take away from user capacity, but it gives back reduced write amplification, increased endurance, and increased performance.
TRIM is a SATA command that enables the operating system to tell an SSD what blocks of previously saved data are no longer needed as a result of file deletions or using the format command. When an LBA is replaced by the OS, as with an overwrite of a file, the SSD knows that the original LBA can be marked as stale or invalid and it will not save those blocks during garbage collection. If the user or operating system erases a file (not just remove parts of it), the file will typically be marked for deletion, but the actual contents on the disk are never actually erased. Because of this, the SSD does not know the LBAs that the file previously occupied can be erased, so the SSD will keep garbage collecting them.
The introduction of the TRIM command resolves this problem for operating systems which support it like Windows 7, Mac OS (latest releases of Snow Leopard, Lion, and Mountain Lion, patched in some cases), and Linux since 2.6.33. When a file is permanently deleted or the drive is formatted, the OS sends the TRIM command along with the LBAs that are no longer containing valid data. This informs the SSD that the LBAs in use can be erased and reused. This reduces the LBAs needing to be moved during garbage collection. The result is the SSD will have more free space enabling lower write amplification and higher performance.
The TRIM command also needs the support of the SSD. If the firmware in the SSD does not have support for the TRIM command, the LBAs received with the TRIM command will not be marked as invalid and the drive will continue to garbage collect the data assuming it is still valid. Only when the OS saves new data into those LBAs will the SSD know to mark the original LBA as invalid. SSD Manufacturers that did not originally build TRIM support into their drives can either offer a firmware upgrade to the user, or provide a separate utility that extracts the information on the invalid data from the OS and separately TRIMs the SSD. The benefit would only be realized after each run of that utility by the user. The user could set up that utility to run periodically in the background as an automatically scheduled task.
Just because an SSD supports the TRIM command does not necessarily mean it will be able to perform at top speed immediately after. The space which is freed up after the TRIM command may be random locations spread throughout the SSD. It will take a number of passes of writing data and garbage collecting before those spaces are consolidated to show improved performance.
Even after the OS and SSD are configured to support the TRIM command, other conditions will prevent any benefit from TRIM. 2010, databases and RAID systems are not yet TRIM-aware and consequently will not know how to pass that information on to the SSD. In those cases the SSD will continue to save and garbage collect those blocks until the OS uses those LBAs for new writes.
The actual benefit of the TRIM command depends upon the free user space on the SSD. If the user capacity on the SSD was 100 GB and the user actually saved 95 GB of data to the drive, any TRIM operation would not add more than 5 GB of free space for garbage collection and wear leveling. In those situations, increasing the amount of over-provisioning by 5 GB would allow the SSD to have more consistent performance because it would always have the additional 5 GB of additional free space without having to wait for the TRIM command to come from the OS.
The SSD controller will use any free blocks on the SSD for garbage collection and wear leveling. The portion of the user capacity which is free from user data (either already TRIMed or never written in the first place) will look the same as over-provisioning space (until the user saves new data to the SSD). If the user only saves data consuming 1/2 of the total user capacity of the drive, the other half of the user capacity will look like additional over-provisioning (as long as the TRIM command is supported in the system).