Что нового в ядре Linux 7.1 для серверов

Что нового в ядре Linux 7.1

Ядро Linux 7.1 было выпущено 14 июня 2026 года, через девять недель после версии 7.0. Для владельца VPS (виртуального выделенного сервера) значимые изменения сосредоточены в четырех областях: хранилища и файловые системы, сетевое взаимодействие, управление памятью, а также контроль процессов и контейнеров. Остальная часть релиза в основном касается работы с графикой и настольными системами, которые не загружаются на headless-серверах.

Есть второй ответ, который вам нужен в первую очередь. Версия 7.1 почти наверняка не установлена на вашем сервере, и это не изменится в течение долгого времени. kernel.org не помечает 7.1 как релиз с долгосрочной поддержкой (longterm). По состоянию на 11 августа 2026 года ветки с долгосрочной поддержкой — это 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. Ядро 6.8.0-79 от Canonical содержит тысячи исправлений, перенесенных (backported) из более новых версий, поэтому это не тот код, который Линус пометил как 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. Подсчет релизов — это грубая метрика, так как она игнорирует все изменения, которые дистрибутивы переносят из новых версий, но она показывает масштаб разрыва. Если вы выбираете, что именно использовать, в основе этих цифр лежит компромисс между 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 и SATA SSD на VPS объяснит, почему этот ответ влияет на ваши показатели производительности.

В Btrfs исправлено усиление copy-on-write при нехватке памяти, а также внесено изменение, ускоряющее очистку первого экстента в отслеживаемом диапазоне, что дает прирост пропускной способности на 10% на тестовых нагрузках, указанных в описании слияния. Операция завершения работы (shutdown) больше не считается экспериментальной. В XFS улучшены сброс нулевых диапазонов и поиск через iomap, а также добавлен указатель записи в геометрию групп реального времени, что является основой для работы с зонированными устройствами. NTFS в этом релизе была полностью переписана, получила полноценную поддержку записи и конвертацию в iomap, что важно, если вы когда-либо монтируете образы дисков с машин Windows на своем сервере.

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

Сети: аренда очередей и преимущества для контейнеров

Главное изменение в сетевой подсистеме — аренда аппаратных очередей. Виртуальное сетевое устройство теперь может арендовать очередь, привязанную к реальной очереди на физическом сетевом адаптере, и выступать для неё прокси-сервером. Это сделано для контейнеров. Ранее контейнеру, которому требовался AF_XDP (address family express data path — тип сокета, передающий «сырые» пакеты в пользовательское пространство без копирования через сетевой стек), приходилось предоставлять доступ почти ко всему устройству целиком. Благодаря аренде очереди контейнер получает одну аппаратную очередь, работает с AF_XDP и провайдерами памяти на нативной скорости, а хост сохраняет контроль над остальной частью NIC. Это нововведение дополняет поддержку AF_XDP в механизме zero-copy для io_uring.

Что касается стандартных функций, сокеты в sockfs теперь поддерживают user.* расширенные атрибуты (xattr). Сокеты AF_UNIX, привязанные к пути в файловой системе, уже наследовали поддержку xattr от нижележащей ФС, но сокеты, существующие только в sockfs, её не имели. Теперь процесс может присвоить сокету метку, а eBPF-программа — выполнять фильтрацию на основе этой метки.

Два компонента были удалены. Поддержка UDP-Lite исключена из-за отсутствия пользователей. IPv6 больше нельзя собрать в виде загружаемого модуля: если вам нужен IPv6, он должен быть скомпилирован в ядро. Второе изменение незаметно для любого дистрибутивного ядра, так как популярные серверные дистрибутивы уже включают IPv6 в состав ядра по умолчанию.

Управление памятью: таблица swap завершена

Переработка подсистемы swap достигла третьей фазы, в которой удаляется статическая карта swap. Теперь счетчик swap находится непосредственно в таблице swap. Заявленная экономия составляет около 30% статических метаданных swap — это память, которую ядро удерживает пропорционально размеру вашего swap-устройства, независимо от того, используется ли оно. В абсолютных значениях это немного для небольшого файла подкачки, но объем растет вместе с настроенным вами размером swap.

MGLRU (multi-generational least recently used, более новый алгоритм вытеснения страниц) теперь может проверять флаг «молодости» (young flag) страниц пакетами, а не по одной странице за раз. Согласно опубликованным данным, производительность на 32-ядерном сервере Arm64 выросла более чем на 60%. Пакетная обработка дает наибольший выигрыш там, где затраты на одну страницу максимальны, поэтому такой показатель был получен на крупной машине Arm. Если вы используете VPS на базе Arm, а не x86, это изменение в версии 7.1 вероятнее всего отразится на ваших собственных замерах, хотя и не в таком масштабе на двух или четырех ядрах.

Также в этом обновлении: удалена передача данных из завершающих работу cgroups памяти, khugepaged выполняет сканирование с меньшей нагрузкой на CPU, а структура maple tree прошла масштабный рефакторинг в части обработки больших узлов. Все это не требует настройки. Вы заметите эти изменения как небольшое сокращение системного времени (system time).

