2012年12月4日火曜日

Deterministic Zeroing TRIMについて

前回の記事では、Trimコマンドの送信を個人で確認する方法ついて説明しました。
気がつくと、数ヶ月かけてTrimがらみの記事を4連発ということになりますが、今回は、前回の記事の補足としてTrimコマンドを受け取ったあとのSSDの動作について、もう少し、突っ込んで説明したいと思います。

Trimコマンドによって取得した論理アドレスに対して、書き込みが発生する前に、読み出しが発生した場合の動作の方法がSSDには2つ準備されています。1つが、前回の記事でも書いた「Read Zero After Trim(以下、RZAT)」。もう1つが、「Deterministic Read After Trim(以下、DRAT)」です。

前者のRZATとは、上記の条件のもとでは文字通りデータとして「0」を返すという仕様です。非対応のSSDは、その時点に書き込まれているデータを対応する物理アドレスから読み出してOSに返します。この場合の動作は、HDDと同じです。

一方、後者のDRATは、上記の条件の場合に必ず同じデータが返ってくることを保証する機能です。この機能に対応したSSDは、Trimコマンドによって取得した論理アドレスに対して書き込みが発生しなければ、必ず同じデータが返ってきますが、非対応の製品は、それが保証されません。

なぜDRATが準備されているかといいますと、SSDでは、Trimコマンドによって取得した論理アドレスのデータの内容が書き込み発生前に変わってしまう可能性があるからです。たとえば、Trimコマンドを受け取った直後は、物理消去ができなくてもGCの発動によって物理消去可能となるケースが考えられます。

この場合、Trimコマンドを受け取った直後のデータは、Trimコマンドを受けとる前と同じです。しかし、物理消去が実行されてしまうとデータの内容は、Trimコマンドを受け取った直後とは異なることになります。つまり、DRAT非対応のSSDでは、Trimコマンドで受け取った論理アドレスのデータが変わってしまう可能性がある(不確定である)ことを示しています。

「不要なデータだからどちらでも良いのでは」と考えられる方もいる思いますが、これは、RAID5/RAID6などの環境においては重要なことです。RAID5やRAID6では、パリティを書き込みますが、ファイルシステム上で削除したデータもそのまま変更されずに残っていることが前提となってパリティが作成されているからです。

しかし、Trimコマンドでは、受け取ったアドレスをどのように利用するかの規定はなく、SSD側が、受け取った情報を自由に利用できます。このため、TrimコマンドによってSSD側で勝手に物理消去が実行されてしまうと、Trimコマンドを受け取った直後と多少時間がたってからでデータの内容が異なってしまうケースがでてきます。これは、RAID5やRAID6にとって非常に都合が悪いということになります。そこで準備されたのが、Trim後もそのアドレスに対して書き込みが発生しなければ、常に同じデータが返ってくることを保証するDRATです。

DRATは、当初ほとんどのSSDが対応していませんでした。Trimで送られてきた論理アドレスのデータを次回書き込みが発生するまで常に同じにしたいなら、Trimコマンド非対応またはTrimコマンドを送らなければよいからです。ですが、これでは、せっかくのTrimコマンドのメリットが全く生かされません。

そこで登場するのが、現在実装が進む「Deterministic Zeroing TRIM」です。これは、Trimコマンドによって取得した論理アドレスに対して、書き込みが発生する前に、読み出しが発生した場合、いついかなる時も必ず「0」を返すという仕様です。この仕様でいけば、ファイルシステム上で削除フラグがたったファイルのデータは常に「0」であるものとしてRAID5/6環境で運用できます。これによって、前述の不都合が解消できるというわけです。

もう少し詳しくDeterministic Zeroing TRIMについて説明します。Deterministic Zeroing TRIMを実装する場合、「0」を返すのは、コントローラーの仕事であってTrimコマンドで送られてきた論理アドレスが、実際に物理消去されているかどうかは関係ありません。これは、Trimコマンドによって受け取った論理アド レスすべてが即時消去を行えるわけではないからです。

