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

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

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

Есть второй ответ, который вам нужно знать заранее. Версия 7.1 почти наверняка не установлена на вашем сервере, и этого не произойдет еще долгое время. kernel.org не указывает 7.1 как LTS-релиз (с долгосрочной поддержкой). По состоянию на 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 улучшено сброс (flushing) нулевых диапазонов и поиск через 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.* расширенные атрибуты. Сокеты 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) страниц пакетами, а не по одной странице за раз. Согласно опубликованным данным, это дает более 60% прироста производительности на 32-ядерном сервере Arm64. Пакетная обработка наиболее эффективна там, где затраты на одну страницу максимальны, поэтому такой результат был получен на крупной системе Arm. Если вы используете VPS на базе Arm, а не x86, это изменение в версии 7.1 вероятнее всего отразится на ваших собственных замерах, хотя и не в таком масштабе на двух или четырех ядрах.

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

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

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

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

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

Новые средства управления процессами и контейнерами в 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 запланирован в 24.04.5 на 27 августа 2026 года. Точечный релиз — это не новая версия Ubuntu, а та же 24.04, в которую включены все обновления для свежих установочных образов, поэтому что меняет 24.04.5 на уже пропатченном сервере — это только ветка HWE-ядра и почти ничего больше.

Вот момент, в котором часто ошибаются. Стек 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 выполняют бэкпорт исправлений безопасности в свои «замороженные» версии и тестируют их на совместимость с поставляемым пользовательским окружением. Основное ядро из стороннего репозитория или собранное вручную дает вам новые функции, но лишает этой поддержки, так как никто не будет выполнять бэкпорт исправлений для вашей сборки. Вы становитесь мейнтейнером собственного ядра.

Исключения существуют, но они редки: оборудование, которое старое ядро не поддерживает, или изменение производительности, которое вы измерили на своей рабочей нагрузке и готовы принять последствия. На 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. В 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 и сокращает объем метаданных, удерживаемых ядром для устройства подкачки, примерно на 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, а затем выполните переустановку. Модули, не входящие в основное дерево ядра (out-of-tree), собранные для старой версии, перестают загружаться, поэтому всё, что управляется через DKMS, должно быть пересобрано; сбой при пересборке проходит незаметно до тех пор, пока модуль не окажется недоступен во время выполнения. Если uname -r по-прежнему показывает старую версию после перезагрузки, а dpkg -l отображает новый образ, значит, установка прошла успешно, но загрузчик не обновил конфигурацию по умолчанию.