OpenZFS の新しいバージョンがリリースされると、多くの管理者は、今すぐ更新する価値があるのか、それとも落ち着くまで待つ価値があるのか疑問に思います。 OpenZFS 2.4 この質問はさらに興味深い。 それは大きな変化を伴う パフォーマンス、新しい管理ツール、およびリリース候補版を本番システムで使用することについてのコミュニティの議論。
OpenZFS 2.4の一般的な機能
OpenZFS 2.4は、 安定した、そしてかなり野心的な性格 Linux と FreeBSD の両方の環境向けに設計されたこのプロジェクトは、最終的なラベル付けの時点で、最新のカーネルとの互換性を維持し、データのセキュリティを確保しながら、ファイル システムとボリューム マネージャの成熟を促進し続けることが目標であるとすでに強調されていました。
このバージョンでは、 ラマ 2.3 およびその中間改訂： 暗号化層新しい管理ツールなど ZFSの書き換えより柔軟なクォータ機能、および断片化の削減、重複排除の最適化、ギャング ブロック管理や問題のあるディスクの動作などの複雑な側面の改善を目的とした内部変更。
コミュニティはまた、 最新のカーネルとの統合Linux では、4.18 から最近の LTS ブランチ (2.4 の安定リリース時のカーネル 6.18 を含む) までのサポートが宣言されていますが、FreeBSD では、14.0 を含む 13.3 以降のバージョンがカバーされ、15.0 などの新しいブランチも準備されています。
OpenZFS 2.4 のプラットフォームサポートとカーネル互換性
OpenZFS 2.4の柱の一つは 幅広いプラットフォーム互換性多くの管理者にとって、これは重要なことです。期待される ZFS 機能を失うことなくオペレーティング システムのバージョンをアップグレードできるためです。
Linux側では、OpenZFS 2.4はバージョン4.18からシリーズまでのカーネルとの互換性を示しています。 6.18安定保守的なエンタープライズディストリビューションから、最新のカーネルを常に適用する高度な最新環境まで、あらゆるものを網羅しています。その中間には、サーバーで使用されるLTSバージョン、カスタムカーネル、CentOS Streamなどのプロジェクトで採用されているバージョンなど、一般的なリリースの全範囲が含まれます。
FreeBSDでは、新しいバージョンでは、 FreeBSD 13.3 今後は、14.0以降のバージョン、そして近々リリース予定の15.0も対象となります。この幅広いサポート範囲により、既に実稼働中のシステムと次世代の導入の両方において、特殊なパッチやカスタムソリューションを必要とせずにOpenZFSを引き続きご利用いただけます。
この互換性の背後には、シリーズですでに明らかだった継続的な努力がある。 OpenZFS 2.3.x2.3.4などの以前のアップデートでは、カーネルサポートを6.16まで拡張し、以前のRCで提供が開始されていたパッチを統合しました。OpenZFS 2.4は、これまでのアップデートを継承し、さらに一歩進んで、最新のカーネルとの整合性を確保し、ベーススタックを比較的頻繁にアップデートするユーザーのエクスペリエンスを向上させています。
クォータと新しいスペース管理機能
管理者にとって最も実用的な新機能の中には、システムの改善があります。 事前に決められた割り当てOpenZFS 2.4 では、ユーザー、グループ、プロジェクトのデフォルトのクォータを定義する機能が導入され、各ケースを手動で構成することなく、スペースの消費をより均一に制御できるようになりました。
この機能を使用すると、例えば、 すべてのユーザーの基本料金 特定のデータセットに作成されるリソースを制限したり、新しいリソースが割り当てられたときに自動的に適用されるプロジェクト制限を設定したりできます。これは、マルチユーザー環境、ホスティング、ラボなど、見落としによってプール全体が埋まってしまうのを防ぎたいあらゆるシナリオで非常に便利なツールです。
デフォルトクォータのサポートは、既存の特定のクォータを置き換えるものではなく、それらを補完するものです。管理者は、 世界政治 そして、より多くの（またはより少ない）スペースを必要とする特定のユーザーまたはグループに対して、例外を設定して調整します。これらすべては、既に使い慣れた同じプロパティモデルを維持しながら、標準のZFSツールで管理されます。
ダイレクトI/O、キャッシュレスI/O、およびミスアライン書き込み動作
パフォーマンスの面では、OpenZFS 2.4は管理に非常に興味深い変化をもたらしました。 直接入力/出力これまで、ダイレクトI/Oを使用すると、状況によっては書き込みアライメントと競合し、コードパスが最適ではなくなる可能性がありました。新バージョンでは、ダイレクトI/Oを理想的に実装できない場合に代替モードを使用するメカニズムが導入されました。 軽量キャッシュレスIO この種のシナリオ向けに特別に設計されています。
これは実際には何を意味するのでしょうか？期待される配置にうまく適合しない文章は、もはや病的なケースではなく、代わりに 最適化されたルート ZFS 内では、オーバーヘッドが削減され、ボトルネックが回避され、特に直接 I/O を使用するアプリケーションと使用しないアプリケーションが共存する環境では、より予測可能な動作が実現されます。
この変更は、次のような目標を持つ厳しいワークロードで特に役立ちます。 パフォーマンスを引き出す ZFSが提供する整合性保証を犠牲にすることなく、ストレージを拡張できます。特別に設計されたフォールバック機能により、OpenZFSは、理想的な操作の整合性を常に維持できない多くのアプリケーションの現実により適しています。
OpenZFS 2.4 における統合割り当てスロットリングと断片化削減
OpenZFS 2.4のもう一つの大きな変更点は、新しいアルゴリズムの導入です。 統合割り当てスロットリングこの名前の背後には、仮想デバイス (vdev) の断片化を減らし、システムに負荷がかかっているときに書き込みが分散される方法を改善することを目的としたメカニズムがあります。
これまで、高負荷状況でのブロック割り当ては、時間の経過とともに、 vdevの断片化統合アルゴリズムは割り当て率を調和させることを目的としており、これによりプールはより整然とした構造を維持し、スペースが少なくなり始めたときやブロック サイズの組み合わせが非常に多様であるときにパフォーマンスの低下を軽減します。
こうした変更は新しいコマンドほど目立ちませんが、プールの拡張、再バランス調整、新しい仮想開発環境（vdev）の追加、そして数年にわたるメンテナンス作業など、長期的な導入においては非常に役立ちます。OpenZFS 2.4は、割り当て制御を改善することで、 時間の経過とともにより安定した行動システムが集中的に使用されている場合でも。
AVX2とAES-GCMによる暗号化の改善
セキュリティとパフォーマンスの面では、OpenZFS 2.4には、 AES-GCM 用の AVX2簡単に言えば、暗号化の実装が改良され、これらの高度なベクトル命令を備えた最新のプロセッサの機能をより有効に活用できるようになりました。
その結果、暗号化の保証を犠牲にすることなく暗号化が高速化されます。これは、大量の暗号化データを処理するシステムや、保護されたデータセットに対して多数の同時操作が実行される環境で特に顕著です。 CPUオーバーヘッドを削減 暗号化に関連すれば、より多くのリクエストを処理できるようになり、より多くのリソースを他のシステムタスクに割り当てることができます。
実際には、管理者は引き続き以下の機能に頼ることができます。 ZFSネイティブ暗号化 以前の世代のようなパフォーマンスへの大きな影響なしに、機密データを保護します。暗号化は「無料」になるわけではありませんが、以前は明らかにボトルネックとなっていたワークロードにおいて、より管理しやすくなります。
特殊 vdev の ZIL と special_small_blocks の改善
OpenZFS 2.4では、 特別なvdev特定の種類のデータ (メタデータ、小さなブロック、重複排除テーブルなど) を、通常は SSD または NVMe などのより高速なメディアに保存するように設計されたデバイスです。
一方で、 ZIL (ZFS インテント ログ) 利用可能な場合は専用の仮想デバイス上に配置します。これにより、低レイテンシのデバイスへの同期書き込みを集中させやすくなり、データベースや強力な永続性を備えたメッセージングシステムなど、同期を多用する操作に依存するアプリケーションの応答時間が向上します。
一方、プロパティの挙動は拡張される special_small_blocks そのように ZVOLの著作 また、特定の通常のファイルブロックだけでなく、特別な仮想デバイスにも配置できます。さらに、値が2の累乗でなければならないという制限が緩和されたため、管理者は厳格なオプションに制限されることなく、実際のワークロードに合わせてより細かいサイズを選択できます。
これらの改善を組み合わせることで、 最も重要なデータ メタデータ、小さなブロック、ZIL、重複排除テーブルなど、一部のデータは高速メディアに保存され、残りのデータはより安価なディスクに残ります。これにより、「小さい」データとそうでないデータの区別がはるかに柔軟になります。
zfs rewrite と zfs rewrite -P: データを効率的に再配置する
2.3シリーズでは、最近の最も印象的な機能の1つであるサブコマンドがすでに導入されています。 ZFSの書き換えOpenZFS 2.4では、このツールをさらに進化させ、バリアントを組み込んでいます。 zfs rewrite -Pこれにより、プール内でデータを再配置する際に新たな可能性が生まれます。
コマンド zfs rewrite 「書き直すファイルまたはデータセットの内容は、論理的な意味を変えることなくコピーされますが、物理的には内部プロパティが異なる別の領域に再配置されます。これにより、圧縮アルゴリズム、チェックサムの種類、重複排除の適用の有無、コピー数、さらには優先デバイスなどの変更が可能になり、データをユーザー空間にコピーして書き換える必要がありません。
これにはいくつかの明確な利点があります。従来の「コピー＆リネーム」方式に比べてI/Oトラフィックが削減され、キャッシュへの影響が最小限に抑えられ、外部ツールを介したデータの移動に要する長時間を回避できます。さらに、コンテンツに論理的な変更がないため、 mtimeは変更されない また、ユーザーの観点からは目に見えるその他のプロパティもありません。つまり、多くのアプリケーションでは操作に気付かないのです。
選択 zfs rewrite -P の可能性を追加します 論理的な出生時刻を保存する 可能な限りブロックの情報を保存することで、増分レプリケーションフローのサイズを最小限に抑えることができます。この情報を安定的に維持することで、後続の送受信操作で実際に変更された部分と変更されていない部分をより正確に識別できるようになり、システム間で移動する必要があるデータの量を削減できます。
もう一つの重要な利点は、書き換えプロセスが保護されていることです。 レンジロック 通常のワークロードと並行して実行できるため、システムを過度にブロックすることなく実行できます。 sync=always データの論理的な変更がないため、ZIL への追加の書き込みが強制されず、同期操作での追加コストを回避できるため、メリットはさらに大きくなります。
OpenZFS 2.4 の新しい管理オプション: -a|–all、範囲スクラブ、BRT プリフェッチ
OpenZFS 2.4では、管理ツールの機能がさらに強化され、日常的な使用に役立つオプションがいくつか追加されました。その一つが、 -a|–すべて スクラブ、トリム、初期化など、プールのメンテナンス タスクを実行するコマンドで使用します。
このオプションを使用すると、 すべてのインポートされたプール 一つ一つを手動で反復処理する代わりに、一度にすべて処理できます。これにより、複数のプールを管理するサーバー上の作業が大幅に簡素化され、人的ミスが削減され、自動化が容易になります。
さらに、 zpool scrub 限定 特定の時間範囲 オプションを通じて -S -Eこの機能は、問題が疑われる期間のみを確認する場合や、全体的なパフォーマンスに過度の影響を与えないようにスクラブのコストを複数の部分実行に分散する場合に非常に役立ちます。
もう一つの関連する新機能は、 zpool prefetch -t brt メモリにプリロードする ブロック参照テーブル（ブロック複製テーブル）これにより、以前のバージョンで導入されたブロッククローン機能をより有効に活用できるようになり、この機能に関係する内部構造にアクセスする際の待ち時間が短縮されます。
権限、ツール名の変更、重複排除とブロッククローンの改善
OpenZFS 2.4では、エクスペリエンスを洗練させる小さいながらも重要な改善点として、新しい権限が追加されました。 送信:暗号化暗号化されたデータを誰が送信できるかをより細かく制御できるように設計されており、スナップショットを管理する人、レプリケーションを処理する人、暗号化キーにアクセスできる人の間で責任が分離されているチームに適しています。
従来のユーティリティも名称が変更されました。 arc_summary y arcstat、その後知られるようになる zarcsummary y zarcstatこの変更により、名前の競合を回避し、これらが ZFS に関連付けられたツールであることが明確になります。これは、同様のコマンドを公開する複数のコンポーネントを持つシステムで役立ちます。
内部的には、2.4シリーズは 新しい最適化と修正 これは重複排除とブロッククローンの両方に当てはまります。データ構造が洗練され、エッジケースが修正され、メモリとCPUへの影響をより管理しやすいように、より適切なアクセスパターンが模索されています。これらの変更はユーザーには直接見えませんが、複雑なワークロードにおける動作の安定性が向上し、予期せぬ問題も減少します。
ギャングブロック、アシフト、遅い子仮想デバイス、特殊なトポロジ
OpenZFS 2.4には、前バージョンに比べて多くの改良と修正が組み込まれています。 ギャングブロックこれは、従来の方法では配置できないブロックを処理するために設計された内部システム機能です。ほとんどのユーザーは直接操作することはありませんが、この部分のコードに不具合があると深刻な結果を招く可能性があります。そのため、多数の修正と最適化が行われたことは、システム全体の堅牢性にとって朗報です。
並行して、 シフトデバイスのセクターの物理サイズに合わせた最小割り当て単位を定義するパラメーターです。シフト管理の改善により、大きなセクターを持つディスクに必要以上のデータが書き込まれる可能性が低減され、プールの寿命全体にわたって許容可能なパフォーマンスレベルを維持するのに役立ちます。
もう一つの興味深い新機能は、子vdevを次のように動作させる機能です。 異常に遅い 一時的に「ベンチテスト」を行うことができます。システム全体のパフォーマンスを低下させるのではなく、しばらくの間、負荷を軽減することができます。これは、ディスクに障害が発生し始めた場合、ドライブに断続的な問題が発生している場合、または環境に一貫性のないハードウェアがある場合に非常に役立ちます。
ついに彼らは 緩和されたトポロジ制約 特殊VDEVおよび重複排除VDEVにおいて、高度な構成を持つプールを設計する際の柔軟性が向上します。これにより、レイアウト定義に過度に厳格な制限を設けることなく、メタデータ、重複排除テーブル、ZIL、その他の機密要素用の高速デバイスをより適切に統合できます。
OpenZFS 2.3.4: メンテナンス、初期のZFS書き換えと統合
2.4が示す飛躍を完全に理解するには、次の点をざっと見てみる価値がある。 OpenZFS 2.3.4は、少し前に登場したメンテナンス バージョンであり、後に新しいメイン ブランチに統合されるものの基礎の一部を築きました。
バージョン2.3.4は2.3.3の2ヶ月後にリリースされ、非常に重点が置かれていました。 堅牢性と互換性Linuxカーネルのサポートをバージョン6.16まで拡張し、最小バージョンを4.18に維持しました。また、FreeBSDバージョン13.3以降（近日リリース予定の15.0を含む）との互換性も確認しました。つまり、安定性を犠牲にすることなく、最新のベースシステムとの共存を実現するための基盤を既に整えていたのです。
この特定のレビューでは、コマンドの初期バージョンがデビューしました。 zfs rewriteまさにそのために設計された 論理的な内容を変更せずにデータを移動する コピー/リネームやデータセット名の変更を伴う送受信といった、より面倒な戦略に頼ることなく、仮想デバイスの追加後にプールのバランスを調整したり、ランダムに書き込まれたファイルの断片化を軽減したり、既存のデータに新しいストレージプロパティを適用したりできるツールを提供することが目標でした。
従来の代替品と比較して、 zfs rewrite データがユーザー空間に移動するのを避けるため、高速化されます。 sync=alwaysさらに、データが論理的に変更されないため、ZILへの追加書き込みがトリガーされず、パフォーマンスが向上します。これらすべてが、何も変更せずに実行されます。 mtimeまたはその他のメタデータ アプリケーションから見えるため、その上で実行されるソフトウェアへの影響が最小限に抑えられます。
バージョン2.3.4では、さまざまな FreeBSD固有の設定パッケージングの改善と、コードの隅々まで磨きをかけるための一連のマイナーフィックスが含まれていました。これは破壊的な変更を導入することを目的としたバージョンではなく、新機能を多数搭載したブランチ2.4に移行する前に、安定性を微調整するためのものでした。
OpenZFS 2.4 RC1、RC2、RC4: テスト、フィードバック、コミュニティの議論
2.4シリーズが安定版と宣言される前に、プロジェクトはいくつかの リリース候補者 (RC1、RC2、RC4) は、上級ユーザーや開発者がテストを行い、問題を報告できるようにすることを目的としています。これらのリリース候補版には、これまで説明したほぼすべての機能が既に含まれています。デフォルトクォータ、フォールバックとしてのキャッシュレスI/O、統合アロケーションスロットリング、暗号化の改善、特別な仮想デバイスにおけるZIL、special_small_blocks拡張、新しい権限、ツール名の変更など、その他にも多くの機能が含まれています。
RC1とRC2のノートではコミュニティの重要性が強調されている ビルドをテストします GitHub経由でフィードバックを送信し、参照ブランチに対する変更を簡単にリストするコマンド（ git cherry zfs-2.3-release をさまざまな RC と比較しています。メッセージは明確です。目標は、コードを「安定」とラベル付けする前に、実際の環境でテストすることです。
ただし、特定のRC（例えば、 2.4.0-RC4FreeBSD 15.0 のように RELEASE と表記されたバージョンに .NET Framework (RF) が含まれていることに、一部のユーザーは驚きを隠せませんでした。なぜ RF を含めることにしたのか疑問に思うユーザーもいました。 OpenZFS リリース候補 以前の既存のブランチに頼るのではなく、オペレーティングシステムの安定版とみなされるバージョンにアップグレードする。この選択は、データを保存するファイルシステムが最終バージョンのみに基づいていることを望む人々から不満を招いた。
疑問は、その決定の持続性に関するものでした。OpenZFS 2.4.0-RC4を搭載したFreeBSD 15.0をインストールした後、-CURRENTブランチに従わなかった場合、マイナーリビジョンやシリーズの新しいポイントがリリースされるまで、リリース候補版で数ヶ月間「行き詰まる」ことになるのではないかという懸念がありました。また、将来のリリースでも同様の問題が発生するのではないかという懸念もありました。 15.1 最終バージョンではなく、別の RC (たとえば、仮想の 2.4.1-RC3) を統合します。
この議論の背後には、「リリース候補版ファイルシステムのような繊細なコンテキストにおいて、リリース候補版（RC）は実質的に安定版であり、わずかな調整のみで済むと考える人もいます。しかし、RCはRELEASEとマークされたシステムの基盤として使用すべきではなく、開発ブランチを綿密に追跡する人のために確保しておくべきコードだと考える人もいます。
いずれにせよ、RCは 実験場これらの改善により、バグの検出、細部の調整が可能になり、「2.4 安定版」リリースへのより確実な到達が可能になりました。セキュリティを何よりも優先する方は、2.4 が本番環境で十分に成熟したと判断されるまで、2.3.x などの以前のブランチを使い続けるという選択肢もございます。
OpenZFS 2.4がもたらすすべてのものは、2.3シリーズとそのメンテナンスアップデートでプロジェクトが獲得した堅牢性に基づいており、カーネルの互換性の改善、次のような新しいツールを組み合わせています。 ZFSの書き換えこのリリースには、重複排除とブロッククローンの調整、暗号化の最適化、ギャングブロックとashiftの内部変更、そして様々な新しい管理オプションが含まれています。一部のオペレーティングシステムにおけるリリース候補版の使用については議論が巻き起こっていますが、安定版2.4は、LinuxおよびFreeBSDでZFSの既存の整合性と復元力の保証を犠牲にすることなく、より多くのメリットを得たいと考えている人にとって、大きな飛躍をもたらします。
