ブログのしゅーくりーむ

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

F2FS(Flash-Friendly File System) を試してみる。

このエントリは、 カーネル/VM Advent Calendar 2013 の 19日目の記事として書いています。

こんにちは、 @syu_cream です。 本記事では SSD に特化したファイルシステムであるところのF2FS(Flash-Friendly File System) の軽い説明を入れつつ、試しに使ってみて軽くベンチマークを取ってみた結果を掲載します。

大分ざっくりと書いてるので、誤った点など多々あるかと思います。適当にご指摘頂けると幸いです。

F2FS とは

F2FS(Flash-Friendly File System) は Linux カーネル 3.8 でマージされた、Samsung が中心となって開発した、主にSSDに特化したファイルシステムです。 生のフラッシュメモリ 特化のファイルシステムは、既存のものが幾つか存在するのですが、F2FS はそれらとはまた違った構造のストレージを想定して設計されています。

で、ざっくりと結論を出してしまうと、F2FS は SSDにとって苦手なランダムライト性能を、ログ構造ファイルシステム的なデータの書き出し方をすることで向上する ファイルシステムと言えます。 実際にベンチマークしてみたところ、確かに F2FS の導入によりランダムライト性能が向上する傾向が見られました。

SSD に有効なファイルシステムとは

先述の通り、 F2FS は NANDフラッシュベースのストレージ 、例えばSSDに特化したファイルシステムだと主張されています。 生のフラッシュメモリ特化 のファイルシステムはこれまで幾つか、例えば jffs2 や logfs などが存在するのですが、これらはNANDフラッシュメモリを直接アクセスするような環境で使用されることを想定されています。

さて、NANDフラッシュベースのストレージであるSSDはしかし、ソフトウェアのレイヤから見た時に生のフラッシュメモリではなくハードディスクで使われるようなSATAなどをしゃべるディスクのように振る舞います。 しかしながら、NANDフラッシュメモリはモノからして磁気ディスクとは違うものです。 そのため、配線や材料の特性上、ハードディスクには無い以下のような特徴を持ちます。

  • 読み書きと削除の 粒度が異なる

    • ページ : 読み書きの単位。一般的なSSD なら、4kB~ であることが多い。
    • ブロック : 削除の単位。一般的なSSD なら、1MB~ くらい?
  • メモリセルへの 上書き処理が直接出来ない

    • そのため、まず削除を行う必要がある。巻き込まれるデータは退避させる
    • この処理のコストが大きいため、上書きするような小サイズのランダムライトの性能は出にくい
  • メモリセルに 書込み回数の上限(寿命) が存在する

このように、NANDフラッシュメモリは根本的にハードディスクと違うストレージである(そもそも内部的にはセクタ区切りにされていない!)ため、SSDはファームウェアで実装されている FTL(Flash Translation Layer) によって、これらの特性の隠蔽や改善を行っています。 このFTLは名前通りの変換処理以外にも、以下に挙げるような様々な役割を持っています。

  • セクタ単位のアドレスから、NANDフラッシュメモリに対応する物理アドレスへの変換
  • メモリセル延命のための ウェアレベリング
  • 削除処理の発生を抑制するための使用済みページの ガベージコレクション
  • オーバープロビジョニング(OSには隠された予備領域) を使った性能向上

この辺は Software Design 2013年11月号のFusion-io解説記事 とか、僕が昔書いた資料を読むと良いと思われます(宣伝)

さて、F2FS の話に戻します。 F2FSが謳っている NANDフラッシュベースのストレージ特化 というのは、「FTLがなんか色々勝手に処理しているのを想定した上で的確に振る舞う」ファイルシステムとなります。

F2FS の仕組み

F2FS は以下のような特徴、機能を持つファイルシステムです。 基本的に、ログ構造的な書込み方式を採用しつつ、副次的な問題を抑制することにより書き込み性能を向上するところが大きなメリットであると思われます。

  • LFS(Log-structured File System) 的なデータ書込み方式による、書込み性能の向上
  • LFSのネックを抑制する設計

  • フラッシュメモリの処理単位に合わせたログ書き出し

LFS(Log-structured File System) について


Log-structured File System はパーティション全体を連続した記憶領域として扱います。 LFSへの書込みはその連続した領域に"ログ"として書き残されます。

LFS はディスクへの書込みをシーケンシャルライトで行うため、SSDに導入することでランダムライトの発生を抑制し、性能向上をねらうことができます。 しかしながら、ある程度使い込まれた際に不要になったログを回収(ガベージコレクション)して、新たにログを書き出せる連続した空き領域を作る必要があり、この処理のコストが高い問題があります。

LFSのモダンな実装として、NILFS2 などが挙げられます。

F2FS の工夫


F2FSでは、上記のLFSのようなログ構造的なデータの書き出しを行い、SSDに対して発行されるランダムライトの頻度を低下させる(シーケンシャルライトとして書き出させる)ことにより性能を向上させつつ、LFSのデメリットを解消する工夫がなされています。 ちょっと調べたところ、以下のような特徴があるようです。詳しくはF2FSの紹介スライドなどを参照してみてください。

