memo:test

差分

このページの2つのバージョン間の差分を表示します。

この比較画面にリンクする

両方とも前のリビジョン 前のリビジョン
次のリビジョン 		前のリビジョン
memo:test [2020-12-03 09:33]
Decomo 		memo:test [2020-12-09 09:21]
Decomo 削除
行 1: 行 1:
-27. ZFS Primer+====== ZFSのヤバげな機能Special Allocation ClassがFreeBSD 12.2で対応されてた ======
  
-ZFSは先進的で現代的なファイルシステムで、特に伝統的なUNIXファイルシステムでは利用できなかった機能の提供を目的に設計されました。 +OpenZFS 2.0リリースの陰でひっそりと、FreeBSD 12.2-RELEASEのZFS実装にSpecial Allocation Class（以下、SACと略すことがある）が追加されていた。
-オリジナルはSunにおいてソースのオープン化の意向とともに開発されたため、他のオペレーティングシステムへ移植することが可能でした。 +
-OracleによるSunの買収後、ZFSのオリジナル開発者の何人かが、オープンソースバージョンの継続的な共同開発を提供するために[[http://open-zfs.org/wiki/Main_Page|OpenZFS]]を創設しました。+
  
-ここにZFSの特徴の概要を記します：+時系列的にはOpenZFS 2.0が2020年12月1日、FreeBSD 12.2Rが10月27日リリースなので、まったく陰ってはないんですけどね、インパクトありそうな機能の割にはリリースノートに記載がなく、''zpool status''したら「プールのアップグレードができるぜ！」と出たので調べてみたら追加されていたという。関連するコミットはこの辺→[[https://svnweb.freebsd.org/base?view=revision&revision=354382|Rev.354382]] [[https://svnweb.freebsd.org/base?view=revision&revision=354385|Rev.354385]] [[https://svnweb.freebsd.org/base?view=revision&revision=354941|Rev.354941]]
  
-**ZFSはトランザクションを持つCopy-On-Write ([[https://en.wikipedia.org/wiki/ZFS#Copy-on-write_transactional_model|COW]])なファイルシステムです。** +Special Allocation Class自体は[[https://github.com/openzfs/zfs/releases/tag/zfs-0.8.0|ZoL 0.8.0]]で2019年5月24日にリリースされ、その後、illumosへのバックポートを経て、めでたくFreeBSDに取り込まれた模様。ZFS実装が新生OpenZFSベースに切り替わろうとしている中で、Legacy ZFSをきっちりメンテする姿勢には頭が下がります。
-各書き込み要求について、関係するディスクブロックのコピーが作られ、そして全ての変更は元のブロックではなくコピーに対して作用します。 +
-書き込みが完了すると、全てのブロックポインタの指す先がその新しいコピーに変更されます。 +
-これは、ZFSは常に空き領域に書き込み、ほとんどの書き込みはシーケンシャルで、そして古いバージョンのファイルは新バージョンの書き込みが完全に成功するまで分離されないことを意味します。 +
-ZFSはディスクへの直接アクセスを行い、複数の読み込み/書き込み要求をトランザクションにまとめます。 +
-ほとんどのファイルシステムはこれを行わず、ただディスクブロックへアクセスするのみです。 +
-完了か失敗どちらか一方に定まるトランザクションは、[[https://blogs.oracle.com/bonwick/raid-z|ライトホール]]は決して存在せず、そしてファイルシステムの確認ユーティリティは必要ないことを意味します。 +
-このトランザクションベースの設計により、追加のストレージ領域が足されれば、それはすぐさま書き込み用に利用可能となります。 +
-データの再均衡化のために、データをコピーして既存のデータを全ての利用可能なディスクに横断的に上書きすることができます。 +
-128ビットファイルシステムなので、ファイルシステムとファイルの最大サイズは16エクサバイトです。+
  
-**ZFSは自己修復ファイルシステムとして設計されました。** +で、肝心のSpecial Allocation Classは何かというと、I/O性能に直結するデータを専用のvdevに格納して性能改善を図るもののようだ。多少正確さを欠く表現だが、階層化ストレージのZFS版といえる。
-ZFSはデータを書くたびに、対象のディスクブロックごとにチェックサムを生成し記録します。 +
-ZFSはデータを読むたびに、対象のディスクブロックごとのチェックサムを読み込み検証します。 +
-メディアのエラーや“ビット腐敗”はデータに変化を引き起こし、そのチェックサムが一致することはありません。 +
-ZFSがミラーないしRAIDZ構成のプール上にディスクブロックのチェックサムエラーを検出した場合、ZFSは壊れたデータを正しいデータで置き換えます。 +
-滅多に読まれないディスクブロックもあることから、定期的なscrubをスケジューリングし、ZFSが全データブロックを読んでチェックサムの検証と異常ブロックの訂正が行えるようにすると良いでしょう。 +
-冗長性とデータ訂正の提供のために複数のディスクが要求される一方で、1ディスクのシステムにおいてもZFSはデータ異常検出を提供します。 +
-FreeNAS®は各ZFSプールに対し月1回のscrubを自動的にスケジュールし、その結果は[[https://www.ixsystems.com/documentation/freenas/11.3-U5/storage.html#pools|Pools]]を選択し (Settings)→Statusとクリックすると表示されます。 +
-scrub結果をチェックすることは、ディスクの潜在的な問題の早期発見につながる可能性があります。+
  
-伝統的なUNIXファイルシステムと違い、**ファイルシステム作成時にパーティションサイズを決める必要はありません。** +ZFSでは扱うデータの種類に応じてvdevをAllocation Classという概念で分類しており、OpenZFS 2.0時点では以下の5種類となっている。ちなみにAllocation Classは、元は[[blog:2020:2020-10-07|dRAID]]で導入されたもので、その後、開発コミュニティによって汎用化され現在の形となったそうだ。
-代わりに、vdevと呼ばれるディスクのグループがZFSプールに組み込まれます。 +
-ファイルシステムは必要に応じて、そのプールから生成されます。 +
-より多くの容量が必要になった時は、同一のvdevをプールにストライピングすることができます。 +
-FreeNAS®の[[https://www.ixsystems.com/documentation/freenas/11.3-U5/storage.html#pools|Pools]]はプールの作成と拡張に使われます。 +
-プールの作成後、必要に応じて、プールから動的サイズのデータセットまたは固定サイズのzvolを切り出すことができます。 +
-データセットを用い、格納されるデータの種類に応じたパーミッションや容量制限・圧縮といったプロパティをデータセット単位で設定し、ストレージを最適化することができます。 +
-zvolは本質的には生の仮想ブロックデバイスで、iSCSIデバイスエクステントなどのローデバイスを必要とするアプリケーションで使用されます。+
  
-**ZFSはリアルタイムデータ圧縮をサポートします。** +^  クラス  ^  SAC  ^  用途  ^  専用vdevを割り当てた時の効果  ^ 
-ブロックがディスクに書き込まれたときに圧縮が行われますが、そのデータが圧縮の恩恵を受けられる場合に限ります。 +| Normal |  ×  | 通常のデータを扱うvdev。ミラーとかRAIDZとか。 | | 
-圧縮済みブロックにアクセスがあった時は、自動的に展開されます。 +| Log |  ×  |ZILのレコード。いわゆるSLOG。 | 同期書き込みの高速化 | 
-圧縮はファイルレベルではなくブロックレベルで行われるため、あらゆるアプリケーションが透過的に圧縮データにアクセスします。 +| Dedup |  ○  |重複排除テーブル(DDT)のデータ | 重複排除パフォーマンスの向上とDDTのメモリ使用量の削減 | 
-FreeNAS®バージョン9.2.1以降で作られたZFSプールは、推奨のLZ4圧縮アルゴリズムを使います。+| Metadata |  ○  | プールとファイルシステムのメタデータ | メタデータ操作（ファイル一覧の取得など）パフォーマンスの向上 | 
 +| Small Blocks |  ○  | レコードサイズ以下のブロック | 小さなサイズの膨大なI/O性能の改善。詳細は後述 |
  
-**ZFSは低コストの即時スナップショットを提供します。**対象となるのはプール、データセット、あるいはzvolです。 +表で〇を付けたAllocation ClassがSpecial Allocation Classとされている。それぞれのSACの役割は名前のごとくで、専用vdev (Special vdev)を割り当てるとそれなりに効果がありそうだ。とりわけSmall Blocksは[[https://www.napp-it.org/doc/downloads/special-vdev.pdf|劇的な性能改善の可能性]](PDF)を秘めている。
-COWのおかげで、スナップショットは最初は余分な領域を必要としません。 +
-スナップショットのサイズは時間とともに、スナップショットに含まれるファイルがディスクに書き込まれ、変更があるにつれ増加します。 +
-スナップショットを使うと、スナップショットを取得した時点のデータのコピーを提供することできます。 +
-通常、ファイルが削除されると対応するディスクブロックは空きリストに追加されます。しかし、スナップショット内にファイルが存在する場合、参照するすべてのスナップショットが削除されるまで、ファイルブロックが空きリストに追加されることはありません。 +
-これにより、スナップショットはファイルの履歴の保持、古いコピーや削除されたファイルの復元に便利な賢い手段となります。 +
-こうした理由で, 多くの管理者は頻繁にスナップショットを取得し、一定期間保存し、そして別のシステムに保管します。 +
-このような戦略は、管理者にシステムを特定の時点へロールバックすることを可能とします。 +
-もし破滅的なデータ消失があった場合、オフサイトのスナップショットはシステムを最後の定期スナップショット─例えばデータ消失の直前15分の時点に、システムを復元することができます。 +
-スナップショットはローカルに保管されますが、リモートのZFSプールにレプリケートすることもできます。 +
-レプリケーションでは、ZFSはバイト単位のコピーは行わず、代わりにスナップショットをデータストリームへ変換します。 +
-この設計は、受信側のZFSプール構成が同一である必要はなく、異なるRAIDZレベル、プールサイズ、あるいは圧縮設定が使用可能なことを意味します。+
  
 +ZFSのファイルI/Oは原則的に128KiB単位((データセット毎にrecordsizeプロパティで変更可能))で行われ、それに満たないデータは、より小さなレコードが使われる。この小さなレコードがI/O性能にそれなりに影響するようで、Small Blocksは指定サイズ以下のブロックの読み書きをSpecial vdevにオフロードするようなイメージとなる。つまり、Special vdevとしてSSDを割り当てると、その特性を活かして膨大な小規模I/Oを捌けるようになる、というわけだ。
  
-**ZFS Boot Environemtはシステム更新の失敗から復旧する手段を提供します。** +ここで注意が必要なのは、Small Blocksの処理はファイルサイズベースではなく、あくまでブロックサイズベースで行われるということ。なので、小さなファイルの全体がSpecial vdevに格納される訳ではない((Small Blocksの閾値をレコードサイズと同値にして全データをSpecial vdevに送ることは可能))。そもそも、ZFSの書き込みは一旦メモリにキャッシュされ、トランザクショングループ（txg）にまとめられた上でレコードに書き出されるため、必ずしも小さいファイル＝小さなレコードとは限らない。逆に、大きなファイルでもレコードサイズ以下の端数は必ず存在するわけで、これらのtxgでレコードサイズ未満となった分がSpecial vdev行きとなるようだ。この辺が一般的な階層化ストレージと大きく異なる部分である。
-FreeNAS®では、アップグレードやシステム更新の前に、OSが存在するデータセットのスナップショットが自動取得されます。 +
-この保存済みBoot Environmentは自動的にGRUBブートローダに追加されます。 +
-万が一、アップグレードや設定変更が失敗したら、単にシステムを再起動し起動メニューから以前のBoot Environmentを選択します。 +
-ユーザーは必要に応じて、例えば設定変更を行う前にSystem ➞ Bootで自身のBoot Environmentを作ることもできます。+
  
-**ZFSはライトキャッシュを提供します。**オンメモリキャッシュとZFSインテントログ(ZIL)があります。 +Small Blocksの対象となるブロックサイズは、レコードサイズ以下の2の冪を任意に指定できる。128KiB以上のレコードサイズが使えるようになるlarge_blocksフィーチャーと合わせて使うと、よりパフォーマンスチューニングの幅が広がるだろう。なお、FreeBSDはレコードサイズが128KiBを超えるデータセットからの起動には対応してないので要注意。
-ZILは、[[https://pthree.org/2013/04/19/zfs-administration-appendix-a-visualizing-the-zfs-intent-log/|「同期書き込み」を、ZFSプールに書き込まれるまで一時的に保持する]]ストレージ領域です。 +
-高速（低遅延）で電源保護されたSSDをSLOG (Separate Log)デバイスとして追加すると、はるかに高い性能を得られます。 +
-これはESXi越しのNFSに不可欠で、またデータベースサーバや同期書き込みに依存する他のアプリケーションで強く推奨します。 +
-SLOGの恩恵と使い方の詳細は、以下のブログとフォーラムの投稿をご覧ください：+
  
-  * [[http://www.freenas.org/blog/zfs-zil-and-slog-demystified/|The ZFS ZIL and SLOG Demystified]] +Special Allocation Classで性能向上が見込める一方で、その仕組み上、Special vdevが死ぬと一発でプール全体のデータが飛ぶ恐れがある、というかメタデータという極めて重要なデータが飛ぶんだから、ほぼ確実に死ぬと思われる。なので今まで以上に冗長性には留意する必要がある。信頼のおけるSSDで最低でもミラーリング、可能なら電源喪失保護付きSSDで3重ミラーにしたいところ。
-  * [[https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/|Some insights into SLOG/ZIL with ZFS on FreeNAS®]] +
-  * [[http://nex7.blogspot.com/2013/04/zfs-intent-log.html|ZFS Intent Log]]+
  
-SMB、AFP、iSCSIでは同期書き込みは比較的まれで、すなわち、これらプロトコルの性能改善のためのSLOG追加は特別な場合のみであると意味します。 +Special vdevの容量が一杯になった場合は、従来通り普通のvdevの方が使われるそうだ。
-システムがSLOGの恩恵を受けられるかの判定のため、zilstatユーティリティをShellで実行することができます。 +
-使い方の情報は[[http://www.richardelling.com/Home/scripts-and-programs-1/zilstat|このウェブサイト]]をご覧ください。+
  
-現在のところZFSはSLOG用に16GiBの領域を使います。 +そのうち試してみたい。
-より大きなSSDを組み込んでも、余分な領域は使用されません。 +
-SLOGデバイスはプール間で共有できません。 +
-それぞれのプールは別々のSLOGデバイスを要求します。 +
-帯域とスループットの制約により、SLOGデバイスはこの単一目的のためだけに使用されなければなりません。 +
-同一のSSDに他のキャッシュ機能を追加しようとしてはなりません。さもないと性能を損なうことになるでしょう。 +
- +
-ミッションクリティカルなシステムでは、ミラー構成のSLOGデバイスを強く推奨します。 +
-ミラー構成のSLOGデバイスはZFSバージョン19以前のZFSプールで要求されます。 +
-ZFSプールのバージョンはShellで''zpool get version プール名''コマンドで確認します。 +
-バージョン番号が「-」の場合、そのZFSプールは（Feature Flagとしても知られる）バージョン5000かそれ以降を意味します。 +
- +
-**ZFSはリードキャッシュを提供します。**ARCとして知られる読み込みレイテンシを削減するオンメモリキャッシュです。 +
-FreeNAS®はARCの状態をtop(1)に追加し、またARCの効率をモニタリングするためのarc_suymmary.pyとarcstat.pyツールを含みます。 +
-SSDを専用キャッシュデバイスとして使う場合、それはL2ARCとして知られています。 +
-追加の読み込みデータはL2ARCにキャッシュされ、ランダム読み込み性能を向上させます。 +
-L2ARCは（ZFSにおける）十分なメモリの必要性を低減するものではありません。 +
-事実、L2ARCは機能するのにメモリを必要とします。 +
-ARC用に必要十分なメモリがない場合、L2ARCを追加しても性能は増加しません。 +
-実際のところ、殆どの場合で性能が低下し、潜在的にシステムの不安定性を引き起こします。 +
-RAMは常にディスクより速いので、システムがL2ARCデバイスからの恩恵を享受できるかどうかを考える前に、まずは可能な限りのRAMを追加します。 +
- +
-アプリケーションがデータセットに対し、L2ARCに十分に収まるサイズ程度の膨大な量のランダム読み込みを行う場合、専用キャッシュデバイスの追加によって読み込み性能が向上する可能性があります。 +
-SSDキャッシュデバイスは、活きているデータ量がシステムRAMより大きく、かつSSDの大きさに対し十分に小さい場合にのみ有効に働きます。 +
-原則として、32GiBのRAMより小さなシステムにL2ARCを追加するべきではなく、L2ARCの大きさはRAM量の10倍を超えるべきではありません。 +
-幾つかのケースにおいて、2つの別々のプールを持つ方が効率的かもしれません：1つはアクティブデータ用としてSSDに、そしてもう1つは稀に使われるコンテンツ用としてHDDに。L2ARCデバイスの追加後、arcstatなどのツールでその効率を監視します。 +
-既存のL2ARCのサイズを増やすには、別のキャッシュデバイスを取り付けストライピングします。 +
-ウェブインタフェースからは、L2ARCをミラーではなく常にストライピングで追加します。そして、L2ARCの内容は起動のたびに再生成されます。 +
-プールのL2ARCを構成する個々のSSDの障害はプールの整合性に影響しませんが、読み込み性能にインパクトを与える可能性があり、これはワークロードおよびデータセットサイズとキャッシュサイズの比率に依存します。 +
-専用L2ARCデバイスはZFSプール間で共有できないことに留意してください。 +
- +
-**ZFSは冗長性を提供すると同時にハードウェアRAIDに内在する幾つかの問題に取り組むよう設計されました。**その問題とは、ライトホール問題とハードウェアコントローラが警告を出す前に、書き込まれたデータが時間とともに壊れる問題です。 +
-ZFSは3レベルの冗長性を提供し、それはRAIDZとして知られ、そしてRAIDZの後ろの数値はデータを保ったまま失うことのできるvdevあたりのディスク数を示します。 +
-ZFSはミラー構成にも対応し、ミラー中のディスク数に制限はありません。 +
-ZFSは一般品のディスク向けに設計されたため、RAIDコントローラは必要ありません。 +
-ZFSをRAIDコントローラとともに使うこともできますが、ZFSはディスクの全制御を行うため、コントローラをJBODモードにすることを推奨します。 +
- +
-使用するZFS冗長性の種類を決定する際、ゴールはディスク容量の最大化なのか性能の最大化なのかを考えます： +
- +
-  * RAIDZ1はディスク容量を最大化し、一般的に大きなチャンク（128KB以上）のデータの読み書きの時に良く機能します。 +
-  * RAIDZ2はRAIDZ1よりも良いデータ可用性と有意に良好な平均データ消失時間(MTTDL)を提示します。 +
-  * ミラーリングはディスク容量をより消費しますが、一般的に小さなランダムリードでより良く機能します。より良い性能のためには、あらゆるRAIDZよりミラーを強く推奨します。巨大で、キャッシュ不可能なランダムリードの負荷ではなおさらです。 +
-  * vdevあたり12を超えるディスクの利用は非推奨です。vdev毎の推奨ディスク数は3～9です。より多くのディスクを扱う場合は、複数のvdevを使ってください。 +
-  * 古いZFSドキュメントのなかには、最適性能の達成のため各RAIDZタイプごとに特定数のディスクを推奨しているものがあります。LZ4圧縮を使うシステムにおいて、これには標準のFreeNAS® 9.2.1以降も含まれますが、もはや真実ではありません。詳細は[[https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz|ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ]]をご覧ください。 +
- +
- +
-以下の情報源も、特定のストレージ要求に対する最適なRAID設定の選定に役立つでしょう： +
- +
-  * [[https://forums.freenas.org/index.php?threads/getting-the-most-out-of-zfs-pools.16/|Getting the Most out of ZFS Pools]] +
-  * [[https://constantin.glez.de/2010/06/04/a-closer-look-zfs-vdevs-and-performance/|A Closer Look at ZFS, Vdevs and Performance]] +
- +
-<note warning>警告 +
- +
-__ +
-RAIDとディスク冗長化は、信頼あるバックアップ戦略の代わりではありません。 +
-悲運に見舞われた時、価値あるデータを守るために善きバックアップ戦略が依然として求められます。 +
-__ +
-[[https://www.ixsystems.com/documentation/freenas/11.2/tasks.html#periodic-snapshot-tasks|Periodic Snapshot Tasks]]と[[https://www.ixsystems.com/documentation/freenas/11.2/tasks.html#replication-tasks|Replication Tasks]]を見て、バックアップ戦略の一部として複製されたZFSスナップショットを使ってください。 +
-</note> +
- +
-**ZFSはデバイスを管理します。** +
-ミラーやRAIDZの構成デバイスに障害が発生しユーザーによって交換された時、ZFSは置き換えられたデバイスをvdevに追加し、resilveringと呼ばれる処理の中で冗長データを新デバイスにコピーします。 +
-ハードウェアRAIDコントローラは、通常、どのブロックが使われているかを知る術がないため、全てのブロックを新デバイスにコピーしなければなりません。 +
-ZFSは使用中のブロックだけをコピーするので、vdevの再構築時間を削減します。 +
-Resilveringは中断可能でもあります。 +
-中断後、resilveringは最初から開始するのではなく、中断した部分から再開します。 +
- +
-ZFSは多くの恩恵を提供する一方、いくつかの注意点があります： +
- +
-  * 容量の90%に達すると、ZFSは最適化戦略を性能ベースから空間ベースへと切り替えます。これは性能に関して大変な意味合いを持ちます。最大書き込み性能とドライブ置き換え時の問題を防ぐために、プールの使用率が80%に達する前に容量を増やしてください。 +
-  * vdevあたりの使用ディスク数を考える時、そのディスクのサイズとvdevの再構築処理であるresilveringに要する時間を考慮します。大きなサイズのvdevは、それだけresilveringが長くなります。RAIDZ内のディスクを置き換える場合、resilvering処理の完了前に別のディスクが故障する可能性があります。故障ディスクの数がRAIDZの種類によって決まるvdevあたりの耐障害数を超えると、そのプールのデータは失われます。この理由により、1TiB以上のドライブでRAIDZ1はおすすめしません。 +
-  * vdevを作成する場合、使用するドライブの容量を合わせることを推奨します。ZFSは異なる容量のドライブでvdevを作成できるものの、vdevの容量は最小のディスクの容量によって制限されます。 +
- +
- +
-ZFS入門者にとって、WikipediaのページはZFSの特徴をより知るための素晴らしい出発地点を提供します。 +
-参考までに、以下の情報源も有益です： +
- +
-  * [[https://wiki.freebsd.org/ZFSTuningGuide|FreeBSD ZFS Tuning Guide]] +
-  * [[https://docs.oracle.com/cd/E19253-01/819-5461/index.html|ZFS Administration Guide]] +
-  * [[https://www.youtube.com/watch?v=tPsV_8k-aVU|Becoming a ZFS Ninja Part 1 (video)]] と [[https://www.youtube.com/watch?v=wy6cJRVHiYU|Becoming a ZFS Ninja Part 2 (video)]] +
-  * [[https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/zfs.html|The Z File System (ZFS)]] +
-  * [[https://www.youtube.com/watch?v=aTXKxpL_0OI&list=PL5AD0E43959919807|ZFS: The Last Word in File Systems - Part 1 (video)]] +
-  * [[https://www.youtube.com/watch?v=ptY6-K78McY|The Zettabyte Filesystem]] +
- +
-27.1. ZFS Feature Flags +
- +
-OracleのZFSバージョン番号との識別のため、OpenZFSは機能フラグ(feature flags)を使います。 +
-機能フラグは、異なるプラットフォーム上で動くOpenZFS実装同士の移植性を保つため、一意の名前を機能にタグ付けするのに用いられ、ZFSプールの全ての機能フラグ +
-FreeNAS®はOpenZFSを採用し、 +
- +
-To differentiate itself from Oracle ZFS version numbers, OpenZFS uses feature flags. Feature flags are used to tag features with unique names to provide portability between OpenZFS implementations running on different platforms, as long as all of the feature flags enabled on the ZFS pool are supported by both platforms. FreeNAS® uses OpenZFS and each new version of FreeNAS® keeps up-to-date with the latest feature flags and OpenZFS bug fixes. +
- +
-See zpool-features(7) for a complete listing of all OpenZFS feature flags available on FreeBSD.+
  
 +===== 参考サイト =====
  
 +  * [[https://github.com/openzfs/zfs/pull/5182|Metadata Allocation Classes by don-brady · Pull Request #5182 · openzfs/zfs · GitHub]]
 +  * [[https://docs.google.com/presentation/d/17nYRgs-TAIOPODOMaq-VwuJ0LqJHEXBfM9sUDxJUJ54|Pool Allocation Classes - 5182]]
 +  * [[https://forums.servethehome.com/index.php?threads/zfs-allocation-classes-special-vdev.28862/|ZFS Allocation Classes / Special VDEV | ServeTheHome Forums]]
 +  * [[https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954|ZFS Metadata Special Device: Z - Wikis & How-to Guides - Level1Techs Forums]]
 +  * [[https://zfs.datto.com/2017_slides/brady.pdf|Using Allocation Class]](PDF)
 +  * [[https://www.napp-it.org/doc/downloads/special-vdev.pdf|Allocation Classes Feature - Benchmarks and use case on OmniOS]]