NANDメモリの書き込み/読みだしの物理単位はペー ジと呼ばれ、現在のSSDなら8KB程度だと思います。一方、消去は、ページを複数個(128個とか256個)まとめたブロックと呼ばれる単位で行われます。さらに、Trimコマンドで送られてくるのは、論理アドレスですから、512バイト単位ということになります。

これからもわかるように実際の運用においてTrimコマンドで送られてきた論理アドレスが、そう都合よく消去できるわけではないということが容易に想像できます。Windowsは、4KB以下のファイルのアクセスが大半を占めるので、漏れが生じるのは明らかだからです。

このため、Deterministic Zeroing TRIMでは、以下のような流れで処理を行なっていると推測されます。
  1. Trimコマンドを受け取る
  2. SSD内部の管理テーブルにTrimコマンドで送られてきた論理アドレスを登録(フラグを立て)しする。
  3. 読み出しが発生する。
  4. フラグが立てられた論理アドレスだった場合、コントローラが自動的に「0」を返す。それ以外の場合は、通常の読み出しを行いデータを返す。
Deterministic Zeroing TRIMでは、書き込みが発生しない限り、Trimコマンドで通知された論理アドレスのデータは、いついかなる時も必ず「0」で返さなければなりません。これを実現するには、上記のような仕組みの実装が事実上必須だといえます。

ここでまで読んで、あることに気づかれた思われた方がいるのではないでしょうか。そうです。Read Zero After TrimとDeterministic Zeroing TRIMでなにが違うのかということです。
正直、僕も違いがわかりません。

というのも、RZATやDRATの対応、非対応の確認は、ATA IDENTIFY DEVICEコマンドで取得できる情報のWord69、Bit5/Bit14で確認できます。Bit5は、RZATのフラグで、Bit14がDRATのフラグです。それぞれ、「1」がセットされていた場合は対応。「0」の場合は非対応です。

Deterministic Zeroing TRIM用のフラグは準備されていませんので、普通に考えれば、RZATおよびDRATの両方に「1」をセットしておけば、Deterministic Zeroing TRIM対応と考えることができます。このタイプ製品は、僕の知る限り現状、SAMSUNG 840/840Proに加え、Intel SSD 320シリーズがあります。


しかし、Intelの330/335/520シリーズやMicron/CrucialのSSDのように、DRATにのみ「1」がセットされ、RZATは「0(非対応)」となっていますが、データとしては「0」を返してくるような製品もあります。また、Plextor(PLDS)のSSDは、DRAT/RZATの両方に「0」をセットしつつ、実際にはデータとして「0」を返してきます。


前者の場合は、DRATが「1」となっている上で、データとして「0」を返してきているので事実上、Deterministic Zeroing TRIM対応ではないかと思うのですが、なんとも言えません。一方、後者の場合は、DRATが「0」となっていますので、「0」が返ってこないケースがごくまれにあるのかもしれません。だからDRATに「0」がセットしてあると見ることもできます。ちなみに、RZATのみが「1」にセットされた製品を僕は見たことがありません。

というわけで、現状では、実際の動作とセットでみると、ATA IDENTIFY DEVICEコマンドで取得できる情報のフラグの立て方に、メーカー間の解釈の違いが存在しているようにみうけられます。コマンドセット場合、手取り足取りこうしろと細かく規定されているんじゃないかと思われる方が多いと思います。しかし、実際は、結構いい加減です。解釈の違いでフラグの立て方が違うとか、コマンドの挙動が他のメーカーと違うとかいうことは、無いわけではありません。今回のIntel/Micronのケースは、これに当てはまるのではないかと推測しております。

なお、RZAT/DRAT対応/非対応の確認は、Intel SSD Toolboxを使うと簡単です。個人的に調べた結果を掲載しておきますので、参考にしていただけたらと思います。

ModelRZATDRAT実データ
Intel 330/335/520×0データ
Crucial m4×0データ
TOSHIBA THNSNSXXXGBSP(砂芝)××読み出したデータ
SAMSUNG 840/840 Pro0データ
SAMSUNG 830××0データ
Plextor M3P/M5P××0データ

0 件のコメント:

コメントを投稿