OpenZFS の新しいバージョンがリリースされるたびに、管理者と愛好家の間で常に同じ疑問が生じます。 できるだけ早くアップデートするべきでしょうか、それともすべてがよりスムーズに実行されるまで待つべきでしょうか? 2.4ブランチでは、この疑問はさらに興味深いものになります。なぜなら、これは単なるメンテナンスパッチではなく、パフォーマンス、スペース管理、そしてハイブリッドプール向けの高度な機能において飛躍的な進歩を遂げているからです。さらに、リリース候補版（RC）に関しては、特にFreeBSDなどのシステムとの統合に関して、コミュニティ内で議論が交わされてきました。
この記事では冷静に振り返ります OpenZFS 2.4.1の最も注目すべき新機能これには、Windows と macOS 向けの具体的な変更、リリース候補版のステータス、そしてすぐには目に見えないものの、本番環境では大きな違いをもたらす内部的な改善点などが含まれます。Linux、FreeBSD、TrueNAS サーバーを管理している方、あるいは Windows や macOS への移植に苦労している方は、アップグレードを評価するために必要な情報がすべてここにあります。
OpenZFS 2.4.1 と Windows における具体的な変更点
ラベル zfswin-2.4.1rc1 これには、ブランチ2.4.1をWindows環境に適応させることが含まれており、特に以下の点に重点を置いています。 ハイブリッドプールと特別なvdevこれにより、特別な vdev がパフォーマンスの主要コンポーネントとなり、一歩前進します。
このバージョンでは、 特別なvdevはSLOGとして動作できる 同期書き込み用のZFSインテントログ（ZFS Intent Log）です。これにより、メタデータや小さなブロックだけでなく、同期操作を一元管理するために高速SSDやNVMeドライブを活用できるようになります。これは、即時書き込みコミットに依存するデータベースやメッセージングシステムなどのワークロードに特に役立ちます。
また、 ハイブリッドプール フラッシュ ディスクとメカニカル ディスクの組み合わせを最大限に活用するように設計できるため、IOPS 要件が高い Windows 環境の効率が向上します。
もう一つの関連する変更は、 特別なvdevはファイルシステムのメタデータを保存します小さなブロックサイズの設定に応じて、データセット内のすべてのファイル、小さなファイル、またはすべてのファイルがブロックされます（special_small_blocksブロックサイズが0の場合、メタデータのみが保存されます。サイズがファイルサイズより小さい場合、小さなファイルは特別なvdevに保存されます。 recsize それがしきい値以下の場合、ファイルシステム内のほぼすべてのファイルがプールの高速部分に配置される可能性があります。
その柔軟性を次のようなツールと組み合わせることで ZFSの書き換え可能です 機械式ドライブとフラッシュドライブ間でデータを移動する ユーザー空間へのコピーは不要です。小さな書き込みのランダムパフォーマンスが重要となるWindows環境では、特殊な仮想デバイスでのzvol、フラッシュ経由のSLOG、そして再書き込みによるデータの再配置を組み合わせることで、高度に調整されたハイブリッドアーキテクチャの設計が可能になります。
OpenZFS on Windowsチームは、 オペレーティングシステムの特異性 （マウント、ファイルロック、サードパーティ製ドライバとの統合、ウイルス対策など）は、LinuxやmacOSよりも様々なハードウェアで大幅に多くのテストを必要とします。そのため、リリース候補版ごとに、新しい問題と2.3ブランチから引き継がれた問題の両方をGitHubで報告することを推奨しています。これは、Windows版をmacOS版と同等の成熟度にできるだけ早く到達させることを目指しています。
デフォルトのクォータと新しいスペース管理機能
日常生活で最も歓迎すべき変化の一つは、 事前に定められた割り当てを定義する ユーザー、グループ、プロジェクトごとに設定できます。これまで、マルチユーザー環境で使用制限を割り当てるには、ケースバイケースのアプローチが必要でしたが、OpenZFS 2.4では、データセットごとにデフォルトのポリシーを設定できるようになりました。
これにより、例えば、 すべてのユーザーの基本料金 これらの制限は特定のファイルシステム内で作成されるか、新しいリソースが割り当てられる際に標準のプロジェクト境界が自動的に適用されます。これは、不注意なユーザーや設定ミスのあるサービスによって問題が発生するのを防ぐことを目的としています。 プール全体を満たす 驚いたことに。
これらのデフォルトのクォータは既存の特定のルールを置き換えるものではなく、 これらは世界政策として互いに補完し合っている基本設定から始めて、特定のユーザーまたはグループに対して例外を定義し、必要に応じて微調整することができます。これらはすべて標準のZFSプロパティを使用して管理されるため、プロパティモデルに既に慣れているユーザーは、全く新しいインターフェースを習得する必要はありません。
ダイレクトI/O、キャッシュレスIO、およびミスアライン書き込み
パフォーマンスの面では、OpenZFS 2.4は、管理に非常に興味深い変更を導入しています。 直接I/O不整列な書き込みが使用されるシナリオでは、O_DIRECT を使用すると非効率的なコード パスがトリガーされる可能性があります。
これを解決するために、Direct I/Oを理想的に適用できない場合に、 軽量のキャッシュレスI/Oモードへのフォールバックこの代替パスは、パフォーマンスを必要以上に低下させることなく、問題のある書き込みを処理するように特別に設計されています。
これは実際には何を意味するのでしょうか？ 整合アクセスポイントと非整合アクセスポイント これらは、I/Oスタックのボトルネックを引き起こすような病的なケースではなくなります。特にデータベース、仮想化エンジン、または集中的な直接I/Oを伴うサービスを提供するシステムでは、動作がより予測可能で安定します。
統合割り当てスロットリングと断片化削減
もう一つの大きな変化は、目に見えないものの、 統合割り当てスロットリングその目的は、システムの書き込み圧力が高いときにブロック割り当てをより適切に管理し、vdev の断片化を減らし、より整理されたスペース割り当てを維持することです。
これまで、特定のワークロードでは、vdevファイルに非常に大きな書き込みパターンを残す書き込みパターンを排除するのは比較的容易でした。 断片化されており管理が難しい 長期的には、この統合アルゴリズムによって割り当て率が調整され、プールがいっぱいになったときや、さまざまなブロック サイズが混在しているときに、より安定した動作が実現します。
この最適化は特に 長期プール長年にわたり、仮想デバイスは拡張され、スペースのバランス調整、スクラブの実行、デバイスの追加、そしてワークロードの変化に対応してきました。よりスマートな割り当てメカニズムにより、プールが初日ほど「クリーン」ではなくなった場合でも、ZFSは良好な応答時間を維持できます。
AVX2とAES-GCMによる暗号化の改善
セキュリティとパフォーマンスの面では、OpenZFS 2.4は暗号化の実装を改善し、 AES-GCM の AVX2 命令をより有効に活用するこのプロジェクトでは、BoringSSL の実装を参考にして、このコードを最新の CPU、特に AMD Zen 3 などのアーキテクチャ上で最適化しました。
結果は パフォーマンスの大幅な向上 （特定のシナリオでは最大80%の改善が報告されています）これにより、暗号化によるCPUへの影響が軽減されます。この最適化は、大量の暗号化データを保存したり、暗号化されたデータセットに対して多数の同時操作を実行したりするシステムで特に顕著です。
実際には、これにより ZFSネイティブ暗号化は「安価」無料にはなりませんが、以前のバージョンのような大きなボトルネックではなくなり、これまでセキュリティとパフォーマンスの間でトレードオフがあった環境での導入が容易になります。
特殊な vdev と拡張された special_small_blocks の ZIL
の管理 特別なvdev これはOpenZFS 2.4が興味深い飛躍を遂げたもう一つの領域です。従来、これらのデバイスはメタデータ、小さなブロック、あるいは重複排除テーブルのために使用され、通常はSSDやNVMeドライブ上に存在していました。
このバージョンでは、システムにより ZIL (ZFS インテント ログ) 利用可能な場合は、特別な仮想デバイス上にホストされます。つまり、SLOGのような専用のデバイスを必要とせずに、非常に低レイテンシのメディアに同期書き込みを行うことができるため、より柔軟なハイブリッドプール設計が可能になります。
プロパティ special_small_blocks それは拡張され、 ZVOLの著作 これらの特殊VDEVは、特定の通常のファイルブロックだけでなく、これらの特殊VDEVにも含まれる可能性があります。さらに、このプロパティの値が2の累乗である必要はなくなったため、「小さなブロック」のしきい値を各ロードの実態に合わせてより柔軟に調整できるようになりました。
特別なvdevでZILを組み合わせることで、 フラッシュのZVOLと調整可能なしきい値メタデータ、小さなブロック、重複排除テーブル、クローン、同期書き込みを最速のデバイスに集中させ、回転ディスクをレイテンシの影響を受けにくい大容量ストレージとして残すアーキテクチャを設計できます。
zfs rewrite と zfs rewrite -P: 何も壊さずにデータを再配置する
2.3シリーズが導入された ZFSの書き換え 近年の最も強力な機能の一つとして、OpenZFS 2.4ではオプションを追加することでさらに一歩前進しました。 zfs rewrite -Pこのツールを使用すると、データの論理的な意味をそのまま維持しながら、プール内でデータを書き換えることができます。
とともに zfs rewrite 例えば、 圧縮アルゴリズム、チェックサム、重複排除を変更する またはコピー数を変更したり、vdev を追加した後にデータのバランスを再調整したり、特定のファイルを特別な vdev に強制的に移動したりできます。これらはすべて、ユーザー空間にコピーしたり、mtime などのメタデータを変更したりすることなく実行できます。
バリアント -P 制定 ブロックの論理的な生成時刻を保存する 可能な限り。これは増分送受信の効率に直接影響します。これらの値を安定させることで、後続のレプリケーションで実際に何が変更されたかをより正確に検出し、システム間でやり取りされるデータ量を削減できるためです。
もう一つの重要な点は、書き換えプロセスが保護されていることです。 標準レンジロックこれにより、データセットを過度にブロックすることなく、実際のワークロードと並行して実行できます。 sync=alwaysこの操作には 2 つの利点があります。コンテンツに論理的な変更がないため、ZIL への追加の書き込みは発生せず、同期書き込み専用のデバイスへの影響が軽減されます。
新しい管理オプション: -a、範囲スクラブ、BRT プリフェッチ
OpenZFS 2.4では、管理者の作業効率も向上します。 コマンドラインツールへの小さな変更最も実用的なものの一つは、オプションの追加です -a|--all スクラブ、トリム、初期化などの操作で使用されます。
このオプションのおかげで、 インポートされたすべてのプールに対してスクラブ、トリム、または初期化を実行します。 手動で各プールを反復処理する必要なく、1回のパスで完了します。これにより、人為的なエラーが削減され、複数のプールを持つサーバーのメンテナンススクリプトが簡素化されます。
もう一つの新機能は、実行機能です zpool scrub 特定の時間範囲に限定される オプションを通じて -S y -Eこの時間ウィンドウ アプローチは、特定の期間に問題が疑われる場合や、大規模なスクラブのコストを、影響の少ない複数の部分的な実行に分割する場合に最適です。
さらに、 zpool prefetch -t brtメモリにプリロードできる ブロック参照テーブル（BRT）つまり、ブロックのクローン作成に使用される内部テーブルです。この構造をプリフェッチすることで、クローン作成に依存する操作のレイテンシが短縮され、クローン作成に大きく依存するワークロードにメリットをもたらします。
権限、名前変更されたツール、重複排除、ブロッククローン
セキュリティと権限管理の分野では、OpenZFS 2.4では、 送信:暗号化これにより、暗号化されたデータセットを送信する権限を持つユーザーをより細かく制御し、スナップショット、レプリケーション、およびキー アクセスを管理するユーザー間で責任を分離できます。
同時に、 arc_summary y arcstat 彼らは zarcsummary y zarcstatこの名前変更により、他のシステム ツールとの名前の競合を回避でき、これらが ZFS ARC にリンクされたユーティリティであることが明確になり、多くのコンポーネントがある環境で役立ちます。
内部的には、ブランチ2.4は ブロック重複排除とクローン作成の最適化と修正データ構造が洗練され、エッジケースが修正され、メモリとCPUへの影響を軽減する取り組みがなされています。これはユーザーがすぐに気づくような新しいオプションではありませんが、高負荷時に重複排除やブロッククローンが有効化される際の予期せぬ動作が少なくなります。
ギャングブロック、ashift、低速vdev、特殊なトポロジ
新バージョンには、 ギャングブロックに関する改善と修正これらは、ZFSが従来の方法でデータを保存できない場合に使用する特別なブロックです。このコード領域に欠陥があると深刻な事態を招く可能性があるため、導入された多数の修正によって堅牢性が向上しています。
の管理 ashiftデバイスの物理セクターサイズに合わせて最小割り当てサイズを設定するパラメータです。「ashift」のよりスマートな処理により、大きなセクターを持つディスクへの不要な上書きが削減され、プールの寿命全体にわたってパフォーマンスを維持するのに役立ちます。
もう一つの非常に実用的な貢献は、 「ベンチに座らせる」異常に遅い行動をする子供たちをvdevs問題のあるドライブのせいでシステム全体のパフォーマンスが低下するのを防ぐため、システムはそのドライブへの依存を一時的に停止することができます。これは、ドライブが断続的に故障し始めた場合や、異機種ハードウェアが混在する構成の場合に非常に役立ちます。
ついに 特殊な vdev および重複排除におけるトポロジ制限を緩和します。これにより、高度なプールの設計における可能性が広がります。メタデータ、重複排除テーブル、ZIL、その他の機密要素用の高速デバイスを、トポロジ定義における過度に厳しい制限に常に直面することなく、容易に組み合わせることができるようになります。
OpenZFS 2.3.4 を 2.4 へのアップグレードのベースとして
この飛躍の大きさを完全に理解するには、次のことを覚えておく価値がある。 OpenZFS 2.3.4 これは、Linux カーネルのサポートをバージョン 4.18 に維持しながらバージョン 6.16 まで拡張し、準備中の FreeBSD 13.3 から 15.0 ブランチまでの互換性を確認した重要なメンテナンス リリースでした。
このレビューにより、 zfs rewrite、のために正確に設計されています 論理的な内容を変更せずにデータを移動する データセットの名前変更や手動コピーを伴う送受信に頼る必要もありません。仮想デバイスの追加後にプールのバランスを調整したり、ランダム書き込みによる断片化を軽減したり、既存のデータに新しいストレージプロパティを適用したりできるツールを提供することが目的でした。
古典的な戦略とは対照的に、 zfs rewrite そうだった より速く、より邪魔にならない データをユーザー空間に持ち出すことを回避し、データセット内のZILへの余分な書き込みを強制しないため、 sync=alwaysさらに、尊重 mtimeおよびその他の表示可能なメタデータファイルシステム上で動作するアプリケーションは、何かが起こったことをほとんど認識できないようになります。
OpenZFS 2.4とその進化版2.4.1を合わせると、 パフォーマンス、柔軟性、管理ツールの大幅な向上特に、特別な仮想デバイス、強力な暗号化、そして厳格なクォータを持つマルチユーザー環境を備えたハイブリッドプールに依存しているユーザーにとって、AVX2による暗号化の改善、統合された割り当てスロットリング、特別な仮想デバイスにおけるZIL、そして special_small_blocks, zfs rewrite そして、その変種は、ギャング ブロック、アシフト、重複排除、ブロック クローンに関するすべての作業とともに、OpenZFS をフリー エコシステムで最も先進的なファイル システムの 1 つとして統合し、Linux と FreeBSD、macOS、そして徐々に Windows でも利用される準備が整っています。
