Ano ang bago sa Linux kernel 7.1 para sa server

Ano ang bago sa Linux kernel 7.1

Inilabas ang Linux kernel 7.1 noong 14 June 2026, siyam na linggo pagkatapos ng 7.0. Para sa tenant ng VPS (virtual private server), ang mahahalagang pagbabago ay nasa apat na bahagi: storage at filesystems, networking, memory management, at process at container control. Karamihan sa natitirang bahagi ng release ay para sa desktop at graphics, na hindi nilo-load ng headless server.

May isa pang sagot na kailangan mo munang malaman. Halos tiyak na hindi tumatakbo ang 7.1 sa server mo, at matatagalan bago ito maging ganoon. Hindi nakalista sa kernel.org ang 7.1 bilang longterm release. Noong 11 August 2026, ang mga longterm line ay 6.18, 6.12, 6.6, 6.1, 5.15 at 5.10, at ang bawat mainstream server distribution ay nakabatay sa isa sa mga ito o sa sariling line na mina-maintain nito. Magkaiba nang ilang taon ang “bago sa kernel” at “bago sa server mo,” kaya saklaw ng gabay na ito ang dalawang bahagi.

Aling kernel ang kasalukuyang pinapatakbo ng iyong VPS

uname -r
uname -srm
systemd-detect-virt

Ang uname -r ay nagpi-print ng release ng kernel na kasalukuyang tumatakbo. Sa Ubuntu 24.04, ganito ang hitsura nito: 6.8.0-79-generic. Ang bahagi bago ang unang dash ay ang upstream line. Ang lahat ng kasunod nito ay sariling build number ng iyong distribution, at hindi ito sumusunod sa upstream. Ang 6.8.0-79 ng Canonical ay may dalang libo-libong fix na ibina-backport mula sa mga mas bagong kernel, kaya hindi ito ang code na tinag ni Linus bilang 6.8 noong March 2024. Dahil dito, kulang ang ibig sabihin ng pahayag na “luma ang kernel ko.” Luma ang mga feature. Karaniwan namang hindi luma ang security fix.

Sinasabi ng systemd-detect-virt kung maaari mong palitan ang kernel. Nagpi-print ito ng kvm sa isang full virtual machine, kung saan ikaw ang nagbo-boot ng sarili mong kernel image at tunay na upgrade ang isang upgrade. Nagpi-print ito ng lxc o openvz sa container virtualisation, kung saan shared ang kernel ng host. Sa isang container plan, ipinapakita ng uname -r ang kernel ng provider. Walang nababago sa anumang kernel na maaari mong i-boot kapag nag-install ka ng kernel package. Hindi rin magiging available sa iyo ang anumang feature sa release na ito hanggang sa mag-reboot ang provider ng host gamit ang mas bagong kernel. Isagawa ang check na ito bago ka magplano ng anumang kernel work.

[
  {
    "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"
  }
]

May 6 platform, at wala sa mga ito ang nagbo-boot ng 7.1. Ang pinakabago ay ang Ubuntu 26.04 LTS (7.0), na 1 upstream release na mas luma. Ang pinakamatandang suportado pa rin ay 26 release na mas luma. Ang default GA kernel ng Ubuntu 24.04 ay 13 release na mas luma, habang ang Debian 13 at RHEL 10 ay 9 release na mas luma sa 6.12 longterm line. Tinatantiya lamang ng pagbibilang ng releases ang agwat, dahil hindi nito isinasaalang-alang ang lahat ng bina-backport ng mga distribution, ngunit ipinapakita nito ang kabuuang hugis ng agwat. Kung pinag-iisipan mo kung alin sa mga ito ang gagamitin, ang trade-off ng LTS laban sa interim release sa isang server ang tunay na desisyong nasa likod ng mga numerong ito.

Storage at mga filesystem sa 7.1

Sa 7.1, maaari nang bumuo at mag-verify ng T10 PI (protection information) sa loob ng filesystem sa halip na sa block layer lamang. May flexible support din ito para sa T10 alignment. Ang T10 PI ay mga karagdagang byte na ikinakabit sa bawat block. Naglalaman ito ng checksum at tag na tumutukoy kung saang block kabilang ang data. Dahil dito, natutukoy ang misdirected o torn write sa halip na maibalik ito bilang valid na data. Para sa VPS tenant, hardware ang pangunahing limitasyon. Kailangang i-expose ng device ang integrity metadata, ngunit karaniwang hindi ito ipinapakita ng virtual disk.

