ZFS 2.3 リリース、RAIDZ 拡張機能を搭載

 (github.com/openzfs)
1 ポイント 投稿者 GN⁺ 2025-01-15 | 1件のコメント | WhatsAppで共有
  • OpenZFS 2.3.0 は、既存の RAIDZ プールに新しいデバイスを追加して ダウンタイムなしで容量を増やせる RAIDZ Expansion を中核機能として含む
  • Fast Dedup は既存の重複排除機能の性能を大幅に改善し、コードベース全体の性能改善もあわせて行われた
  • Direct IO は読み書き時に ARC をバイパスできるようにし、NVMe デバイスのようにキャッシュが効率を下げうる環境を対象としている
  • よく使われるコマンドの選択的な JSON 出力、最大 1023 文字のファイル・ディレクトリ名対応、以前のバージョンの問題を扱う重要なバグ修正が追加された
  • サポート範囲は Linux カーネル 4.18~6.12 と FreeBSD 13.3、14.0~14.2 で、今回のリリースサイクルには 134 人が参加した

OpenZFS 2.3.0 で変わったこと

  • OpenZFS 2.3.0 は、ストレージ拡張、重複排除性能、入出力経路、コマンド出力形式、ファイル名長の対応を中心に更新された
  • リリースタグは zfs-2.3.0 で、OpenZFS 2.2.0 以降の変更を含む

ストレージ拡張と性能改善

  • RAIDZ Expansion は既存の RAIDZ プール に新しいデバイスを追加し、ダウンタイムなしでストレージ容量を増やせるようにする
  • Fast Dedup は既存の OpenZFS 重複排除 機能の主要な性能アップグレード
  • Direct IO は読み書き時の ARC バイパス を許可する
    • NVMe デバイスのようにキャッシュが効率を妨げる可能性がある状況での性能改善を目的とする
  • コードベース全体にも複数の性能改善が含まれる

コマンド出力と名前の長さ

  • JSON は、最もよく使われるコマンドに選択的な JSON 出力 を追加する
  • Long names は、ファイル名とディレクトリ名を最大 1023 文字 までサポートする

安定性、プラットフォーム、貢献

  • 以前のバージョンで報告された問題に対処する 重要なバグ修正 が含まれる
  • 対応プラットフォーム:
    • Linux カーネル 4.18~6.12
    • FreeBSD 13.3, 14.0~14.2
  • 今回のリリースサイクルには 134 人 のコントリビューターが参加した

ドキュメントと変更ログ

モジュールオプションの変更

  • 全オプションと制御対象は module parameters ドキュメントに整理されている
  • 新しいモジュールオプションには RAIDZ 拡張、重複排除ログ、Direct IO、allocator、scrub、resilver 関連の項目が含まれる
    • 例: raidz_expand_max_copy_bytes, raidz_expand_max_reflow_bytes, zfs_dio_enabled, zfs_dedup_log_mem_max, zfs_scrub_after_expand
  • 削除されたモジュールオプション:
    • zfetch_array_rd_sz
  • 変更されたモジュールオプション:
    • zfs_arc_shrinker_limit
    • zfs_bclone_enabled
    • zfs_vdev_disk_classic
    • zio_taskq_write

関連記事

