Що нового в Linux kernel 7.1 для серверів

Що нового в Linux kernel 7.1

Linux kernel 7.1 випущено 14 June 2026, через дев’ять тижнів після 7.0. Для орендаря VPS (virtual private server) важливі зміни стосуються чотирьох сфер: сховищ і файлових систем, мереж, керування пам’яттю, а також керування процесами та контейнерами. Решта випуску здебільшого присвячена настільним системам і графіці, які headless-сервер не завантажує.

Спочатку потрібно врахувати ще один момент. На вашому сервері майже напевно не працює 7.1, і це ще довго не зміниться. kernel.org не вказує 7.1 як longterm-випуск. Станом на 11 August 2026 longterm-гілками є 6.18, 6.12, 6.6, 6.1, 5.15 і 5.10, а всі основні серверні дистрибутиви будуються на одній із них або на гілці, яку вони підтримують самостійно. «Нове в ядрі» та «нове на вашому сервері» розділяють роки, тому цей посібник охоплює обидві частини.

Яке ядро зараз використовується на вашому VPS

uname -r
uname -srm
systemd-detect-virt

uname -r виводить реліз запущеного ядра. В Ubuntu 24.04 це має такий вигляд: 6.8.0-79-generic. Частина до першого дефіса — це основна upstream-гілка. Усе після неї — власний номер збірки дистрибутива, який взагалі не відображає актуальний стан upstream. Ядро Canonical 6.8.0-79 містить тисячі виправлень, перенесених із новіших ядер, тому це не той самий код, який Linus позначив як 6.8 у березні 2024 року. Тому твердження «моє ядро старе» не повністю передає ситуацію. Функції можуть бути старими. Виправлення безпеки зазвичай — ні.

systemd-detect-virt показує, чи можете ви взагалі змінити ядро. На повній віртуальній машині воно виводить kvm: ви завантажуєте власний образ ядра, і оновлення справді змінює ядро. У контейнерній віртуалізації воно виводить lxc або openvz, оскільки використовується спільне ядро хоста. У контейнерному тарифі uname -r показує ядро провайдера, а встановлення пакета ядра нічого не змінює в тому, що можна завантажити. Жодна функція цього релізу не буде вам доступна, доки провайдер не перезавантажить хост із новішим ядром. Виконайте цю перевірку перед плануванням будь-яких робіт із ядром.