ls /sys/block/vda/integrity/

Sa karamihan ng VPS disk, nagbabalik ito ng No such file or directory, dahil ginagawa lamang ng block layer ang directory na integrity kapag nag-register ang device ng integrity support. Karaniwan ang error na ito sa sitwasyong ito at hindi ito fault. Kung gusto mong malaman kung ano talaga ang disk mo bago magbasa pa tungkol sa storage features, unahin ang pagsuri kung NVMe talaga ang VPS disk, at ipinapaliwanag ng pagkakaiba ng NVMe at SATA SSD sa VPS kung bakit nagbabago ang mga numerong makukuha mo.

Nakakakuha ang Btrfs ng mga fix para sa copy-on-write amplification kapag kapos ang memory, pati ng pagbabagong nagpapabilis sa pag-clear ng unang extent sa isang tracked range. Iniulat na 10% ang dagdag na throughput sa sample workload na binanggit sa merge. Hindi na minamarkahan bilang experimental ang shutdown operation nito. Pinahusay ng XFS ang zero range flushing at lookup sa pamamagitan ng iomap. Nagdagdag din ito ng write pointer sa real-time group geometry, na nagsisilbing pundasyon para sa mga zoned device. Kumpletong rewrite ang NTFS sa release na ito, kasama ang full write support at iomap conversion. Mahalaga ito kung ikakabit mo sa server ang disk image mula sa Windows machine.

Narito ang iba pang maliliit ngunit kapaki-pakinabang na storage update: nagkaroon ng zero-copy I/O ang ublk, ang user-space block driver; nagkaroon ang io_uring ng SCSI passthrough commands; nakakuha ang SED-OPAL self-encrypting drive support ng STACK_RESET command at extended single user mode; may bagong fs-dax character driver para sa direct-access devices; at pinalawak ng VFS ang inode->i_ino mula unsigned long tungo sa u64, kaya inalis ang inode number ceiling sa 32-bit builds. Para sa network filesystem, maaari nang pirmahan ng in-kernel NFS server ang mga file handle nito gamit ang sign_fh mount option, at natutunan ng CIFS client ang O_TMPFILE.

Networking: pag-upa ng queue, at mga benepisyo nito sa isang container

Ang pangunahing pagbabago sa networking ay ang hardware queue leasing. Maaari nang umupa ang isang virtual netdev ng queue na naka-bind sa isang aktuwal na queue sa isang physical netdev, at magsilbing proxy para rito. Para ito sa mga container. Dati, ang container na nangangailangan ng AF_XDP (address family express data path, ang socket type na naghahatid ng mga raw packet sa user space nang hindi ipinapadaan ang mga ito sa network stack para kopyahin) ay kailangang bigyan ng halos buong device. Sa leased queue, nakakakuha ito ng isang hardware queue, nagpapatakbo ng AF_XDP at memory providers sa native speed, at napapanatili ng host ang natitirang bahagi ng NIC. Idinagdag din ito kasabay ng suporta sa AF_XDP sa zero-copy path ng io_uring.

Sa karaniwang paggamit naman, tumatanggap na ngayon ang mga socket sa sockfs ng user.* extended attributes. Ang path-based na AF_UNIX socket ay dati nang nagmamana ng xattr support mula sa filesystem na nasa ilalim nito, ngunit walang ganitong suporta ang socket na nasa sockfs lamang. Ngayon, maaaring lagyan ng label ng isang process ang socket, at maaaring mag-filter ang isang eBPF program batay sa label na iyon.

Dalawang feature ang inalis. Wala na ang UDP-Lite dahil walang gumagamit dito. Hindi na maaaring i-build ang IPv6 bilang loadable module: kung kailangan mo ng IPv6, dapat itong i-compile in. Hindi mapapansin ang ikalawang pagbabago sa kernel ng anumang distribution, dahil ang karaniwang server distributions ay nagbu-build na ng IPv6 bilang built-in.

Pamamahala ng memory: tapos na ang swap table

Pumapasok sa ikatlong phase ang rework ng swap, at inaalis ng phase na ito ang static swap map. Nasa swap table na mismo ang bilang ng swap. Ang naiulat na matitipid ay humigit-kumulang 30% ng static swap metadata. Memory ito na pinapanatili ng kernel ayon sa laki ng swap device mo, may nagaganap mang swapping o wala. Sa absolute na halaga, maliit ito sa maliit na swap file. Lumalaki ito kasabay ng laki ng swap na kino-configure mo.