1件のコメント

 
GN⁺ 2025-01-15
Hacker News のコメント

  • 長年準備されてきた ZFS RAIDZ 拡張 がついに入った
    主な機能は、既存の RAIDZ プールにデバイスを追加して停止なしで容量を増やす RAIDZ 拡張、OpenZFS の重複排除性能を大きく高めた高速重複排除、ARC をバイパスして NVMe のようにキャッシュが非効率になり得る環境で性能を改善するダイレクト I/O、よく使うコマンドの選択的 JSON 出力、最大 1023 文字のファイル・ディレクトリ名のサポート

    • より正確には、既存の RAIDZ vdev に新しいデバイス、つまりディスクを追加できるという意味
    • Proxmox を ZFS と NVMe の上で動かしているなら、2.3 が配布されたときに ダイレクト I/O を有効にした方がよいのか気になる
      どんな用途向けの機能なのか知りたい
    • 最初の 4 つは本当に大きな変化に見える
    • それでも vdev の削除 はまだ不可能だと見てよさそう
    • この機能が 暗号化 と一緒にどれだけ十分にテストされているのか気になる
      ZFS チームが暗号化を本当に最優先事項として扱っているのかも疑問
      Linux の ZFS は Solaris の ZFS の名声を多く受け継いでいるが、本番環境で使う人は現実を見るために issue tracker をかなり詳しく見る必要がある

  • ユーザー数ベースで圧倒的に大きい PC プラットフォームである Windows 側に、いまだに ZFS に対する答え がないのは理解できない
    Microsoft には WinFS があり、その次に ReFS もあったが後回しにされており、開発は続いていて Win11 にときどき一部が入ってくるものの、正式リリースは見えていない
    何人かの個人が ZFS 互換レイヤーを作る大きな作業に挑んでいるが、まだ成熟しているとも実運用可能とも言いがたい
    Windows がどうしていまだに 32 年前のファイルシステムを使っているのかわからない

    • 正直、Linux の状況もそれほど良くはない
      ZFS は Linux と ライセンス問題 があって完全統合が妨げられており、Btrfs は 15 年間開発されているのに、機能と安定性でまだ ZFS に及ばない
      ほとんどの Linux ディストリビューションはいまだにデフォルトで 19 年前の ext4 を使っており、ext4 も実際には NTFS と同じ年齢の ext2 の上に拡張を積み重ねたものに近い
      公平に見れば、ファイルシステムほど重要な OS コンポーネントも少なく、本番環境で 10 年以上検証されていないファイルシステムには手を出したくない人も多い
    • 理由は単純。ファイルシステムが負うべき負担の大半を、そのファイルシステムを載せる エンタープライズ向けストレージハードウェア が担っているから
      スナップショット、ブロックレベル重複排除、オブジェクトストレージ技術、RAID/耐障害性、サイズ変更など必要な機能をストレージ機器が担当する
      現代のストレージアプライアンスはほぼ黒魔術のレベルなので、NTFS にさらに多くの機能が必須というわけではない
      NAS/SAN 経由で透過的にアクセスするか、有能なディスクボックス上に NTFS ボリュームを保存すればよい
      Linux 世界のハイエンド領域には Lustre や GPFS があり、ZFS はたいてい性能が最重要ではないが耐障害性が必要な用途に向いている
    • メインライン Linux カーネルにも ZFS に相当する答えはない
      難しくリスクも高いわりに、見返りはたいてい技術的な尊敬にとどまるからだと思う
    • Windows と Linux を使っているが ZFS は使っていないエンドユーザーの立場として、自分が何を見落としているのか気になる
    • Windows 向け OpenZFS はリリース候補段階（rc11）に達しており、ボリュームのマウント周りに少し残っているバグがある
      深刻ではないが、今のところ暗号化は避けた方がよく、残った問題を修正するために数週間ごとに新しいリリース候補が出るほど開発速度も速い
      ここに Storage Spaces を組み合わせて、種類やサイズの異なるディスクをプールし、配置・冗長性・階層化を Space ごとに定義すれば、Windows は今や 高度なストレージプラットフォーム になる
      Windows Server、たとえば安価な 2022/2025 Essentials を使えば、LAN と仮想ハードディスク .vhdx 上で最大 10Gbyte/s の SMB Direct/RDMA も使え、iSCSI より設定が少なく高速な代替になる
      そこで ZFS の Web GUI である napp-it cs を Solaris から Windows に移植し、Storage Spaces と ZFS、さらに Proxmox のようなリモート OpenZFS サーバーを管理できるようにした。非商用利用は無料

  • 拡張機能がかなり保守的に作られている点は良い
    拡張は完全に透過的で再開可能であるだけでなく、処理の全期間を通じて冗長性も維持される
    ただし、人々が知っておくべき小さな注意点が1つある
    拡張が終わった後でも既存ブロックは以前のデータ対パリティ比を維持する。たとえば 5-wide RAIDZ2 は、データ3に対してパリティ2のまま、より大きなディスク集合に分散される
    新しいブロックは新しいデータ対パリティ比で書き込まれる。たとえば 5-wide RAIDZ2 を1回拡張して 6-wide になると、データ4に対してパリティ2になる

    • それが本当に注意点なのかはよく分からない。既存データが最適でない配置のまま残る可能性がある、というだけだ
      それでも RAIDZ N の利点はそのままで、最大 N 台のディスクが完全に故障してもプールは動き続ける
    • その注意点は十分に予想できる挙動だ。ZFS の機能は通常、既存ブロックを書き直さないと考えるべきだ
      たとえば設定変更も新しいデータにしか適用されない
    • 正直かなり大きな注意点だ
      Da1 Db1 Dc1 Pa1 Pb1
      Da2 Db2 Dc2 Pa2 Pb2
      Da3 Db3 Dc3 Pa3 Pb3
      ___ ___ ___ Pa4 Pb4
      ここで ___ は空き領域だ。ディスクを1台追加して拡張すると、論理的には次のようになると期待できる
      Da1 Db1 Dc1 Da2 Pa1 Pb1
      Db2 Dc2 Da3 Db3 Pa2 Pb2
      Dc3 ___ ___ ___ Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      しかし私の理解では、実際には次のように拡張される
      Da1 Db1 Dc1 Dd1 Pa1 Pb1
      Da2 Db2 Dc2 Dd2 Pa2 Pb2
      Da3 Db3 Dc3 Dd3 Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      ここで Dd1〜3 のブロックは単に無駄になる。つまり、アレイに新しいディスクを追加しても空きストレージは 25% しか増えないということだ
      たとえば 8TB ディスクで元の総使用可能容量が 24TB、拡張前の空き容量が 4TB だったなら、拡張後の空き容量は 5TB になる
      私の誤解だと言ってほしい。誤解でないなら、かなり役に立たない実装に見える

  • ZFS ユーザーにとっては大きなニュースだ。おそらく趣味・家庭向けユーザーにとって特にそうだろうが、それでも大きい
    RAIDZ 拡張はここ数年で最も多く要望されていた機能の1つだった

    • まだ ZFS に慣れていなくて、リリースノートでも見つけられなかったのだが、拡張は同じサイズのディスクでしか動作しないのか気になる
      より大きい、あるいは小さいディスクを追加できるのか、それともすべてのディスクサイズが同じでなければならないのか知りたい

  • これはオンライン拡張だ。拡張自体は以前から可能だったが、アレイを停止する必要があった
    より大きいドライブへ移行することも可能だったが、1回に1台ずつ交換しなければならず、当然ながらすべてのドライブをアップグレードし終えて初めて新しい容量を得られた
    私の知る限り、プールの縮小はまだ不可能だ。なので 5 台構成のプールに 6 台目を追加すると、たとえデータがごく少なくても再び 5 台には戻せない

  • ついに！
    今買える最も高価で高密度なハードディスク 4 台で、RAID-Z3 のような境界線上で狂気じみた単一 vdev 構成も可能になる
    最初はディスク 3 台分の冗長性なので有効容量利用率は 25% しかないが、容量需要が増えるたびにディスクを1台ずつ買い足して 12 台前後まで拡張できる
    時間が経つにつれてディスク価格は下がり、またディスクを異なる時点で追加するので故障確率も分散される

    • そのとおりだが、兄弟コメントも見るべきだ
      アレイを拡張しても既存データがより効率的に保存されるわけではない
      新しいパリティ/データ比を得るには、データを強制的にコピーして古い非効率な版を削除しなければならない。たとえばこういうツールが必要だ [1]
      個人的には、個別に完成した RAID-Z 構成を購入して新しい構成を追加するか、古い構成をディスク単位で置き換えていくほうがずっと良いと思う
      [1] https://github.com/markusressel/zfs-inplace-rebalancing

  • ZFSはbtrfsと比べてどうなのか気になる
    今ホームサーバーでbtrfsを使っているが、妙な問題を何度か経験した
    ZFSに移行しようかと考えているが、同じような状況には陥りたくない

    • 15年前、Linux 2.6.33-rc4の頃にbtrfsを初めて使ってみた
      3日で削除できないファイルができてしまい、使用をやめて後からZFSを見つけた
      ZFSにもそれほど深刻ではない問題がいくつかあったが、当時は計算機科学の学生で、btrfsで遭遇した問題に比べれば些細に見えたので直せそうだと思った
      その後18か月の間に気になっていた問題をすべて解決し、当時のZFSOnLinuxリポジトリにパッチを送り、その努力はLinuxでZFSを本番環境に使えるようにする助けになった
      それ以来ずっとZFSを使っており、うまく動いている
      btrfsの状態がもっと良ければ、btrfsへのコントリビューターになっていただろう。だが当時の状態は悪かっただけでなく、その後も本格用途で試すたびに、まだ空き容量があるのにENOSPCが頻発するといった問題に足を引っ張られ続けた
      一方でZFSは単純に動く。私や多くの人たちが、きちんと動くようにするために多くの作業をしてきた
      最大の違いは、ZFSには非常に堅牢な基盤があり、それは優れた回帰テスト基盤のおかげだ
      ユーザー空間版がコードをランダムに実行して本番環境で爆発する前にバグを見つけ、提案されたすべての変更ごとにテストスイートを回してバグをふるい落としている
      ZFSは提案変更をレビューする人も他のファイルシステムより多い。Btrfs開発者たちも両ファイルシステム間の人員差が大きいとよく言っており、たしかおよそ6倍だったと思う
      とにかく、ZFSを使って後悔する人はまれなので、たぶん気に入ると思う
    • ZFSはほぼ20年間本番環境で使われてきた
      BTRFSのドキュメントによれば、BTRFSはまだ完全には本番環境向きではない: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
      単純な用途の一部はBTRFSでも本番利用に十分と見なせるかもしれないが、結果は環境ごとに異なる
    • btrfsはZFSと似た目標を持っているが、はるかに成熟していない
      DKMSが不要なのでルートパーティションで使っていたが、問題が多かった
      かなり単純にミラー構成で使っていただけだが、ある日アレイ内の1台のドライブに問題が起きると、btrfsはまともに踏ん張れなかった
      記憶では、すべてを読み取り専用で再マウントし、デフォルトでは縮退モードで動作しなかった
      チェックサムのような機能がないmdraidですら、これよりましだっただろう
      ZFSも同様にアレイに欠陥があると表示するが、当然ながらそのまま使い続けられるようにしてくれる
      デフォルト動作がRAIDではなかったこと、つまりデータを読み戻すRの部分が事実上欠けていたことのせいで、信頼を失った
      ZFSに移ってからは問題がなく、コミュニティと優れたツールもずっと多い
    • 数年間Btrfsを使っていたが、数年前に離れた
      Btrfsでも妙なことが一度二度はあったが、最終的にはすべて復旧できた
      全体としてBtrfsの柔軟性は良かったが、たいていの場合は遅すぎると感じた
      今はArch LinuxでZFSを使っており、今のところ全体的に問題はない
      パフォーマンスを最適化できるチューニング項目や方法も多い
      一つ助言するなら、ZFSは十分に調べてテストしてみるのがよい。多少の学習コストはあるが、私にとっては移行する価値があった

  • NVMe性能のためにARCバイパスが入ったのはうれしい
    ZFSはNVMeの潜在能力を十分に引き出せていない傾向がある
    オンライン拡張も興味深いかもしれない
    非常に忙しいデータベースでZFSを使おうとして、断片化バグでひどい目に遭った
    性能を元に戻す唯一の方法は、ボリュームの外にデータをコピーし、ボリュームを消してから再度コピーし直すことのようだった
    これでおそらく、zpoolを拡張してから同じボリューム内でテーブルスペースをコピーし、断片化を減らせるようになるかもしれない

  • TrueNASがすでにこの機能をサポートしている点も注目に値する[0]
    おそらく2.3.0rc3を使っているようだが、安定性はよく分からないものの、とても期待している
    https://www.truenas.com/blog/electric-eel-openzfs-23/

  • 家庭用でなぜ ZFS のようなものを使うのか説明してもらえる？

    • 自分にとって都合がいい理由はこんな感じ
      チェックサム: 家庭用はたいていハードウェア品質が低いので、むしろさらに重要。欠陥のあるコントローラ、ひどいケーブル、推奨より高い温度で保管されたハードディスクなど、誤ったデータが保存される理由はいくらでもあり、ZFS は冗長性があればそれを自動でうまく処理してくれる
      スナップショット: バックアップを作り、ミスしたときにファイルの以前のバージョンへすばやく戻るのにとても便利
      安心感: 代替手段と比べると、ZFS は使いやすく、データ損失につながるミスをしにくいと感じる。たとえば故障したドライブを交換しているときに、誤って別のドライブを抜いてプールが使えなくなっても、挿し直せば何事もなかったかのように戻る
      今では mdadm も違うかもしれないが、数年前に使ったときは破壊的なミスをしてしまわないか常に不安だった
    • 他の人がしていない答えをすると、ZFS は Steam ゲームの保存 に向いている
      recordsize=1M と compression=zstd を設定すると、同じ容量にゲームを 33% ほど多く保存できることがよくある
      ある友人は、数台のハードディスクに Steam ゲームを保存するのに ZFS を使っている。そして ZFS に SSD を L2ARC として割り当てていた
      ZFS がよく起動するゲームを自動で SSD にキャッシュし、読み込みを高速化してくれる
      好きなゲームが変われば、ZFS が自動で適応してそのゲーム群を SSD にキャッシュする
    • zrepl を使ってファイルシステム全体を 10 分ごとにローカル NAS にレプリケーションしている
      WD_BLACK SN850 が突然死んだとき [1]、すでに一度かなり助けられた
      典型的な git のミスで消したコードも復旧してくれた
      ユーザーのミスや単一デバイスの故障でデータを失うことは、もうあってはならない。私たちにはその技術がある
      [1]: https://chromakode.com/post/zfs-recovery-with-zrepl/
    • 理由はいろいろあるが、自分にとって大きいのは 信頼性 と移植性
      チェックサムと自己修復があり、Linux、FreeBSD、Windows、macOS で読み書きできる、これ以外の現代的なファイルシステムはない
      スナップショット、つまりブート環境は Btrfs もサポートしている。自分の Linux インストールでは、ルートファイルシステムを読むためにサードパーティ製カーネルモジュールを気にしたくないのでそちらを使っている
      性能も極端に悪いわけではないが、Linux で性能が主な関心事なら XFS のほうが良い選択だ
    • 比較的簡単だが強力
      その前は MDADM + LVM + dm-crypt + ext4 を使っていて、それも動いてはいたが、レイヤーが多すぎて面倒だった
      自動スナップショットはとても簡単で高速
      ファイルを削除したときもアクセスしやすく、スナップショット全体を復元する必要はなく、隠し .zfs/ フォルダからそのまま cp すればいい
      ここ数年、8TB ディスク 6 台で運用している。RAIDZ2 なので最大 2 台まで故障しても大丈夫
      デスクトップの単一ディスクで使うかと聞かれたら、たぶんそうはしない