差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン | ||
blog:2020:2020-12-08 [2020-12-28 11:54] Decomo |
blog:2020:2020-12-08 [2022-03-04 11:37] Decomo |
||
---|---|---|---|
行 9: | 行 9: | ||
で、肝心のSpecial Allocation Classは何かというと、I/ | で、肝心のSpecial Allocation Classは何かというと、I/ | ||
- | ZFSでは扱うデータの種類に応じてvdevをAllocation Classという概念で分類しており、OpenZFS 2.0時点では以下の5種類となっている。ちなみにAllocation Classは、元は[[blog: | + | ZFSはターゲットとするデータの種類によってvdevをAllocation Classという概念で分類し、OpenZFS 2.0時点では以下の5種類のクラスが定義されている。ちなみにAllocation Classの考え方は[[blog: |
^ クラス | ^ クラス | ||
行 18: | 行 18: | ||
| Small Blocks | ○ | レコードサイズ以下のブロック | 小さなサイズの膨大なI/ | | Small Blocks | ○ | レコードサイズ以下のブロック | 小さなサイズの膨大なI/ | ||
- | 表で〇を付けたAllocation ClassがSpecial Allocation Classとされている。それぞれのSACの役割は名前のごとくで、専用vdev (Special vdev)を割り当てるとそれなりに効果がありそうだ。とりわけSmall Blocksは[[https:// | + | 表で○を付けたクラスがSpecial Allocation Classとされている。それぞれのSACの役割は名前のごとくで、専用vdev (Special vdev)を割り当てるとそれなりに効果がありそうだ。とりわけSmall Blocksは[[https:// |
- | ZFSのファイルI/ | + | ZFSのファイルI/ |
- | ここで注意が必要なのは、Small Blocksの処理はファイルサイズベースではなく、あくまでブロックサイズベースで行われるということ。なので、小さなファイルの全体がSpecial vdevに格納される訳ではない((Small Blocksの閾値をレコードサイズと同値にして全データをSpecial vdevに送ることは可能))。そもそも、ZFSの書き込みは一旦メモリにキャッシュされ、トランザクショングループ(txg)にまとめられた上でレコードに書き出されるため、必ずしも小さいファイル=小さなレコードとは限らない。逆に、大きなファイルでもレコードサイズ以下の端数は必ず存在するわけで、これらのtxgでレコードサイズ未満となった分がSpecial vdev行きとなるようだ。この辺が一般的な階層化ストレージと大きく異なる部分である。 | + | ここで注意が必要なのは、Small Blocksの処理はファイルサイズベースではなく、レコードサイズベースで行われるということ。つまり、小さなファイルの全体がSpecial vdevに格納される訳ではない((Small Blocksの閾値をレコードサイズと同値にして全データをSpecial vdevに送ることは可能だが、それなら最初からSSDでプールを組んだ方が良い))。ZFSの書き込みは一旦キャッシュされ、トランザクショングループ(txg)にまとめられた後にレコード単位で書き出されるため、必ずしも小さいファイル=小さなレコードとは限らない。逆に、大きなファイルでもレコードサイズ以下の端数は必ず存在するわけで、こうしたtxgを経てなおレコードサイズ未満となった分がSpecial vdev行きとなるようだ。このあたりが一般的な階層化ストレージと大きく異なる部分である。 |
- | Small Blocksの対象となるブロックサイズは、レコードサイズ以下の2の冪を任意に指定できる。128KiB以上のレコードサイズが使えるようになるlarge_blocksフィーチャーと合わせて使うと、よりパフォーマンスチューニングの幅が広がるだろう。なお、FreeBSDはレコードサイズが128KiBを超えるデータセットからの起動には対応してないので要注意。 | + | 他の階層化ストレージで見られる最頻ファイルをSSD層に配置する、といったことは(現時点では)できないが、ZFSではpL2ARC(とARC)がその役割を担っていると思われる。都度'' |
- | Special Allocation Classで性能向上が見込める一方で、その仕組み上、Special vdevが死ぬと一発でプール全体のデータが飛ぶ恐れがある、というかメタデータという極めて重要なデータが飛ぶんだから、ほぼ確実に死ぬと思われる。なので今まで以上に冗長性には留意する必要がある。信頼のおけるSSDで最低でもミラーリング、可能なら電源喪失保護付きSSDで3重ミラーにしたいところ。 | + | Small Blocksの対象となるブロックサイズは、レコードサイズ以下の2の冪を任意に指定できる。128KiB超のレコードサイズを許可する'' |
+ | |||
+ | Special Allocation Classで性能向上が見込める一方で、その仕組み上、Special vdevが死ぬと一発でプール全体のデータが飛ぶ恐れがある、というかメタデータという極めて重要なデータが飛ぶんだから、ほぼ確実に死ぬと思われる(→[[blog: | ||
Special vdevの容量が一杯になった場合は、従来通り普通のvdevの方が使われるそうなので、その辺は特に気にしなくてもよい模様。 | Special vdevの容量が一杯になった場合は、従来通り普通のvdevの方が使われるそうなので、その辺は特に気にしなくてもよい模様。 |