Планировщики: подпланировщики sched_ext и включенный по умолчанию FRED

sched_ext, расширяемый класс планировщика, позволяющий написать планировщик CPU в виде BPF-программы и загрузить его во время выполнения, появился в версии 6.12. В 7.1 добавлена базовая структура для подпланировщиков, чтобы в будущем контрольная группа могла работать под управлением собственного планировщика. Прочитайте это предложение внимательно. Реализация в 7.1 не завершена, в частности, отсутствует путь постановки в очередь (enqueue path), поэтому это задел для будущих релизов, а не функция, которую можно включить сегодня.

Intel FRED (flexible return and event delivery) теперь включен по умолчанию на поддерживающем его оборудовании. FRED заменяет устаревший путь обработки событий x86 на более чистый; он присутствовал в ядре с версии 6.9 и активировался через параметр загрузки fred=on. Перевод его в состояние «включено по умолчанию» означает, что поставляемое оборудование прошло достаточный уровень тестирования. Опубликованные на данный момент результаты измерений, показывающие прирост от 4% до 7% на задачах с интенсивным вводом-выводом, получены в ходе тестирования Phoronix на клиентских процессорах, поэтому не стоит рассчитывать на такой результат на сервере, пока вы не измерите показатели на своей собственной рабочей нагрузке.

В механизм proxy execution добавлена миграция доноров (donor migration) для ускорения владельца удаленной блокировки, в EEVDF внесены исправления, связанные с отрицательным лагом (negative lag), а ядро таймеров высокого разрешения было существенно переписано. Это изменения, влияющие на качество задержек, которые не настраиваются через конфигурационные файлы.

Новые средства управления процессами и контейнерами в clone3()

В clone3() были добавлены три флага, каждый из которых устраняет проблему, которую супервизоры годами решали вручную. Флаг CLONE_AUTOREAP заставляет дочерний процесс автоматически завершаться, не превращаясь в зомби в ожидании родительского процесса, который может никогда не вызвать wait(). Флаг CLONE_NNP устанавливает no_new_privs для дочернего процесса в момент его создания, что закрывает временной интервал между вызовом clone и установкой этого флага самим процессом. Флаг CLONE_PIDFD_AUTOKILL привязывает время жизни дочернего процесса к pidfd, возвращаемому родителю: при закрытии pidfd дочерний процесс завершается, поэтому супервизор, который аварийно завершил работу, не оставит после себя работающих «сирот».

Аналогичные изменения коснулись пространств имен монтирования (mount namespaces). Флаги CLONE_EMPTY_MNTNS для clone3() и UNSHARE_EMPTY_MNTNS для unshare() позволяют создать пустое пространство имен монтирования вместо стандартного полного копирования всех точек монтирования родительского процесса, которые среде выполнения (runtime) затем приходилось отмонтировать вручную. Флаг FSMOUNT_NAMESPACE позволяет fsmount() поместить файловую систему непосредственно в новое пространство имен. Среды выполнения контейнеров собирали эту функциональность вручную в течение десятилетия, поэтому реализация этого в одном вызове означает, что среда выполнения больше не начинает работу с пространством имен, заполненным точками монтирования хоста.

Что касается виртуализации, guest_memfd теперь поддерживает userfaultfd, что позволяет гипервизору обрабатывать ошибки страниц (page faults) гостевой системы из пользовательского пространства. В защищенном KVM на архитектуре Arm появилась поддержка анонимной памяти, которая, согласно описанию самого слияния (merge), пока не готова к промышленной эксплуатации.

Когда ядро 7.1 появится на вашем сервере

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

Все остальные дистрибутивы ждут, и это ожидание предусмотрено архитектурой. Debian 13 поставляется с 6.12 и остается на этой версии в течение всего жизненного цикла релиза, получая лишь бэкпорты исправлений. RHEL 10 поставляется с 6.12.0 и придерживается той же политики. Ubuntu 26.04 LTS получила 7.0 в апреле 2026 года. В Ubuntu 24.04 LTS используется стек аппаратного обеспечения (HWE), который подтягивает более новые ядра из последующих релизов Ubuntu в LTS-версию. По состоянию на точечный релиз 24.04.4 этот стек использует 6.17, а переход на 7.0 запланирован на 27 августа 2026 года в составе 24.04.5.

Вот момент, в котором многие ошибаются. Стек HWE переходит на любое ядро, которое используется в новейшем промежуточном релизе, поэтому он может полностью пропустить апстрим-ветку. Версия 7.0 есть в Ubuntu LTS. Версия 7.1 может никогда не стать базовой для LTS, так как в следующем промежуточном релизе будет использоваться более новая ветка. В ваш LTS из 7.1 попадут только исправления, бэкпортированные в ту ветку, на которой вы находитесь. Новые функции при этом останутся в стороне.

Если вам действительно нужно более новое ядро на стабильном сервере, поддерживаемых путей немного.

# 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 отображает все установленные образы ядер. Если uname -r показывает старую версию, а dpkg -l перечисляет новую, значит, пакет установился, но загрузчик не обновил настройки по умолчанию: проверьте пункты меню GRUB. Наличие /var/run/reboot-required означает, что пакет обновил ядро, но с тех пор не было перезагрузки. Это самая частая причина, по которой пропатченный сервер продолжает выполнять уязвимый код.