1. バックグラウンドガベージコレクション

後述のブロック割当のポリシーにもよるのですが、ログのガベージコレクションを基本的にバックグラウンドで行います。

2. ブロック割当のポリシー

ログのガベージコレクション処理は非常にコストのかかる重い処理ですが、これを行わなければ連続した空き領域を確保できずランダムライトが発生してしまいます。 F2FSでは、これを考慮し、ガベージコレクションを行う/行わないポリシーを提供し、デフォルトではこれを状況に応じて使い分けるような挙動をします。 具体的には、通常は以下に挙げる Copy-and-compaction を採用し、空き領域が十分に無い場合には Threaded logging に動的に切り替わります。

3. Hot/Cold データの分離

F2FSでは、データの書き込み頻度の偏りにより、書き出すログをそれぞれ別の場所に分離し、性能向上のためそれぞれフラッシュメモリの処理単位にまとまるように書き出します。 書込み頻度の高いデータの局所性を高めることにより、ガベージコレクションのオーバーヘッドを低減している模様?

F2FS の性能

ここまでの流れから、確かに F2FS でランダムライトの性能を向上できる気がしてきます。 しかしながら、他のファイルシステムと比較して性能がどれくらい伸びるのか、ランダムライト以外の性能はどうなのかという点も気になってきます。

F2FSの性能に関しては、既に幾つかのファイルシステムとの性能比較データがあります。 が、SSDはベンダーや型番により中身が大きくことなるのに合わせ、最近のカーネルだと性能がどうなのかという辺りが気になったので、fio でベンチマークを行い性能比較を行ってみました。

実験環境

ベンチマークを行った環境は以下の通りです。

各項目 詳細
CPU Intel Core i5 760 @ 2.80GHz
Mem 8GB
SSD Intel 320 80GB (ファームウェア最新)
OS Ubuntu 13.10
Kernel 3.12.5 (バニラカーネル)

実験方法

ここでは、fio を用いてベンチマークを行ってみます。 *.fio ファイルは以下の通り記述しました。 各項目については、man を読むなどして確かめてみてください。

ここでは以下の4つのアクセスパターンに絞ってベンチマークを行ってみました。 アクセスパターンは、上の *.fio ファイルの値を適宜修正することで変更しました。

  • シーケンシャルリード
  • シーケンシャルライト
  • 4k ランダムリード
  • 4k ランダムライト

また、ファイルシステムの差異による性能の違いを見たいため、以下のようなファイルシステムを対象にそれぞれベンチマークを回しました。

  • F2FS
  • ext4
  • XFS
  • btrfs
  • btrfs(ssd_spread オプション有効)
  • NILFS2

btrfs については、SSD の最適化をより強化するためのマウントオプション ssd_spread があるようなので、これが有効/無効である場合でそれぞれ測定を行いました。

実験結果

fio による性能測定結果は、以下のグラフの通りになりました。 グラフの縦軸の単位ですが、シーケンシャルリード/ライトは Mbps 単位で、ランダムリード/ライトは IOPS 単位で出しています。

この実験結果から、だいたい次のことが言えるかなと思います。

  • F2FS、本当に性能が出た。特にランダムライトが顕著
  • XFS、btrfs もかなり検討している。

    • ただし、btrfs の ssd_spread オプションによる性能向上は今回は見られなかった
  • NILFS2 の性能があまり出ない・・・何かミスっているだろうか

シーケンシャルリードの性能


ファイルシステム毎の差はほとんど見られない値になりました。

f:id:syu_cream:20131219214953p:plain

シーケンシャルライトの性能


ext4、次いで NILFS2 が性能が落ち、他はほぼ同じくらいの性能となりました。

f:id:syu_cream:20131219215002p:plain

ランダムリードの性能


ext4、btrfs、NILFS2の性能があまり伸びす。 F2FS とXFSの性能が目立ちます。

f:id:syu_cream:20131219215009p:plain

ランダムライトの性能


F2FSが抜きん出て性能が良いです。 次いで btrfs、XFSの性能が目立ちます。

f:id:syu_cream:20131219215017p:plain

さいごに

性能だけ見ると、F2FSは悪くないように思えます。 おそらく、安価でファームウェアがあまり賢く無いSSDに使うには良いかと。導入もそれほど難しくなくお手軽なので。 ただし、実際の運用が楽なのかどうかという点も気になりますね。

最近、SSD自体やSSDをハードディスクのキャッシュとして用いる性能向上手法がやたら出てきて群雄割拠の状態かと思います。 更に、Fusion-io みたいな余計なレイヤ挟まないことにより性能を出すみたいな道も一般化してきていて。。。 F2FSがこの先生きのこるにはどうするか、どうなっていくのか気になってくるところですね。