ブログのしゅーくりーむ

技術的なメモとかライフログとか。

SSD時代のファイルシステム選択について考えてみる

この記事は、カーネル/VM Advent Calendar の、12/28 日目の記事です。

はじめに

ご存知の通り、近年ハードディスクに代わるストレージとして、SSD(Solid-State Drive) が普及してきています。
SSDフラッシュメモリと高性能なコントローラを搭載した、高速にアクセス可能なストレージです。
僕もこの夏、スペックに限界を感じ始めてきたMacBook Pro (13-inch, Mid 2009) にIntel SSD 320 series 80GB を突っ込んでストレスフルな環境から脱出できたり、なかなか助けられています。


しかしながらこのSSD、掘り下げて見ていきますと、ハードディスクとは構造上の差異などが見られ、なかなかクセモノです。
特にディスクI/Oの性能を左右するファイルシステムは、これまでハードディスクを用いる事を前提に最適化されているものが多くありますが、これほどまでにSSDが普及した今、SSD向けに最適化されて然るべきでしょう。
実際に、SSD向けに最適化されていると謳っているファイルシステムも登場してきています。


そこで本稿ではハードディスクとSSDの差異を確認しつつ、SSD向けに最適化されたファイルシステムとはどんなもので、何をしてくれるのかという点にざっくり触れてみようと思います。
残念ながら僕は意識低いので、面白い実装や実験結果などは無しです。ご了承下さい。

ハードディスクとSSDの特徴


ハードディスクの特徴を列挙すると、以下のような感じになるかなと思われます。

  • 記憶媒体は磁気を帯びたディスク。
  • 読み書きを行う際は、高速回転する磁気ディスク上を、磁気ヘッドを駆動して目的のセクタに移動し、磁気的に読み出し/新しい値の上書きを行う。
  • 読み書きが行われる最小単位はセクタ(512バイト )
  • アクセスを行う際、どうしても磁気ヘッドを駆動するシーク時間が発生する。このため、ランダムアクセスの性能低下が顕著。
  • 容量当りのコストが低い(今年は洪水の影響の為、そうとも言えなかったですが・・・)


対してSSDは、以下のような特徴があります。

  • 記憶媒体フラッシュメモリ
  • 読み書きを行う際は、電気的に読み出し/新しい値の注入を行う。
  • 読み書きが行われる最小単位はページ。削除が行われる最小単位はブロック。これらのサイズはモノによって左右される。一般的に ページサイズ < ブロックサイズ。
  • 単純な"上書き処理"ができないという制約が存在(上書きしたい場合、古いデータの削除 → 新しいデータの書込み、が必要)
  • ハードディスクと同様のインタフェースを提供するため、コントローラ内にFTL(Flash Translation Layer ) という抽象化層をもつ。


このように、ハードディスクとSSDではそもそも記憶媒体から違うなど、案外差異があることが分かります。
また、これらのことを踏まえハードディスクとSSDを比較すると、SSDの以下のような利点/欠点が浮かび上がってきます。

  • 利点
    • I/O性能が高い ( 特にランダムアクセス性能 )
    • 省電力
  • 欠点
    • 使い込んでいくと、ランダムライト性能が低下する
    • 寿命が存在 (メモリセル毎に、書込み/削除を行える回数が決まっている)
    • 容量当りのコストが未だ高い(最近は大分ましになってきた)


ランダムライト性能低下については、ページサイズとブロックサイズの違いと、上書き処理が出来ないことに起因しています。
分かり易い解説があるので、そちらをどうぞ。

ファイルシステムレベルの、SSD向け最適化が何をしているか見てみる

Btrfs におけるSSD向けの最適化

これらのSSDの欠点を受け、ファイルシステムでは実際にはどのような対策がされているのでしょうか。
ここでは、ZFSに影響を受けて作られている、SSD向けに最適化をされているというBtrfs が何をやっているのか触れてみます。


Btrfs でSSD向けの最適化を有効にする場合、mount -o マウントオプションで指定してやる必要があります。
指定出来るオプションは2通り存在する模様です。


ssd オプションを指定した場合、Btrfs が持つ自動デフラグを無効にします。またSSD上でなるべく空き領域が分散しないようデータを連続的に書込んでくれる模様です。
ssd_spread オプションを指定した場合は、基本的にssd オプションと同様なのですが、メタデータに関してのみ分散した領域に書込む事を許可します。
これによりSSD上のデータの無い未使用な領域は連続的なものが多くなる傾向になり、使い込んだ時の性能劣化を抑制することが出来ます。

その他のファイルシステムの、SSD向けの対策

Windows で採用されているNTFSでは、trim コマンドのサポートをしています。trim コマンドは、ATA8-ACS で定められているATAコマンドの一種で、SSDに「指定された領域がファイルシステム以上で使用されていない」事を通知する為のコマンドです。これの実行をファイルシステムレベルで判断出来る事により、不要なファイルが削除された際にSSD上からも削除されるので、上書き処理の実行頻度を削減することができ、SSDを使い込んだ時のランダムライト性能の低減を抑えることができます。


LFS(Log-Structured File System) のような、連続的に書込みログを記録していくような仕組みのファイルシステムでは、ランダムライトの発生頻度が低く、書込み性能の低下を抑えることが可能かと思われます。


余談ですが、ioDrive ではボトルネックの一因にもなりうるFTLを取っ払い、ソフトウェアレベルで独自のレイヤを挿入し、FTLでやられているような寿命の延長や性能向上の為の最適化を行ったりしています。
更に独自のファイルシステムと連携し、性能向上を狙う論文があったりします。*1

おわりに

SSDがこれだけ流行ってきているので、やがて従来のファイルシステムでは満足できなくなってくるのかなと思いつつ記事を書きました。
最近ではPCIe SSDが脚光を浴びるようになり、ディスクI/Oが高速化され胸も熱くなりますね〜。
SSDはハードウェア内部でガリガリ最適化されまくっていて、ファイルシステムレベルからは微妙に手を出し難い部分があるかと思われますが、性能向上と延命の為になるべくなら最適なファイルシステムを選択したいですね。


なお、本稿はちょっと内容が薄いので後で加筆修正を加えるかもしれません。
また何か指摘等ございましたら知らせて頂けると幸いです。

*1:http://www.usenix.org/events/fast10/tech/full_papers/josephson.pdf