Maaari nang suriin ng MGLRU (multi-generational least recently used, ang mas bagong page reclaim algorithm) ang young flag ng mga page nang batch sa halip na paisa-isa. Ang nai-publish na resulta para sa pagbabagong ito ay higit sa 60% improvement sa isang Arm64 32-core server. Pinakamalaki ang pakinabang ng batching kung mataas ang per-page cost. Kaya nakuha ang numerong iyon sa isang malaking Arm machine. Kung nagpapatakbo ka ng Arm VPS sa halip na x86, ito ang pagbabagong nasa 7.1 na pinakamalamang makita sa sarili mong measurements, bagama't hindi sa ganoong laki sa two o four cores.

Kasama rin dito ang pag-alis ng transfers mula sa dying memory cgroups, mas kaunting CPU sa mga scan ng khugepaged, at malaking refactor sa maple tree para sa paghawak nito ng malalaking node. Wala sa mga ito ang kailangan mong i-configure. Mapapansin mo ang mga ito bilang bahagyang mas kaunting system time.

Mga scheduler: mga sub-scheduler ng sched_ext, at naka-enable na bilang default ang FRED

Dumating ang sched_ext, ang extensible scheduler class na nagbibigay-daan sa pagsulat ng CPU scheduler bilang BPF program at pag-load nito habang tumatakbo ang system, sa 6.12. Idinagdag sa 7.1 ang pangunahing structure para sa mga sub-scheduler, upang sa kalaunan ay makatakbo ang isang control group gamit ang sarili nitong scheduler. Basahin nang mabuti ang pangungusap na iyon. Hindi pa tapos ang implementation sa 7.1, at partikular na kulang ang enqueue path. Kaya groundwork ito para sa susunod na release, hindi isang feature na maaari mong i-enable ngayon.

Naka-enable na ngayon bilang default ang Intel FRED (flexible return and event delivery) sa hardware na sumusuporta rito. Pinapalitan ng FRED ang legacy x86 event delivery path ng mas maayos na path. Kasama na ito sa kernel mula pa noong 6.9, pero dati itong nakatago sa likod ng fred=on boot argument. Ang pag-enable rito bilang default ay nagpapahiwatig na sapat nang nasubukan ang mga shipping hardware. Ang mga measurement na nailathala hanggang ngayon, na nasa range na 4% hanggang 7% para sa I/O-heavy workload, ay mula sa Phoronix testing sa client silicon. Kaya huwag mong isama ang gain na iyon sa server budget hangga't hindi mo nasusukat ang sarili mong workload.

Nagdagdag ang proxy execution ng donor migration para sa pag-boost ng remote lock owner. Nakatanggap ang EEVDF ng mga fix para sa negative lag. Malaki rin ang isinagawang rewrite sa high-resolution timer core. Mga pagbabago ito sa latency quality na walang inilalantad na configuration file.

Mga bagong process at container control sa clone3()

Tatlong flag ang idinagdag sa clone3(), at bawat isa ay nagsasara ng puwang na ilang taon nang mano-manong nilulutas ng mga supervisor. Ginagawa ng CLONE_AUTOREAP na ang child ang mag-reap sa sarili nito kapag nag-exit, kaya hindi ito nagiging zombie na naghihintay sa parent na maaaring hindi kailanman tumawag sa wait(). Itinatakda ng CLONE_NNP ang no_new_privs sa child sa oras ng paglikha nito. Isinasara nito ang pagitan mula sa clone hanggang sa oras na itakda ng child ang flag para sa sarili nito. Itinatali ng CLONE_PIDFD_AUTOKILL ang lifetime ng child sa pidfd na ibinalik sa parent: kapag isinara ang pidfd, papatayin ang child. Dahil dito, hindi makapag-iiwan ng mga orphan na tumatakbo ang supervisor kapag nag-crash ito.

Ganito rin ang ginawa sa mount namespaces. Ang CLONE_EMPTY_MNTNS para sa clone3() at ang UNSHARE_EMPTY_MNTNS para sa unshare() ay lumilikha ng mount namespace na walang laman. Hindi ito gumagamit ng karaniwang buong kopya ng mounts ng parent na kailangan pang i-unmount ng runtime. Hinahayaan ng FSMOUNT_NAMESPACE ang fsmount() na direktang maglagay ng filesystem sa bagong namespace. Isang dekada nang mano-manong binubuo ito ng container runtimes. Dahil maisasagawa na ito sa isang call, hindi na kailangang magsimula ang runtime sa namespace na puno ng mounts ng host.