Стоит ли переходить на 7.1 на продуктивном VPS

Нет, и причина здесь не в излишней осторожности. Ядро из состава дистрибутива — это часть обязательств по поддержке. Canonical, Red Hat, SUSE и Debian выполняют бэкпортирование исправлений безопасности в свои «замороженные» ветки и тестируют их на совместимость с поставляемым пользовательским окружением. Основное ядро (mainline) из стороннего репозитория или собранное вручную дает вам новые функции, но лишает этой поддержки, так как никто не будет бэкпортить исправления в вашу сборку. Вы становитесь мейнтейнером собственного ядра.

Исключения существуют, но они редки: оборудование, которое старое ядро не поддерживает, или изменение производительности, которое вы измерили на своей рабочей нагрузке и готовы принять все последствия. На VPS первый случай практически не встречается, так как оборудование является виртуальным. Во всех остальных ситуациях поддерживайте ядро дистрибутива в актуальном состоянии и выполняйте перезагрузку по запросу системы. Если обновление дистрибутива уже входит в ваши планы, то переход с Ubuntu 24.04 на 26.04 переведет вас с версии 6.8 на 7.0 за один шаг, что является более значительным скачком, чем любой отдельный пакет ядра.

FAQ

Как узнать, какая версия ядра Linux используется на VPS?

Выполните uname -r. Команда выведет строку вида 6.8.0-79-generic. Число перед первым дефисом — это основная ветка ядра, на которой базируется ваш дистрибутив, а всё, что идет после — номер сборки дистрибутива, включающий бэкпортированные исправления. Затем выполните systemd-detect-virt. Если команда выводит lxc или openvz, вы используете контейнерную виртуализацию, разделяете ядро с хостом и не можете его изменить. Если выводится kvm, вы загружаете собственный образ ядра и самостоятельно отвечаете за его обновление.

Является ли Linux 7.1 ядром с долгосрочной поддержкой (LTS)?

Нет. По состоянию на 11 августа 2026 года в списке LTS-веток на kernel.org значатся 6.18, 6.12, 6.6, 6.1, 5.15 и 5.10; версии 7.1 в этом списке нет. Это обычный стабильный релиз, поддержка которого прекращается вскоре после выхода следующей основной версии. Если вам нужно ядро с многолетней историей исправлений и гарантированной поддержкой в будущем, используйте ядро, поставляемое вашим дистрибутивом.

Когда Ubuntu или Debian выпустят ядро 7.1?

Скорее всего, никогда в качестве ядра по умолчанию. Debian 13 использует версию 6.12 на протяжении всего жизненного цикла релиза, как и RHEL 10 (версия 6.12.0). В Ubuntu 26.04 LTS поставляется ядро 7.0, а стек аппаратного обеспечения (HWE) в Ubuntu обновляется до версии ядра из новейшего промежуточного релиза, поэтому некоторые ветки могут быть пропущены полностью. Переход HWE-ядра в Ubuntu 24.04 LTS на версию 7.0 запланирован в составе точечного релиза 24.04.5 на 27 августа 2026 года. Исправления из 7.1 будут поступать к вам в виде бэкпортов для более старых веток ядра, однако новые функциональные возможности обычно не переносятся.

Что именно в Linux 7.1 важно для виртуального частного сервера?

Четыре момента. Аренда аппаратных очередей (hardware queue leasing) позволяет контейнеру использовать одну реальную очередь сетевой карты для AF_XDP на нативной скорости. Третья фаза переработки подсистемы swap устраняет статическую карту swap, что, по имеющимся данным, сокращает объем метаданных, удерживаемых ядром для swap-устройства, на 30%. MGLRU теперь может проверять флаги «молодости» страниц (page young flags) пакетами, что дает наибольший прирост производительности на многоядерных Arm-серверах. Кроме того, clone3() получила CLONE_AUTOREAP, CLONE_NNP и CLONE_PIDFD_AUTOKILL, которые делают процесс управления дочерними процессами более безопасным. Также была добавлена поддержка защиты данных T10 на уровне файловой системы, но виртуальные диски редко предоставляют необходимые для этого метаданные целостности.

Приведет ли обновление ядра к поломке VPS?

Типичные сбои происходят на этапе загрузки. Переполнение /boot приводит к ошибке update-initramfs с сообщением No space left on device во время установки, из-за чего пакет остается в частично настроенном состоянии: очистите старые ядра с помощью sudo apt autoremove --purge, а затем выполните переустановку. Модули, не входящие в основное дерево ядра и собранные для старой версии, перестают загружаться, поэтому все компоненты, управляемые через DKMS, должны быть пересобраны; ошибка пересборки не всегда очевидна до момента, когда модуль не обнаружится во время выполнения. Если uname -r по-прежнему показывает старую версию после перезагрузки, а dpkg -l отображает новый образ, значит, установка прошла успешно, но загрузчик не обновил конфигурацию по умолчанию.