OpenZFS 2.4.2リリース、Linux 7.0に対応
OpenZFS 2.4.2が2026年5月12日に公開された。Linux 7.0カーネルへの正式対応と、データ破損関連を含む多数のバグ修正が目玉の安定版だ。
Linux 7.0対応がメインラインから1か月遅れた
OpenZFSプロジェクトの開発者トニー・ハッター（Tony Hutter）が、5月12日にzfs-2.4.2タグを切った。前バージョン2.4.1の対応範囲はLinux 6.19までであり、7.0環境で使うには2.4.2を待つほかなかった。
Linux 7.0は2026年4月12日にリーナス・トーバルズ（Linus Torvalds）が公開した最新の安定版カーネルで、Ubuntu 26.04 LTSのデフォルトカーネルでもある。OpenZFSは、メインラインカーネルのリリースから約1か月遅れて対応版を出した形になる。
この「1か月のラグ」は、OpenZFSが置かれた構造を表している。OpenZFSはCDDLライセンスで配布されており、GPLv2のLinuxカーネルと法的に統合できない。だからLinuxにマージされず、外部カーネルモジュールとしてしか動かない。カーネルの内部APIが変われば、追従するしかない。
OpenZFSプロジェクトのドキュメントは、CDDLとGPLv2がいずれも自由ソフトウェアライセンスでありながら、両者を同じバイナリに含めることを制限する点で衝突すると明記している。
リーナスはかつて、外部カーネルモジュールの面倒は見ないと公言した。新しいカーネルのリリースが、外部モジュールにとっては毎回の追従作業を意味する。OpenZFSは20年近くこの構造の中で開発を続けてきた。
古いマウントAPIサポートを削除した
2.4.2の変更ログを読むと、Linux 7.0対応の中身が見えてくる。linux/super: remove support for old mount API というコミットが含まれている。古いマウントAPIへの対応が削除され、fs_context型に基づく新しいAPIに一本化された。
カーネル側でfs_contextをベースにしたマウントAPIへの移行が進んでおり、OpenZFSもこれに合わせて内部実装を整理した。「禁止された」マウントオプションを強制するカーネルへの対処や、新しいマウントパラメータパーサの実装も同時に入っている。
Linux 4.18までの後方互換性は維持されているが、マウント処理の内部は7.0系を前提とした構造に書き換えられた。古いカーネルを使い続ける選択肢は残るが、コードベースの軸足は7.0以降に移った。
データ破損まわりの修正が複数
機能追加よりも目を引くのは、データ破損やデッドロック関連のバグ修正が複数含まれていることだ。
主要なものを挙げると、ブロッククローン後にtruncateを行うと発生していたリード破損の修正、dRAID構成でディスク交換後に発生するチェックサムエラーの修正、ディスククリア後のdRAIDデータ破損修正、vdev再構築からのdmu_tx_assign()デッドロック修正、レンジツリー破損レース修正、zfsctl_snapshot_mountのメモリリーク修正など。
dRAIDはOpenZFS 2.1（2021年）で導入された分散型RAIDの仕組みで、ホットスペアをアレイ全体に分散配置することで、ディスク故障時の再構築（resilver）を並列化する。100台規模の大型ストレージでの再構築時間短縮が狙いだ。
このあたりは、本番環境でストレージプールを運用しているユーザーには見過ごせない。dRAID関連の修正が3件並ぶ点が目に留まる。データ整合性に関わる部分で、まだ問題が見つかり続けている。
OpenZFSのCopy-on-Write構造とチェックサム検証は、ファイルシステムレベルでデータ破損を検出する仕組みとして知られている。検出機構が厳密であるほど、内部の細かなバグも観測対象として上がってくる。
POSIX_FADV_DONTNEED対応の意味
機能面で目立つのは、POSIX_FADV_DONTNEEDのサポート追加だ。これはアプリケーションがOSに「このファイル領域はもう使わない、キャッシュから外していい」と伝えるためのインターフェースで、posix_fadvise()システムコールの一部だ。
一度読んだら捨ててよいデータ（バックアップツールやストリーミング処理）でカーネルのページキャッシュを汚さないために使われる。これまでOpenZFSは無視していたが、今回から実装された。さらに単一ブロックファイルでの長時間ハングを修正するパッチも入っている。
posix_fadvise()はLinuxを含む多くのUNIX系OSで標準化されているシステムコールで、アプリケーション側からカーネルにファイルアクセス予定を伝えてキャッシュ戦略を最適化させる。EXT4やXFSなど他のファイルシステムでは長く対応してきた機能だ。地味な機能だが、メモリ管理を意識したアプリケーションを動かす環境では効いてくる。
2.3系にも7.0対応版が出た
同じ日にOpenZFS 2.3.7も公開された。こちらは2.4系へまだ移行していないユーザー向けで、Linux 7.0対応と多くの同じ修正がバックポートされている。
| 2.4.1 | 2.4.2 | 2.3.7 | |
|---|---|---|---|
| リリース日 | 2026年 2月25日 |
2026年 5月12日 |
2026年 5月12日 |
| 系列 | 現行系 (旧) |
現行系 | LTS系 |
| Linux 下限 |
4.18 | 4.18 | 4.18 |
| Linux 上限 |
6.19 | 7.0 | 7.0 |
| FreeBSD | 13.3+ / 14.0+ |
13.3+ / 14.0+ |
13.3+ / 14.0+ |
OpenZFSは現行系列（2.4系）とLTS系列（2.3系）を並行してメンテナンスする方式を取っており、2.3.7は2.3系の最新ポイントリリースになる。本番環境でメジャーバージョンアップに慎重なユーザーは、2.3.7に留まる選択肢が残されている。
ただし、2.3系がいつまで新カーネルに追従するかは未定だ。OpenZFSのドキュメントによれば、LTS系列は「新しいカーネルや機能のサポートは受けない可能性がある」とされている。Linux 7.1以降への対応は、現行系の2.4系が担うことになりそうだ。
メインラインに入れない構造は変わっていない
OpenZFSをLinuxカーネルにマージしようという議論は何度も持ち上がってきた。直近では2025年にGitHubのissueで、デュアルライセンス化（CDDLとGPLv2+）を求める提案が再び出された。Oracleが原ZFSコードの権利者である以上、Oracleの動きなしには進まない。この結論は変わっていない。
つまりOpenZFSは今後も外部モジュールであり続け、カーネルが更新されるたびに追従作業を続けることになる。2.4.2はその20年続いた構造の延長線上にある。1か月遅れで対応版を出し続けられるだけのコミュニティ規模が、このプロジェクトの強さでもある。
ダウンロードと完全な変更履歴はGitHubのリリースページから取得できる。
書いていて気づいたが、Linux 7.0という節目のカーネルにOpenZFSが追いついた、それ自体はニュースとして地味な部類に入る。その地味さに、20年積み重ねた何かが見える気もする。
参照元
