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 matapos ang 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 iba pang 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 ang 7.1 bilang longterm release sa kernel.org. 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 gumagamit ng isa sa mga ito o ng sariling line na pinananatili 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 kasalukuyang kernel release. Sa Ubuntu 24.04, ganito ang itsura 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 libo-libong fix na ibinalik mula sa mas bagong kernel, kaya hindi ito ang code na itinag ni Linus bilang 6.8 noong March 2024. Kaya mas kaunti ang ipinapahiwatig ng “luma ang kernel ko” kaysa sa inaakala. 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 pag-upgrade. Nagpi-print ito ng lxc o openvz sa container virtualisation, kung saan shared ang host kernel. Sa isang container plan, ipinapakita ng uname -r ang kernel ng provider. Walang nababago na maaari mong i-boot kapag nag-install ka ng kernel package, at walang feature sa release na ito ang magiging available sa iyo hanggang hindi nagre-reboot ang provider sa host gamit ang mas bagong kernel. Patakbuhin 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"
  }
]

Iyan ay 6 platform, at wala ni isa sa mga ito ang nagbo-boot ng 7.1. Ang pinakabago ay Ubuntu 26.04 LTS (7.0), na 1 upstream release na mas luma. Ang pinakamatandang suportado pa ay 26 release na mas luma. Ang default GA kernel ng Ubuntu 24.04 ay 13 release na mas luma, at ang Debian 13 at RHEL 10 ay 9 release na mas luma sa 6.12 longterm line. Tinatayang sukatan lamang ang pagbibilang ng release dahil hindi nito isinasaalang-alang ang lahat ng fix na ibinabalik ng mga distribution, pero ipinapakita nito ang lawak ng agwat. Kung pinag-iisipan mo kung alin sa mga ito ang gagamitin, ang trade-off sa pagitan ng LTS at interim release sa isang server ang tunay na desisyon sa likod ng mga numerong ito.

Storage at mga filesystem sa 7.1

Idinagdag sa 7.1 ang kakayahang bumuo at mag-verify ng T10 PI (protection information) sa loob mismo ng filesystem sa halip na sa block layer lamang, kasama ang flexible na suporta para sa T10 alignment. Ang T10 PI ay mga karagdagang byte na nakakabit sa bawat block. Naglalaman ito ng checksum at tag na tumutukoy kung saang block kabilang ang data. Dahil dito, natutukoy ang misdirected write o torn write sa halip na maibalik ito bilang valid na data. Ang pangunahing limitasyon para sa isang VPS tenant ay ang hardware. Kailangang i-expose ng device ang integrity metadata, at karaniwang hindi ito ginagawa 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. Normal na sagot ang error na iyon sa sitwasyong ito, hindi isang fault. Kung gusto mong malaman kung ano talaga ang disk mo bago magbasa pa tungkol sa mga storage feature, unahin ang pagsuri kung NVMe talaga ang VPS disk, at ipinapaliwanag ng pagkakaiba ng NVMe at SATA SSD sa VPS kung bakit nagbabago ang iyong mga numero.

May mga fix ang Btrfs para sa copy-on-write amplification kapag mataas ang memory pressure. May pagbabago rin itong nagpapabilis sa pag-clear ng unang extent sa isang tracked range. Iniulat na 10% ang dagdag na throughput sa sample workload na binanggit ng 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, na may full write support at iomap conversion. Mahalaga ito kung mag-mount ka ng disk image mula sa Windows machine sa iyong server.

Iba pang maliliit ngunit kapaki-pakinabang na storage update: nakakuha ang ublk, ang user-space block driver, ng zero-copy I/O; nakakuha ang io_uring ng mga SCSI passthrough command; nagdagdag 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 hanggang u64, kaya inalis ang ceiling sa inode number sa 32-bit builds. Sa network filesystem naman, maaari nang pirmahan ng in-kernel NFS server ang mga file handle nito gamit ang sign_fh mount option, at natutuhan 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 nito. 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 kinokopya ang mga ito pataas sa network stack) 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. Kasabay nito ang suporta sa AF_XDP sa zero-copy path ng io_uring.

Sa karaniwang paggamit, tumatanggap na ngayon ang mga socket sa sockfs ng user.* extended attributes. Ang isang path-based na AF_UNIX socket ay dati nang nagmana ng suporta sa xattr mula sa filesystem na nasa ilalim nito, ngunit walang ganoong 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 nito. Hindi na maaaring i-build ang IPv6 bilang loadable module: kung kailangan mo ng IPv6, dapat itong i-compile bilang built-in. Hindi makikita ang ikalawang pagbabago sa kernel ng anumang distribution, dahil built-in na ang IPv6 sa mga karaniwang server distribution.