Sa virtualisation naman, sinusuportahan na ngayon ng guest_memfd ang userfaultfd, kaya maaaring pangasiwaan ng hypervisor mula sa user space ang mga page fault ng guest. Nagkaroon din ng suporta sa anonymous memory ang Protected KVM sa Arm. Ayon sa mismong merge, hindi pa ito handa para sa production.

Kailan darating ang kernel 7.1 sa server mo

Mayroon na nito ang Fedora. Lumipat sa 7.1 series ang Fedora 44 update repository noong Hulyo at Agosto 2026 dahil nire-rebase ng Fedora ang kernel nito sa mga bagong stable line sa loob ng isang release. Mayroon na rin nito ang Arch at openSUSE Tumbleweed sa parehong dahilan. Mga machine ang mga ito para sa testing, hindi para patakbuhin ang iyong mga serbisyo.

Naghihintay ang lahat ng iba pa, at sinadya ang paghihintay na ito. Nag-ship ang Debian 13 kasama ang 6.12 at mananatili ito sa 6.12 habang suportado ang release, kasama ang mga fix na bina-backport dito. Nag-ship ang RHEL 10 kasama ang 6.12.0 at ganoon din ang ginagawa nito. Nag-ship ang Ubuntu 26.04 LTS ng 7.0 noong Abril 2026. May hardware enablement stack ang Ubuntu 24.04 LTS. Kumukuha ito ng mas bagong kernel mula sa mga susunod na Ubuntu release at inilalagay ito sa LTS. Nasa 6.17 ang stack na iyon simula sa 24.04.4 point release, at nakatakda itong lumipat sa 7.0 kasama ng 24.04.5 noong 27 Agosto 2026.

Ito ang bahaging madalas mali ang pagkaunawa ng mga tao. Lumilipat ang HWE stack sa kernel na dala ng pinakabagong interim release, kaya maaari nitong laktawan nang buo ang isang upstream line. Nasa Ubuntu LTS ang 7.0. Maaaring hindi kailanman maging base ng isang Ubuntu LTS ang 7.1 dahil mas bagong line ang dadalhin ng interim release na susunod dito. Ang makakarating sa iyong LTS mula sa 7.1 ay ang mga fix na bina-backport sa line na ginagamit mo. Kadalasan, hindi napapasa ang mga feature.

Kung gusto mo talaga ng mas bagong kernel sa isang stable server, kakaunti ang supported na paraan.

# 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

Pagkatapos ng reboot, tingnan kung ano talaga ang na-boot mo:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

Dapat ay ipakita na ngayon ng uname -r ang bagong line, at ipinapakita ng dpkg -l ang lahat ng kernel image na naka-install pa rin. Kung ipinapakita ng uname -r ang lumang version habang inililista ng dpkg -l ang bago, na-install ang package ngunit hindi nagbago ang default ng bootloader: tingnan ang mga entry sa GRUB menu. Ang pagkakaroon ng /var/run/reboot-required ay nangangahulugang nag-upgrade ng kernel ang isang package at wala pang nagre-reboot mula noon. Ito ang pinakakaraniwang dahilan kung bakit patuloy pa ring ine-execute ng isang patched server ang vulnerable code.

Dapat mo bang habulin ang 7.1 sa isang production VPS

Hindi. At hindi ito dahil sa pag-iingat para lamang makaiwas sa panganib. Ang distribution kernel ay bahagi ng support contract. Ang Canonical, Red Hat, SUSE, at Debian ay nagba-backport ng mga security fix sa kani-kanilang frozen line at tine-test ang mga ito laban sa userspace na kasamang ipinapadala nila. Kapag gumamit ka ng mainline kernel mula sa third-party archive o sarili mong build, makukuha mo ang mga feature pero mawawala ang gawaing iyon, dahil walang nagba-backport ng mga fix sa build mo. Ikaw na ang magiging maintainer ng kernel.

