OpenZFS 2.0リリースの陰でひっそりと、FreeBSD 12.2-RELEASEのZFS実装にSpecial Allocation Class（以下、SACと略すことがある）が追加されていた。
時系列的にはOpenZFS 2.0が2020年12月1日、FreeBSD 12.2Rが10月27日リリースなので、まったく陰ってはないんですけどね、インパクトありそうな機能の割にはリリースノートに記載がなく、zpool statusしたら「プールのアップグレードができるぜ！」と出たので調べてみたら追加されていたという。関連するコミットはこの辺→Rev.354382 Rev.354385 Rev.354941
Special Allocation Class自体はZoL 0.8.0で2019年5月24日にリリースされ、その後、illumosへのバックポートを経て、めでたくFreeBSDに取り込まれた模様。ZFS実装が新生OpenZFSベースに切り替わろうとしている中で、Legacy ZFSをきっちりメンテする姿勢には頭が下がります。
で、肝心のSpecial Allocation Classは何かというと、I/O性能に直結するデータを専用のvdevに格納して性能改善を図るもののようだ。多少正確さを欠く表現だが、階層化ストレージのZFS版といえる。
ZFSはターゲットとするデータの種類によってvdevをAllocation Classという概念で分類し、OpenZFS 2.0時点では以下の5種類のクラスが定義されている。ちなみにAllocation Classの考え方はdRAIDで導入され、その後、開発コミュニティによる汎用化を経て現在の形となったそうだ。
| クラス | SAC | 用途 | 専用vdevを割り当てた時の効果 |
|---|---|---|---|
| Normal | × | 通常のデータを扱うvdev。ミラーとかRAIDZとか。 | |
| Log | × | ZILのレコード。いわゆるSLOG。 | 同期書き込みの高速化 |
| Dedup | ○ | 重複排除テーブル(DDT)のデータ | 重複排除パフォーマンスの向上とDDTのメモリ使用量の削減 |
| Metadata | ○ | プールとファイルシステムのメタデータ | メタデータ操作（ファイル一覧の取得など）パフォーマンスの向上 |
| Small Blocks | ○ | レコードサイズ以下のブロック | 小さなサイズの膨大なI/O性能の改善。詳細は後述 |
表で○を付けたクラスがSpecial Allocation Classとされている。それぞれのSACの役割は名前のごとくで、専用vdev (Special vdev)を割り当てるとそれなりに効果がありそうだ。とりわけSmall Blocksは劇的な性能改善の可能性(PDF)を秘めている。
ZFSのファイルI/Oは原則128KiB単位1)で行われる。それに満たないデータは、より小さなレコードが用いられることとなり、これらの小レコードがI/O性能にそれなりに影響するそうだ。Small Blocksは指定サイズ以下のレコードの読み書きをSpecial vdevにオフロードするような形となる。つまり、Special vdevとしてI/O性能が高いデバイス──要はSSDを割り当てると、その特性を活かして膨大な小規模I/Oを捌けるようになり、全体としてスループット向上が見込めるというワケだ。
ここで注意が必要なのは、Small Blocksの処理はファイルサイズベースではなく、レコードサイズベースで行われるということ。つまり、小さなファイルの全体がSpecial vdevに格納される訳ではない2)。ZFSの書き込みは一旦キャッシュされ、トランザクショングループ（txg）にまとめられた後にレコード単位で書き出されるため、必ずしも小さいファイル＝小さなレコードとは限らない。逆に、大きなファイルでもレコードサイズ以下の端数は必ず存在するわけで、こうしたtxgを経てなおレコードサイズ未満となった分がSpecial vdev行きとなるようだ。このあたりが一般的な階層化ストレージと大きく異なる部分である。
他の階層化ストレージで見られる最頻ファイルをSSD層に配置する、といったことは（現時点では）できないが、ZFSではpL2ARC（とARC）がその役割を担っていると思われる。都度special_small_blocksの値を調整しSpecial vdevへの書き込みを制御してやれば、狙ったファイルをSSDに置くこともできなくはないが……
Small Blocksの対象となるブロックサイズは、レコードサイズ以下の2の冪を任意に指定できる。128KiB超のレコードサイズを許可するlarge_blocksフィーチャーと組み合わせると、よりパフォーマンスチューニングの幅が広がるだろう。なお、FreeBSDはレコードサイズが128KiBを超えるデータセットからの起動には対応してないので要注意。
Special Allocation Classで性能向上が見込める一方で、その仕組み上、Special vdevが死ぬと一発でプール全体のデータが飛ぶ恐れがある、というかメタデータという極めて重要なデータが飛ぶんだから、ほぼ確実に死ぬと思われる（→実際に試して死ぬことを確認）。なので今まで以上に冗長性には留意する必要がある。信頼のおけるSSDで最低でもミラーリング、可能なら電源喪失保護付きSSDで3重ミラーにしたいところ。
Special vdevの容量が一杯になった場合は、従来通り普通のvdevの方が使われるそうなので、その辺は特に気にしなくてもよい模様。
もし試す場合は、プール（普通のvdev）とSpecial vdevのashift量を一致させること。もう修正済みかもしれないが、異なるashiftでプールに追加するとSpecial vdevの取り外せなくなるバグがあるっぽい。ashift量はvdevごとに独立してて、プール作成時は気にするもののvdev追加時はついつい忘れちゃうんだよね…。