Pamamahala ng memory: tapos na ang swap table

Umabot na sa ikatlong yugto ang pagbabago sa swap. Sa yugtong ito, inaalis ang static swap map. Direktang nasa swap table na ngayon ang bilang ng swap. Ang iniulat na matitipid ay humigit-kumulang 30% ng static swap metadata. Ito ang memory na hinahawakan ng kernel ayon sa laki ng iyong swap device, ginagamit man ang swap o hindi. Sa aktuwal na laki, maliit ito sa maliit na swap file. Lumalaki ito kasabay ng laki ng swap na kino-configure mo.

Maaari na ngayong suriin ng MGLRU (multi-generational least recently used, ang mas bagong algorithm para sa page reclaim) ang young flag ng mga page nang maramihan sa halip na paisa-isang page. Ang iniulat na resulta ng pagbabagong ito ay mahigit 60% improvement sa isang Arm64 32-core server. Pinakamalaki ang pakinabang ng batching kung mataas ang per-page cost. Kaya mula sa malaking Arm machine ang numerong iyon. Kung nagpapatakbo ka ng Arm VPS sa halip na x86, ito ang pagbabagong 7.1 na pinakamalamang makita sa sarili mong measurements, bagaman hindi kasinglaki ng resulta sa dalawang o apat na core.

Kasama rin dito ang pagtanggal sa 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. Walang kailangang i-configure sa mga ito. Mapapansin mo lamang ang mga ito bilang bahagyang pagbawas sa system time.

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

Ang sched_ext, isang extensible scheduler class na nagpapahintulot sa iyong sumulat ng CPU scheduler bilang BPF program at i-load ito habang tumatakbo ang system, ay ipinakilala sa 6.12. Idinagdag sa 7.1 ang pangunahing structure para sa mga sub-scheduler, upang sa hinaharap ay maaaring gumamit ang isang control group ng sarili nitong scheduler. Basahin nang mabuti ang pangungusap na iyon. Hindi pa tapos ang implementation sa 7.1, at partikular na wala pa ang enqueue path. Kaya groundwork pa lamang ito para sa susunod na release, sa halip na feature na maaari mo nang i-enable ngayon.

Naka-enable na 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 malinis na path. Bahagi na ito ng kernel mula pa sa 6.9, ngunit dati itong nasa likod ng fred=on boot argument. Ang pag-enable rito bilang default ay nagpapahiwatig na sapat nang nasubukan ang hardware na inilalabas sa merkado. Ang mga sukat na nailathala hanggang ngayon, na nasa pagitan ng 4% at 7% para sa mga workload na mabigat sa I/O, ay mula sa testing ng Phoronix sa client silicon. Huwag itong isama sa performance budget ng isang server hangga't hindi mo nasusukat ang sarili mong workload.

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

Mga bagong control para sa process at container sa clone3()

May tatlong flag na idinagdag sa clone3(), at bawat isa ay nagsasara ng gap na maraming taon nang manu-manong nilalampasan ng mga supervisor. Awtomatikong nire-reap ng CLONE_AUTOREAP ang child kapag nag-exit ito, 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 ibinabalik sa parent. Kapag isinara ang pidfd, papatayin ang child. Dahil dito, hindi makapag-iiwan ng mga orphan na tumatakbo ang supervisor kapag nag-crash o nag-exit ito.

Ganito rin ang ginawa sa mount namespace. Ang CLONE_EMPTY_MNTNS para sa clone3() at ang UNSHARE_EMPTY_MNTNS para sa unshare() ay lumilikha ng mount namespace na walang laman. Kabaligtaran ito ng karaniwang buong kopya ng mga mount 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 manu-manong binubuo ito ng mga container runtime. Dahil maaari na itong gawin sa isang call, hindi na kailangang magsimula ang runtime sa namespace na puno ng mga mount ng host.

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

Kailan darating ang kernel 7.1 sa server mo

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

Naghihintay ang lahat ng iba pa, at sinadya ang paghihintay na ito. Ipinadala ang Debian 13 kasama ang 6.12 at mananatili ito sa 6.12 habang suportado ang release, na may mga fix na bina-backport dito. Ipinadala ang RHEL 10 kasama ang 6.12.0 at ganoon din ang ginagawa nito. Ipinadala ang Ubuntu 26.04 LTS na may 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 dinadala 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 sa 27 Agosto 2026. Ang point release ay hindi bagong bersyon ng Ubuntu. Pareho pa rin itong 24.04, ngunit kasama na sa bagong install media ang lahat ng update mula nang unang ilabas ito. Kaya ang binabago ng 24.04.5 sa server na regular mo nang ina-update ay ang HWE kernel line at kaunti lamang na iba pa.