[
  {
    "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 платформ, і жодна з них не завантажує 7.1. Найновіша — Ubuntu 26.04 LTS (7.0), яка відстає від upstream на 1 реліз. Найстаріша платформа, яка все ще підтримується, відстає на 26 релізів. Стандартне GA-ядро Ubuntu 24.04 відстає на 13 релізів, а Debian 13 і RHEL 10 відстають на 9 релізи, використовуючи гілку 6.12 longterm. Підрахунок релізів є приблизним показником, оскільки він не враховує всі виправлення, перенесені дистрибутивами, але показує масштаб розриву. Якщо ви обираєте, яку з цих платформ використовувати, рішення щодо компромісу між LTS і проміжним релізом на сервері є основою наведених чисел.

Сховища та файлові системи у версії 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, а різниця між NVMe та SSD SATA на VPS пояснює, чому відповідь змінює ваші показники.

Btrfs отримує виправлення для зростання обсягу операцій копіювання під час запису за умов нестачі пам’яті, а також зміну, яка пришвидшує очищення першого extent у відстежуваному діапазоні. Для тестового робочого навантаження, зазначеного в описі merge, повідомляється про приріст пропускної здатності на 10%. Операцію завершення роботи більше не позначають як експериментальну. XFS покращує скидання нульового діапазону та пошук через iomap і додає вказівник запису до геометрії груп реального часу. Це є основою для підтримки zoned-пристроїв. NTFS у цьому випуску повністю переписано. Реалізовано повну підтримку запису та перехід на iomap. Це важливо, якщо вам коли-небудь потрібно буде змонтувати на сервері образ диска з Windows-комп’ютера.

Серед інших важливих змін у роботі зі сховищами: ublk, блоковий драйвер користувацького простору, отримав I/O без копіювання; io_uring отримав команди наскрізної передачі SCSI; підтримка самошифрованих дисків SED-OPAL отримала команду STACK_RESET і розширений однокористувацький режим; з’явився новий символьний драйвер fs-dax для пристроїв із прямим доступом; а VFS розширила inode->i_ino з unsigned long до u64, що усуває обмеження на номер inode у 32-бітних збірках. У мережевих файлових системах вбудований NFS-сервер тепер може підписувати дескриптори файлів за допомогою параметра монтування sign_fh, а клієнт CIFS отримав O_TMPFILE.

Мережа: оренда черг і можливості для контейнера

Головна зміна в мережевій підсистемі — оренда апаратних черг. Віртуальний netdev тепер може орендувати чергу, прив’язану до реальної черги фізичного netdev, і працювати як її проксі. Це потрібно насамперед контейнерам. Раніше контейнеру, якому був потрібен AF_XDP (address family express data path — тип сокетів, що передає необроблені пакети в user space без копіювання через мережевий стек), доводилося надавати майже весь пристрій. Тепер орендована черга надає йому одну апаратну чергу: контейнер запускає AF_XDP і memory providers на нативній швидкості, а хост зберігає решту NIC. Це доповнює підтримку AF_XDP у zero-copy path io_uring.

У звичайнішій частині змін сокети в sockfs тепер приймають user.* розширені атрибути. Сокет AF_UNIX, доступний через шлях, уже успадковував підтримку xattr від файлової системи, на якій він зберігався. Але сокет, що існував лише в sockfs, такої підтримки не мав. Тепер процес може додати до сокета мітку, а програма eBPF може фільтрувати сокети за цією міткою.

Два компоненти вилучено. UDP-Lite більше немає, оскільки ним ніхто не користувався. IPv6 більше не можна збирати як loadable module: якщо потрібен IPv6, його потрібно вбудувати в ядро. Друга зміна непомітна в ядрах дистрибутивів, оскільки поширені серверні дистрибутиви вже вбудовують IPv6 у ядро.

Керування пам’яттю: таблицю swap завершено

Перероблення swap переходить до третьої фази. На цьому етапі статичну карту swap видалено. Тепер кількість swap безпосередньо зберігається в таблиці swap. Заявлена економія становить приблизно 30% статичних метаданих swap. Це пам’ять, яку kernel утримує пропорційно до розміру пристрою swap незалежно від того, чи використовуються дані в swap. В абсолютних значеннях на невеликому swap-файлі це небагато. Обсяг економії зростає разом із налаштованим swap.

MGLRU (multi-generational least recently used, новіший алгоритм reclaim сторінок) тепер може перевіряти прапорець young на сторінках пакетами, а не по одній сторінці. В опублікованих результатах зазначено покращення більш ніж на 60% на 32-ядерному сервері Arm64. Пакетна обробка найбільше допомагає там, де вартість обробки кожної сторінки найвища. Саме тому це значення отримали на потужній Arm-системі. Якщо ви використовуєте Arm VPS замість x86 VPS, саме ця зміна у 7.1 найімовірніше буде помітною у ваших вимірюваннях, хоча на системах із двома або чотирма ядрами результат не буде таким самим.

Також усунуто перенесення даних із memory cgroups, що завершуються. Процес khugepaged сканує пам’ять із меншим навантаженням на CPU. Maple tree зазнав масштабного рефакторингу для роботи з великими вузлами. Налаштовувати нічого з цього не потрібно. Ви можете помітити лише дещо менший system time.

Планувальники: субпланувальники sched_ext і FRED за замовчуванням

sched_ext — розширюваний клас планувальників, який дає змогу написати планувальник CPU як програму BPF і завантажити її під час роботи системи. Він з’явився у версії 6.12. У версії 7.1 додано базову структуру для субпланувальників. У майбутньому це дасть змогу групі керування працювати під власним планувальником. Зверніть увагу на формулювання. У версії 7.1 реалізацію ще не завершено. Зокрема, відсутній шлях постановки задач у чергу. Тому це підготовча робота для наступного випуску, а не функція, яку вже можна ввімкнути.

Intel FRED (flexible return and event delivery) тепер увімкнено за замовчуванням на апаратному забезпеченні, яке його підтримує. FRED замінює застарілий шлях доставки подій x86 на простіший механізм. У ядрі він доступний починаючи з версії 6.9, але раніше потребував аргументу завантаження fred=on. Увімкнення FRED за замовчуванням означає, що підтримуване апаратне забезпечення вже достатньо протестоване. Опубліковані результати вимірювань, у межах від 4% до 7% для навантажень із великою кількістю операцій I/O, отримано під час тестування Phoronix на клієнтських процесорах. Тому не закладайте такі показники для сервера, доки не виміряєте власне навантаження.

Proxy execution отримав міграцію донора для підвищення пріоритету віддаленого власника блокування. EEVDF отримав виправлення для випадків із від’ємним lag. Ядро високоточного таймера також суттєво переписано. Це зміни, що покращують характеристики затримок, але не мають параметрів у конфігураційних файлах.

Нові засоби керування процесами та контейнерами в clone3()

До clone3() додали три прапорці. Кожен із них усуває проблему, яку супервізори роками обходили вручну. CLONE_AUTOREAP змушує дочірній процес самостійно завершувати прибирання після виходу, тому він не стає zombie і не очікує на батьківський процес, який може ніколи не викликати wait(). CLONE_NNP встановлює no_new_privs для дочірнього процесу під час створення. Це усуває проміжок між викликом clone і моментом, коли дочірній процес встановлює цей прапорець самостійно. CLONE_PIDFD_AUTOKILL пов’язує час життя дочірнього процесу з pidfd, повернутим батьківському процесу: після закриття pidfd дочірній процес завершується. Тому супервізор, який завершив роботу, не може залишити запущені orphan-процеси.

Для mount namespace додали такі самі можливості. CLONE_EMPTY_MNTNS для clone3() і UNSHARE_EMPTY_MNTNS для unshare() створюють mount namespace порожнім, а не як звичайну повну копію mount namespace батьківського процесу, з якої runtime потім має демонтувати непотрібні файлові системи. FSMOUNT_NAMESPACE дає змогу fsmount() одразу розмістити файлову систему в новому namespace. Протягом десятиліття container runtime збирали цю схему вручну. Тепер один виклик дає змогу runtime не починати роботу з namespace, заповненого mount хоста.

У частині віртуалізації guest_memfd тепер підтримує userfaultfd. Тому hypervisor може обробляти page fault гостьової системи з user space. Protected KVM на Arm отримав підтримку anonymous memory. У самому merge зазначено, що ця можливість ще не готова для production.

Коли kernel 7.1 з’явиться на вашому сервері

Fedora вже має його. Репозиторій оновлень Fedora 44 перейшов на серію 7.1 у липні та серпні 2026 року, оскільки Fedora переводить kernel на нові стабільні гілки в межах одного випуску. Arch і openSUSE Tumbleweed мають його з тієї самої причини. Це системи для тестування, а не для розміщення ваших сервісів.

Усі інші системи чекають, і це передбачено політикою випуску. Debian 13 вийшов із версією 6.12 і використовує 6.12 протягом усього життєвого циклу випуску, додаючи до нього backport виправлень. RHEL 10 вийшов із версією 6.12.0 і працює так само. Ubuntu 26.04 LTS вийшов із версією 7.0 у квітні 2026 року. Ubuntu 24.04 LTS має hardware enablement stack, який переносить новішу версію kernel із пізніших випусків Ubuntu до LTS. Станом на point release 24.04.4 цей stack використовує версію 6.17. У 24.04.5, випуск якого заплановано на 27 серпня 2026 року, він має перейти на 7.0. Point release — це не нова версія Ubuntu, а та сама 24.04, до якої додано всі оновлення з моменту випуску та які включено до нового інсталяційного носія. Тому що 24.04.5 змінює на сервері, який ви вже оновлюєте — це лінія HWE kernel і майже нічого більше.

Ось у чому часто помиляються. HWE stack переходить на ту версію kernel, яку містить найновіший проміжний випуск, тому окрема upstream-гілка може бути повністю пропущена. Версія 7.0 входить до Ubuntu LTS. Версія 7.1 може ніколи не стати базовою для LTS, оскільки наступний проміжний випуск міститиме новішу гілку. До вашої LTS із версії 7.1 потрапляють виправлення, які backport-ять у гілку, що ви використовуєте. Більшість функцій залишається в новішій гілці.

Якщо вам потрібна новіша версія kernel на стабільному сервері, кількість підтримуваних варіантів невелика.

# 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-required

uname -r тепер має показувати нову гілку, а dpkg -l — усі встановлені kernel image. Якщо uname -r показує стару версію, а dpkg -l містить нову, пакет встановлено, але типовий запис bootloader не змінився: перевірте пункти меню GRUB. Наявність /var/run/reboot-required означає, що пакет оновив kernel, але після цього систему ще не перезавантажували. Це найпоширеніша причина, через яку пропатчений сервер досі виконує вразливий код.

Чи варто встановлювати 7.1 на production VPS

Ні, і причина не лише в обережності заради обережності. Kernel дистрибутива — це угода про підтримку. Canonical, Red Hat, SUSE і Debian переносять security fixes до своїх стабільних гілок і тестують їх із userspace, який постачається разом із ними. Mainline kernel зі стороннього архіву або kernel, зібраний вручну, надає нові можливості, але позбавляє цієї роботи, оскільки ніхто не переносить fixes до вашої збірки. Ви стаєте maintainer kernel.

Винятки існують, але їх небагато: старий kernel не підтримує потрібне обладнання або ви виміряли зміну продуктивності на власному workload і настільки хочете її отримати, що готові самостійно відповідати за наслідки. На VPS перший випадок майже ніколи не застосовується, оскільки доступне вам обладнання є віртуальним. В усіх інших випадках підтримуйте kernel дистрибутива в актуальному стані та перезавантажуйте сервер, коли система цього вимагає. Якщо оновлення дистрибутива вже заплановане, перехід з Ubuntu 24.04 на 26.04 переведе вас з 6.8 на 7.0 за один крок. Це більший стрибок, ніж той, який дасть будь-який окремий пакет kernel.

FAQ

Як перевірити, яке ядро Linux працює на моєму VPS?

Виконайте uname -r. Команда виведе приблизно 6.8.0-79-generic. Число перед першим дефісом — це основна версія upstream, на якій базується ядро дистрибутива. Усе після неї — власний номер збірки дистрибутива, що містить backport-виправлення. Потім виконайте systemd-detect-virt. Якщо команда виведе lxc або openvz, ви використовуєте контейнерну віртуалізацію, спільно використовуєте ядро хоста й не можете його змінити. Якщо буде виведено kvm, ви завантажуєте власний образ ядра та самостійно відповідаєте за його оновлення.

Чи є Linux 7.1 ядром із довгостроковою підтримкою?

Ні. Станом на 11 August 2026 на kernel.org перелічено такі longterm-гілки: 6.18, 6.12, 6.6, 6.1, 5.15 і 5.10. Версії 7.1 серед них немає. Це звичайний стабільний реліз, а його стабільну гілку припиняють підтримувати невдовзі після виходу наступного mainline-релізу. Якщо вам потрібне ядро з багаторічною історією виправлень і тривалою майбутньою підтримкою, саме таким уже є ядро вашого дистрибутива.

Коли 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-реліз. Тому певну upstream-гілку може бути повністю пропущено. Для Ubuntu 24.04 LTS заплановано перехід HWE kernel на 7.0 разом із point-релізом 24.04.5 27 August 2026. Виправлення з 7.1 надійдуть до вас у вигляді backport у старішу гілку. Нові функції зазвичай не надходять.

Які зміни в Linux 7.1 справді важливі для virtual private server?

Є чотири основні зміни. Hardware queue leasing дає змогу контейнеру використовувати одну реальну NIC queue для AF_XDP на native speed. Третя фаза перероблення swap усуває статичну swap map і, за опублікованими даними, на 30% зменшує обсяг metadata, який kernel зберігає для swap device. MGLRU може пакетно перевіряти page young flags; найбільший опублікований приріст отримано на Arm server із багатьма ядрами. А clone3() отримав CLONE_AUTOREAP, CLONE_NNP і CLONE_PIDFD_AUTOKILL, що підвищує безпеку нагляду за дочірніми процесами. Також додано T10 protection information на рівні filesystem, але virtual disk рідко надає потрібні для цього integrity metadata.

Чи може оновлення kernel зламати мій VPS?

Типові збої виникають під час завантаження. Повний /boot спричиняє помилку update-initramfs із повідомленням No space left on device під час інсталяції, через що пакет залишається частково налаштованим: видаліть старі kernel за допомогою sudo apt autoremove --purge, а потім повторно інсталюйте пакет. Out-of-tree modules, зібрані для старого kernel, перестають завантажуватися. Тому все, чим керує DKMS, потрібно перебудувати. Невдала перебудова може залишатися непомітною, доки модуль не знадобиться під час роботи. Якщо після перезавантаження uname -r і далі показує стару версію, а dpkg -l перелічує новий image, проблема не в інсталяції. Просто bootloader не змінив версію за замовчуванням.