8月版　SSDをめぐる議論に浮かび上がるベンダ模様

小崎資広
2009/9/8

　お久しぶりです。先月は「セキュリティ＆プログラミングキャンプ2009」の準備があまりにも忙しくて、急きょお休みしてしまった筆者です。

　8月は、2.6.31がリリース間近なこともあり、実験的なパッチの投稿は少なかったように思います。唯一、Jens Axboe（blockレイヤのメンテナ）による矢継ぎ早の超大型パッチの投稿が目立っていましたが、多くの開発者がサマーバケーション中なので、反応はイマイチ。そんな中、SSD周りの議論が強烈に面白い展開をみせていたので、大きく取り上げてみました。来月は、Jensパッチか2.6.31リリースの特集になる予定です。

　それでは、どうぞ。

混迷深めるdiscardリクエスト

■全面書き直しが必要？

　8月15日、Nitin Guptaがswapサブシステムに新しい通知機構の追加を提案、パッチを投稿しました。これが長い長い議論の始まりでした。

　まずHugh Dickinsが「現状のdiscardリクエスト（注1）用のフックが不適切だというならば、なぜそこを修正しないのか。新しいフックが必要なようには見えない」と指摘し、現在のdiscardリクエストの主要デベロッパであるMatthew Wilcoxに意見を求めます。これに対するMatthewの答えは意外なものでした。彼は「discardリクエストを完全に書き直すことを検討している」といい出したのです。

　現在、discardリクエストには、ATAのTRIMコマンドとSCSIのUNMAPコマンドという2つの用途があります。

　1つ目のATAのTRIMコマンドは主にSSDで使われます。未使用となったブロックをデバイスに通知し、SSDコントローラにウェアレベリング（注2）を円滑に動作させるヒントを与えるのです。もう一方のSCSIのUNMAPコマンドはハイエンドエンタープライズストレージ製品のシン・プロビジョニング機能（注3）に使われます。仮想ストレージからファイルが消去されたタイミングで、UNMAPを発行することにより、そのブロックを物理ストレージに返還するのです。

　Matthewによると、不幸なことに、ATAのTRIMコマンドはNCQ（Native Command Queueing）対応コマンドではありません。NCQとは、ホスト側から複数のI/Oリクエストをまとめて発行し、ドライブ側で実際のヘッド位置を加味しながらアウトオブオーダ実行する仕組みです。

　ATA規格ではNCQコマンドと非NCQコマンドの同時発行は許されていません。そこでTRIMコマンドは、

1. すべてのNCQコマンド（read、writeなど）の完了を待つ
2. TRIMを発行する
3. TRIMの完了を待つ
4. 後続のNCQコマンドの発行を再開する

というシーケンスを経る必要があり、I/Oスループットを低下させてしまうそうです。

　よって、結論としてはdiscardはブロックレイヤで一度バッファリングされるべきというのです。そうすることによって前述のNCQ問題を避けることができます。また、すぐさま再利用されたブロックに対してTRIMを発行せずに済み、I/Oスループットの向上も期待できるそうです。

　この変更はUNMAP利用者からすると望ましくありませんが、Matthewは「しかし、圧倒的多数のユーザーはこんなもの持ってないんだから、OSのデザインではこういう少数のベンダの要求は無視すべきだよ」といい添えました。さらに、この修正による性能測定を行いたいので、自分のデスクトップでTRIM対応SSDが使えるようになるのを待っているところである、とも付け加えました。

注1：Linuxが不要ブロックをデバイスに通知するためのフレームワーク。ファイル消去により不要になったブロックをデバイスに通知することにより、デバイスの動作を最適化することができる。 注2：SSDでは書き換え回数に制限があるが、同じ素子ばかりを書き換えないよう書き換えを均等に分散することによって、全体の寿命を延ばす仕組み。 注3：ストレージ仮想化の一形態。実デバイスが持つストレージ容量とOSから見えるボリュームのストレージ容量を分離することにより、実ストレージの増設をOSから不可視にし、運用の柔軟性を上げるテクノロジ。ストレージの購入時期を「必要になったとき」まで遅延できるため、システム構築時に想定最大容量を一括購入するよりもシステムコストが安価になる。

■反対・反対・反対！の大合唱

　もちろん、「無視すべき」などといわれてしまったSCSIデベロッパが黙っているはずもなく、反対の大合唱が始まります。

　James Bottomley（SCSIサブシステムのメンテナ。カンファレンスでいつも司会をしている蝶ネクタイの人として有名）は即座に「エンタープライズの要望を無視するなんて選択はあり得ないよ。でもそれが本当に必要なら、既存の機能を壊さないようなパッチを作って議論できるとハッピーだね」と返します。

　彼は、ATAのTRIMが非NCQなのは規格のミスだと考えているようで（まあ、SCSIはキューイングできるんですから当然の反応ですね）、「規格の方を何とかできないのか」と不満顔。また、NCQをサポートしているSSDなんてほとんどないのに、そんな考慮が本当に必要なの？ と疑問を投げかけました。

■余談

後者については、Ted Ts'oらが現在のSSD製品のNCQ対応状況についてまとめてくれました。彼らによると、 - Intel X25-M 　 NCQを実装した最初のSSD - OCZ Core V2   NCQサポートを喧伝しているけれど、buggyなのでLinuxのATAのblack listで機能を殺されている - “くそったれな”JMicron JMF602 このコントローラを使っているすべてのSSD製品はNCQをサポートしていない - JMicron JMF612   NCQをサポートし、またプチフリーズ問題を解決したとJMicronは主張しているが、私（＝Ted）はJMF612を使った製品をまだ見たことがない - Indilinx controller（OCZ Vertexなど） NCQをサポートしているが、4個以上のNCQ queue depthではスケールしない。これは、Intel SSDがqueue depthを31まで引き上げてもスケールするのとは対照的 という状況のようです。一部、NCQと関係のない私怨が交じっている気がしますが、そこはTedクオリティ、気にしてはいけません。

　また、Jim Owensは、「そもそも現在のLinuxのdiscardの設計は、去年のワークショップでIntelのSSDアーキテクトが『the right thing』といったことをきっかけに、急速に合意に至ったという経緯がある。もしいまの実装でIntel SSDで性能が出ないなら、そいつをオレの代わりにひっぱたいてやってほしいね」と不満をあらわにしながら、もしそういう“まぬけ”ハードが存在することが問題なのであれば、ホワイトリストを作り、まぬけハードにTRIMを発行しないようにすればいい話ではないかと反論しました。

6月版へ

1/2

Index Linux Kernel Watch　8月版 　SSDをめぐる議論に浮かび上がるベンダ模様

Page 1 　混迷深めるdiscardリクエスト 　 Page 2 　少年よ大志を抱け！

連載 Linux Kernel Watch

---

Linux Squareフォーラム Linuxカーネル関連記事

	連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします
	連載：Linuxファイルシステム技術解説 ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する
	特集：全貌を現したLinuxカーネル2.6［第1章］ エンタープライズ向けに刷新されたカーネル・コア ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する
	特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する
	特集：仮想OS「User Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	Linuxのカーネルメンテナは柔軟なシステム カーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）