Ito ang bahaging madalas napagkakamalian. Lumilipat ang HWE stack sa kernel na dala ng pinakabagong interim release, kaya maaari nitong malaktawan 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 dala ng interim release pagkatapos nito. Ang dumarating sa iyong LTS mula sa 7.1 ay ang mga fix na bina-backport sa line na ginagamit mo. Karamihan sa mga feature ay hindi isinasama.

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 aling kernel ang aktuwal na na-boot:

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

Dapat 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 bersyon 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. Kapag umiiral ang /var/run/reboot-required, nag-upgrade ng kernel ang isang package at wala pang nag-reboot mula noon. Ito ang pinakakaraniwang dahilan kung bakit patuloy na ine-execute ng isang patched server ang vulnerable code.

Dapat bang habulin ang 7.1 sa isang production VPS

Hindi. At ang dahilan ay hindi basta pag-iingat lamang. 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 kasama nilang nire-release. Ang mainline kernel mula sa third-party archive o isang kernel na ikaw mismo ang nag-build ay nagbibigay sa iyo ng mga bagong feature, pero inaalis nito ang gawaing iyon dahil walang nagba-backport ng mga fix sa build mo. Ikaw ang nagiging maintainer ng kernel.

May mga lehitimong exception, pero kakaunti ang mga ito: hardware na hindi kayang patakbuhin ng mas lumang kernel, o performance change na sinukat mo sa sarili mong workload at nais mong gamitin nang sapat para akuin ang mga kahihinatnan. Sa isang 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 nasa listahan mo na ang distribution upgrade, ang paglipat mula Ubuntu 24.04 patungong 26.04 ay magdadala sa iyo mula 6.8 patungong 7.0 sa isang hakbang. Mas malaking talon ito kaysa sa maibibigay ng alinmang iisang 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, at 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 magpi-print ito ng kvm, sarili mong kernel image ang bina-boot mo at ikaw ang kailangang mag-upgrade nito.

Ang Linux 7.1 ba ay isang longterm support kernel?

Hindi. Noong 11 August 2026, ang longterm line na nakalista sa kernel.org ay 6.18, 6.12, 6.6, 6.1, 5.15 at 5.10, at wala rito ang 7.1. Isa itong karaniwang stable release, at inaalis ang stable line nito hindi nagtatagal matapos lumabas ang susunod na mainline release. Kung gusto mo ng kernel na may mga taong naipong fix at may mga taong darating pang fix, 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. Nag-ship ang Ubuntu 26.04 LTS ng 7.0, at lumilipat ang Ubuntu hardware enablement stack sa kernel na dala ng pinakabagong interim release, kaya maaari nitong malaktawan nang buo ang isang upstream line. Nakatakdang ilipat ng Ubuntu 24.04 LTS ang HWE kernel nito sa 7.0 kasama ng 24.04.5 point release noong 27 August 2026. Darating sa iyo ang mga fix mula sa 7.1 bilang mga backport sa mas lumang line. Karaniwan, hindi kasama rito ang mga feature.

Ano sa Linux 7.1 ang aktuwal na mahalaga sa isang virtual private server?

Apat na item. Pinapahintulutan ng hardware queue leasing ang isang container na gumamit ng isang tunay na NIC queue para sa AF_XDP sa native speed. Inaalis ng ikatlong phase ng swap rework ang static swap map at binabawasan ng iniulat na 30% ang metadata na hinahawakan ng kernel para sa iyong swap device. Maaaring suriin ng MGLRU ang page young flag nang maramihan, at ang pinakamalaking nai-publish na gain ay nasa isang many-core Arm server. At nagkaroon ang clone3() ng CLONE_AUTOREAP, CLONE_NNP at CLONE_PIDFD_AUTOKILL, na nagpapaligtas sa pag-supervise ng mga child process. Naidagdag din ang filesystem-level T10 protection information, pero bihirang ilantad ng virtual disk ang integrity metadata na kailangan nito.

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

Karaniwang nangyayari ang mga failure sa boot. Kapag puno ang /boot, mabibigo ang update-initramfs na may No space left on device habang nag-i-install, kaya mananatiling kalahating naka-configure ang package: alisin ang mga lumang kernel gamit ang sudo apt autoremove --purge, pagkatapos ay muling i-install. Hihinto sa pag-load ang mga out-of-tree module na binuo para sa lumang kernel, kaya kailangang mag-rebuild ang anumang pinamamahalaan ng DKMS, at hindi agad mapapansin ang failed rebuild hanggang sa mawala ang module habang runtime. At kung ang uname -r ay nag-uulat pa rin ng lumang version matapos ang reboot habang inililista ng dpkg -l ang bagong image, walang nasirang bahagi sa installation: hindi nailipat ang default ng bootloader.