著者 Linux kernel 7.1の新機能とサーバーへの影響
Linux kernel 7.1は2026年6月14日に公開されました。VPSで届く変更、実行中のkernelを確認する方法、各distributionでの提供時期を解説します。
Linux kernel 7.1 の新機能
Linux kernel 7.1 は 2026年6月14日にリリースされ、7.0 の9週間後に公開されました。VPS（virtual private server）の利用者に関係する変更は、ストレージとファイルシステム、ネットワーク、メモリ管理、プロセスとコンテナの制御という4つの分野に集約されます。それ以外の変更は主にデスクトップとグラフィックス関連で、headless server では読み込まれません。
最初に、もう1つ確認すべき点があります。サーバーでは、ほぼ確実に7.1は稼働しておらず、当面は稼働することもありません。kernel.org には、7.1がlongterm releaseとして掲載されていません。2026年8月11日時点でのlongterm系列は6.18、6.12、6.6、6.1、5.15、5.10です。主要なserver distributionは、これらのいずれか、または各distributionが独自に保守する系列を基盤にしています。「kernelの新機能」と「サーバーで利用できる新機能」には数年の差があるため、このガイドでは両方を扱います。
現在、VPS で実行されている kernel
uname -r
uname -srm
systemd-detect-virtuname -r は、実行中の kernel release を表示します。Ubuntu 24.04 では、6.8.0-79-generic のように表示されます。最初のダッシュより前の部分は upstream の系列です。それ以降はディストリビューション独自の build number であり、upstream の番号とはまったく連動しません。Canonical の 6.8.0-79 には、後の kernel から backport された数千件の修正が含まれているため、これは Linus が 2024 年 3 月に 6.8 として tag したコードではありません。つまり、「自分の kernel は古い」という言葉から受ける印象ほど、実態は単純ではありません。機能は古い場合があります。しかし、security fix は通常、古くありません。
systemd-detect-virt は、kernel を変更できるかどうかを示します。完全な virtual machine では kvm と表示されます。この場合は独自の kernel image を起動するため、upgrade は実際の upgrade になります。container virtualization では lxc または openvz と表示されます。この場合は host kernel を共有しています。container plan では uname -r に provider の kernel が表示されます。kernel package をインストールしても、起動できる kernel は変わりません。また、provider が host を新しい kernel で再起動するまで、この release の機能は利用できません。kernel の作業を計画する前に、この確認を実行してください。
The data behind this chart
[
{
"distro": "Ubuntu 26.04 LTS (7.0)",
"releases_behind_7_1": 1,
"notes": "GA kernel, shipped with the April 2026 release"
},
{
"distro": "Ubuntu 24.04 LTS, HWE (6.17)",
"releases_behind_7_1": 4,
"notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
},
{
"distro": "Debian 13 trixie (6.12)",
"releases_behind_7_1": 9,
"notes": "upstream longterm line, kernel.org projected EOL December 2028"
},
{
"distro": "RHEL 10 and its rebuilds (6.12)",
"releases_behind_7_1": 9,
"notes": "Red Hat backports fixes into its own frozen 6.12 stream"
},
{
"distro": "Ubuntu 24.04 LTS, GA (6.8)",
"releases_behind_7_1": 13,
"notes": "the default unless you install the HWE stack"
},
{
"distro": "Ubuntu 22.04 LTS, GA (5.15)",
"releases_behind_7_1": 26,
"notes": "upstream longterm line, kernel.org projected EOL December 2026"
}
]これは 6 個の platform に該当しますが、7.1 で起動する platform は 1 つもありません。最も新しいのは Ubuntu 26.04 LTS (7.0) で、upstream release では 1 個遅れています。現在もサポート対象で最も古いものは、26 個遅れています。Ubuntu 24.04 のデフォルトの GA kernel は 13 個前の release で、Debian 13 と RHEL 10 は 6.12 longterm 系列で 9 個前です。release 数の比較は、ディストリビューションが backport したすべての内容を無視するため、大まかな指標にすぎません。ただし、差がどのような構造になっているかは示せます。これらのどれを実行するか検討している場合、サーバーにおける LTS と interim release のトレードオフが、この数値の背景にある判断です。
7.1 のストレージとファイルシステム
7.1 では、ブロック層だけでなくファイルシステム内でも T10 PI（protection information）を生成・検証できるようになり、T10 のアライメントにも柔軟に対応します。T10 PI は各ブロックに付加される追加バイトで、チェックサムと、そのデータが属するブロックを識別するタグを保持します。これにより、誤った場所への書き込みや不完全な書き込みを検出し、不正なデータを正常なデータとして返すことを防ぎます。VPS テナントにとっての問題はハードウェアです。整合性メタデータはデバイスから公開される必要がありますが、仮想ディスクでは通常公開されません。
ls /sys/block/vda/integrity/ほとんどの VPS ディスクでは No such file or directory が返ります。これは、デバイスが整合性サポートを登録した場合にだけ、ブロック層が integrity ディレクトリを作成するためです。このエラーはこの環境では通常の結果であり、障害ではありません。ストレージ機能を詳しく調べる前に、使用しているディスクの実体を確認したい場合は、まず VPS のディスクが実際に NVMe か確認する 必要があります。VPS における NVMe と SATA SSD の違いでは、その違いによって数値が変わる理由を説明しています。
Btrfs では、メモリ不足時の copy-on-write による書き込み増幅が修正されます。また、追跡対象の範囲で最初の extent をクリアする処理も変更され、マージリクエストに記載されたサンプルワークロードではスループットが 10% 向上しています。シャットダウン操作は experimental として扱われなくなりました。XFS では、iomap による zero range のフラッシュと検索が改善され、リアルタイムグループのジオメトリに write pointer が追加されます。これは zoned device 対応の基盤となります。NTFS はこのリリースで全面的に書き直され、完全な書き込みサポートと iomap への変換が行われました。Windows マシンのディスクイメージをサーバーにマウントする場合に重要な変更です。
そのほかに知っておきたいストレージ関連の変更として、ユーザー空間のブロックドライバーである ublk に zero-copy I/O が追加されました。io_uring は SCSI passthrough コマンドに対応しました。SED-OPAL self-encrypting drive のサポートには STACK_RESET コマンドと拡張 single user mode が追加されました。direct-access device 用の新しい fs-dax character driver も追加されています。また、VFS は inode->i_ino を unsigned long から u64 に拡張し、32-bit ビルドにおける inode number の上限をなくしました。ネットワークファイルシステムでは、カーネル内 NFS server が sign_fh mount option を使って file handle に署名できるようになり、CIFS client は O_TMPFILE を扱えるようになりました。
ネットワーク: キューのリースとコンテナに提供される機能
ネットワークに関する大きな変更は、ハードウェアキューのリースです。仮想 netdev は、物理 netdev 上の実キューにバインドされたキューをリースし、そのプロキシとして動作できるようになりました。これはコンテナを対象とした機能です。これまでは、AF_XDP（address family express data path。ネットワークスタックを通じてコピーせず、生パケットをユーザー空間に渡すソケット種別）を使用するコンテナに、デバイス全体に近いリソースを割り当てる必要がありました。キューをリースすれば、コンテナはハードウェアキューを1つ取得し、AF_XDP と memory providers をネイティブ速度で実行できます。その間も、ホストは NIC の残りの部分を保持できます。この機能は、io_uring の zero-copy パスにおける AF_XDP サポートと同時に追加されます。
通常の機能として、sockfs のソケットが user.* 拡張属性を受け入れるようになりました。パスベースの AF_UNIX ソケットは、基盤となるファイルシステムから xattr のサポートを継承していました。しかし、sockfs にのみ存在するソケットにはサポートがありませんでした。これで、プロセスはソケットにラベルを付けられます。また、eBPF プログラムはそのラベルでフィルタリングできます。
2 つの機能が削除されました。UDP-Lite は利用者が見つからなかったため廃止されました。IPv6 は loadable module としてビルドできなくなりました。IPv6 を使用する場合は、カーネルに組み込んでビルドします。後者は、どのディストリビューションのカーネルでも実質的に影響しません。一般的なサーバー向けディストリビューションは、すでに IPv6 を組み込んでビルドしているためです。
メモリ管理: swap table の実装が完了
swap の再設計は第 3 段階に入り、この段階で静的な swap map が廃止されます。swap の数は、swap table に直接保持されるようになりました。削減量は静的な swap メタデータの約 30% です。これは、実際に swap が使用されているかどうかにかかわらず、swap device のサイズに比例して kernel が保持するメモリです。小さな swap file では絶対量は少なく、設定する swap が大きいほど増加します。
MGLRU（multi-generational least recently used。新しい page reclaim アルゴリズム）は、ページの young flag を 1 ページずつではなく、バッチ単位で確認できるようになりました。この変更で公表されている数値は、Arm64 32-core server で 60% 超の改善です。ページ単位の処理コストが高い環境ほど、バッチ処理の効果が大きくなります。そのため、この数値は大規模な Arm machine で得られたものです。x86 ではなく Arm VPS を使用している場合、これは 7.1 の変更の中で、自分の測定結果に最も現れやすいものです。ただし、2-core や 4-core で同じ規模の改善になるわけではありません。
このほか、終了中の memory cgroup からの転送がなくなり、khugepaged のスキャンで使用する CPU が減り、maple tree では大きな node の処理を中心に大規模なリファクタリングが行われました。いずれも設定する項目ではありません。system time がわずかに減ったこととして確認できます。
スケジューラー: sched_ext のサブスケジューラーと、デフォルトで有効になった FRED
sched_ext は、BPF プログラムとして CPU スケジューラーを記述し、実行時に読み込める拡張可能なスケジューラークラスです。6.12 で導入されました。7.1 では、サブスケジューラーの基盤となる構造が追加されます。将来的には、control group ごとに独自のスケジューラーで実行できるようになります。この点は注意して読んでください。7.1 では実装はまだ完成しておらず、特に enqueue 処理が未実装です。そのため、現時点で有効化できる機能ではなく、後続リリースに向けた基盤整備です。
Intel FRED (flexible return and event delivery) は、対応ハードウェア上でデフォルトで有効になりました。FRED は、従来の x86 event delivery 処理を、より整理された方式に置き換えます。カーネルには 6.9 から、fred=on boot argument による選択式の機能として含まれていました。デフォルトで有効に変更されたことは、市販ハードウェアで十分なテストが行われたことを示します。これまでに公開された測定値は、I/O 負荷の高いワークロードで 4% から 7% の範囲です。ただし、これらはクライアント向け silicon を Phoronix がテストした結果です。自身のワークロードを測定するまでは、サーバーで同程度の改善を見込まないでください。
Proxy execution では、リモートの lock owner を boost するための donor migration が追加されました。EEVDF では、negative lag に関する修正が行われました。また、high-resolution timer の core は大幅に書き直されました。これらは latency の品質に関する変更であり、設定ファイルから変更できるものではありません。
clone3() における新しいプロセスおよびコンテナ制御
clone3()には3つのフラグが追加されました。いずれも、監視プロセスが長年手作業で回避してきた問題を解消します。CLONE_AUTOREAPを指定すると、子プロセスは終了時に自分自身を回収するため、親プロセスがwait()を呼び出さないままゾンビプロセスとして残りません。CLONE_NNPは、子プロセスの作成時にno_new_privsを設定します。これにより、cloneの実行後に子プロセス自身がフラグを設定するまでの時間差がなくなります。CLONE_PIDFD_AUTOKILLは、子プロセスのライフタイムを親プロセスに返されるpidfdに結び付けます。pidfdを閉じると子プロセスが強制終了するため、監視プロセスが終了しても孤児プロセスが実行中のまま残りません。
マウント名前空間にも同様の機能が追加されました。CLONE_EMPTY_MNTNSをclone3()に指定し、UNSHARE_EMPTY_MNTNSをunshare()に指定すると、何も含まないマウント名前空間を作成できます。通常のように親プロセスのマウントをすべてコピーしてから、ランタイムがアンマウントする必要はありません。FSMOUNT_NAMESPACEを使うと、fsmount()によってファイルシステムを新しい名前空間へ直接配置できます。コンテナランタイムはこれを10年間手作業で組み立ててきました。これを1回の呼び出しで実行できるため、ランタイムはホストのマウントで満たされた名前空間から開始する必要がなくなります。
仮想化関連では、guest_memfdがuserfaultfdをサポートするようになりました。これにより、ハイパーバイザーはゲストのページフォールトをユーザー空間で処理できます。ArmのProtected KVMには匿名メモリのサポートが追加されました。ただし、マージ時の説明では、本番環境で使用できる状態ではないとされています。
カーネル 7.1 はいつサーバーに届くのか
Fedora にはすでに導入されています。Fedora 44 の更新リポジトリは、2026 年 7 月から 8 月にかけて 7.1 系列へ移行しました。Fedora はリリース期間中にカーネルを新しい安定系列へリベースするためです。Arch と openSUSE Tumbleweed にも同じ理由で導入されています。これらはテスト用のマシンであり、サービスを運用するマシンではありません。
それ以外は待つことになります。これは意図された動作です。Debian 13 は 6.12 でリリースされ、リリースのサポート期間中は 6.12 を維持し、修正をバックポートします。RHEL 10 は 6.12.0 でリリースされ、同じ方式を採用しています。Ubuntu 26.04 LTS は 2026 年 4 月に 7.0 でリリースされました。Ubuntu 24.04 LTS には hardware enablement stack があり、後続の Ubuntu リリースから新しいカーネルを LTS に取り込みます。24.04.4 point release の時点では 6.17 で、2026 年 8 月 27 日に予定されている 24.04.5 で 7.0 に移行します。Point release は Ubuntu の新しいバージョンではありません。24.04 にそれまでのすべての更新を組み込んだ新しいインストールメディアです。そのため、すでにパッチを適用しているサーバーで 24.04.5 が変更する内容は、HWE カーネル系列と、それ以外のごくわずかな変更です。
ここで多くの人が誤解します。HWE stack は、最新の interim release が採用するカーネルへ移行します。そのため、上流の系列を完全に飛ばす場合があります。7.0 は Ubuntu LTS に含まれています。一方、7.1 が Ubuntu LTS の基盤になることはないかもしれません。その次の interim release が、より新しい系列を採用するためです。7.1 から LTS に届くのは、使用中の系列へバックポートされた修正です。機能の大部分は取り込まれません。
安定版サーバーで新しいカーネルを使う場合、サポートされる方法は限られています。
# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot
# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot再起動後、実際に起動したカーネルを確認します。
uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-requireduname -r には新しい系列が表示され、dpkg -l にはインストールされたままのすべてのカーネルイメージが表示されます。uname -r に古いバージョンが表示され、dpkg -l に新しいバージョンが表示される場合、パッケージはインストールされていますが、bootloader のデフォルトは変更されていません。GRUB のメニュー項目を確認してください。/var/run/reboot-required が存在する場合、パッケージによってカーネルは更新されたものの、その後に再起動されていません。パッチ適用済みのサーバーが脆弱なコードを実行し続ける理由として、これが最も一般的です。
本番 VPS で 7.1 を追いかけるべきか
いいえ。その理由は、単なる慎重さではありません。ディストリビューションの kernel は、サポート契約の一部です。Canonical、Red Hat、SUSE、Debian は、それぞれ固定された系列にセキュリティ修正を backport し、同時に提供する userspace との組み合わせでテストしています。サードパーティーの archive から取得した mainline kernel や手作業で build した kernel では、機能を得る代わりにその作業を失います。誰もその build に修正を backport してくれないためです。自分で kernel の保守担当になります。
例外はありますが、対象は限定的です。古い kernel では扱えないハードウェアを使う場合、または自分のワークロードで測定した性能変更を、結果に対する責任を負ってでも必要とする場合です。VPS では、前者に該当することはほとんどありません。見えているハードウェアは仮想化されているためです。それ以外では、ディストリビューションの kernel を最新に保ち、再起動を求められたら再起動してください。ディストリビューションの upgrade がすでに予定に入っているなら、Ubuntu 24.04 から 26.04 への移行によって 6.8 から 7.0 へ一度に移行できます。これは、単一の kernel パッケージで得られる更新幅より大きな変更です。
FAQ
使用している VPS の Linux kernel を確認するにはどうすればよいですか？
uname -r を実行します。6.8.0-79-generic のような出力が表示されます。最初のダッシュより前の番号は、ディストリビューションが基にしている upstream の系列です。以降の番号はディストリビューション独自のビルド番号で、backport された修正が含まれます。次に systemd-detect-virt を実行します。lxc または openvz と表示された場合は、コンテナ仮想化を使用しています。この場合はホストの kernel を共有するため、kernel を変更できません。kvm と表示された場合は、自分専用の kernel image で起動しており、アップグレードも自分で行います。
Linux 7.1 は長期サポート kernel ですか？
いいえ。2026 年 8 月 11 日時点で kernel.org に掲載されている長期サポート系列は 6.18、6.12、6.6、6.1、5.15、5.10 であり、7.1 は含まれていません。7.1 は通常の安定版リリースです。次の mainline リリースが公開されると、その stable 系列はまもなく終了します。長年にわたる修正を受けられ、今後も修正が提供される kernel が必要な場合は、すでにディストリビューションの kernel がその役割を担っています。
Ubuntu または Debian はいつ kernel 7.1 をリリースしますか？
デフォルトになる可能性は、おそらくありません。Debian 13 はリリースのサポート期間中、6.12 を使用します。RHEL 10 も 6.12.0 を使用します。Ubuntu 26.04 LTS は 7.0 をリリースしました。Ubuntu の hardware enablement stack は、最新の interim release に含まれる kernel へ移行するため、upstream の系列を完全に飛ばすことがあります。Ubuntu 24.04 LTS では、24.04.5 point release に合わせて、2026 年 8 月 27 日に HWE kernel を 7.0 へ移行する予定です。7.1 の修正は、古い系列への backport として提供されます。通常、新機能は提供されません。
Linux 7.1 で virtual private server に実際に関係する変更は何ですか？
4 つあります。Hardware queue leasing により、コンテナが実際の NIC queue を 1 つ使用し、AF_XDP をネイティブ速度で利用できます。swap rework の第 3 フェーズでは、静的な swap map が削除されます。これにより、kernel が swap device 用に保持する metadata が、報告値で 30% 減少します。MGLRU は page の young flag をバッチ単位で確認できます。公開されている最大の性能向上は、多数のコアを持つ Arm server で確認されています。また clone3() に CLONE_AUTOREAP、CLONE_NNP、CLONE_PIDFD_AUTOKILL が追加され、child process の監視がより安全になりました。Filesystem-level の T10 protection information も追加されましたが、仮想ディスクで必要な integrity metadata が公開されることはほとんどありません。
kernel をアップグレードすると VPS が壊れますか？
一般的な失敗は boot 時に発生します。完全な /boot により、インストール中に update-initramfs が No space left on device で失敗し、パッケージが未設定のまま残ることがあります。sudo apt autoremove --purge で古い kernel を削除してから、再インストールしてください。古い kernel 用にビルドされた out-of-tree module は読み込めなくなります。そのため、DKMS で管理しているものは再ビルドが必要です。再ビルドに失敗しても、実行時に module が見つからなくなるまで気付かないことがあります。また、再起動後も uname -r が古いバージョンを示し、dpkg -l に新しい image が表示される場合、インストール自体は失敗していません。bootloader のデフォルトが変更されていないだけです。