May mga tunay ngunit limitadong exception: hardware na hindi kayang i-drive ng mas lumang kernel, o performance change na nasukat mo sa sarili mong workload at sapat ang pakinabang para akuin mo ang mga consequence. Sa VPS, halos hindi naaangkop ang unang kaso dahil virtual ang hardware na nakikita mo. Para sa lahat ng iba pa, panatilihing updated ang distribution kernel at mag-reboot kapag hinihingi nito. Kung kasama na sa listahan mo ang distribution upgrade, dadalhin ka ng paglipat mula Ubuntu 24.04 patungong 26.04 mula 6.8 tungo sa 7.0 sa isang hakbang. Mas malaking pagtalon ito kaysa sa karaniwang naibibigay ng isang kernel package.

FAQ

Paano ko susuriin kung aling Linux kernel ang ginagamit ng aking VPS?

Patakbuhin ang uname -r. Magpi-print ito ng gaya ng 6.8.0-79-generic. Ang numero bago ang unang dash ang upstream line na pinagbabatayan ng build ng iyong distribution. Ang lahat ng kasunod nito ang sariling build number ng distribution, na naglalaman ng mga backported fix. Pagkatapos, patakbuhin ang systemd-detect-virt. Kung magpi-print ito ng lxc o openvz, gumagamit ka ng container virtualisation, nakikihati ka sa kernel ng host, at hindi mo ito maaaring palitan. Kung kvm naman ang ma-print nito, sarili mong kernel image ang bino-boot mo at ikaw ang dapat magpatupad ng mga upgrade nito.

Longterm support kernel ba ang Linux 7.1?

Hindi. Noong 11 August 2026, ang mga longterm line na nakalista sa kernel.org ay 6.18, 6.12, 6.6, 6.1, 5.15 at 5.10, at wala sa mga ito ang 7.1. Normal stable release ito, at inaalis ang stable line nito pagkalipas ng maikling panahon matapos lumabas ang susunod na mainline release. Kung kailangan mo ng kernel na maraming taong fixes na ang nakaraan at marami pang darating, iyon na ang kernel ng iyong distribution.

Kailan maglalabas ang Ubuntu o Debian ng kernel 7.1?

Malamang, hindi ito magiging default. Mananatili ang Debian 13 sa 6.12 habang suportado ang release, at mananatili ang RHEL 10 sa 6.12.0. May 7.0 ang Ubuntu 26.04 LTS nang ilabas ito, at lumilipat ang Ubuntu hardware enablement stack sa kernel na dala ng pinakabagong interim release. Dahil dito, maaari nitong malaktawan nang buo ang isang upstream line. Nakatakdang ilipat ng Ubuntu 24.04 LTS ang HWE kernel nito sa 7.0 sa point release na 24.04.5 sa 27 August 2026. Darating sa iyo ang mga fix mula sa 7.1 bilang backport sa mas lumang line. Karaniwang hindi kasama rito ang mga feature.

Ano sa Linux 7.1 ang talagang mahalaga sa isang virtual private server?

Apat na item. Hinahayaan ng hardware queue leasing ang isang container na gumamit ng isang totoong NIC queue para sa AF_XDP sa native speed. Inaalis ng ikatlong phase ng swap rework ang static swap map at binabawasan nito nang 30%, ayon sa naiulat, ang metadata na hinahawakan ng kernel para sa iyong swap device. Maaaring suriin ng MGLRU ang page young flags nang batch-batch, na may pinakamalaking naiulat na gain sa isang Arm server na maraming core. At nagkaroon ang clone3() ng CLONE_AUTOREAP, CLONE_NNP at CLONE_PIDFD_AUTOKILL, na nagpapaligtas sa pag-supervise ng mga child process. Naisama rin ang T10 protection information sa filesystem level, ngunit bihirang ilantad ng virtual disk ang integrity metadata na kailangan nito.

Masisira ba ang aking VPS kapag nag-upgrade ako ng kernel?

Sa boot karaniwang nangyayari ang mga failure. Kapag puno ang /boot, mabibigo ang update-initramfs gamit ang No space left on device habang nag-i-install, at maiiwang half-configured ang package. Alisin ang mga lumang kernel gamit ang sudo apt autoremove --purge, pagkatapos ay i-reinstall ito. Hindi na naglo-load ang mga out-of-tree module na ginawa para sa lumang kernel. Kaya kailangang mag-rebuild ang anumang pinamamahalaan ng DKMS, at hindi mapapansin ang failed rebuild hanggang sa mawala ang module habang runtime. Kung luma pa rin ang version na nire-report ng uname -r pagkatapos ng reboot habang bagong image naman ang inililista ng dpkg -l, walang nasira sa installation. Hindi nagbago ang default ng bootloader.