Ядро Linux 7.0 в корпоративной инфраструктуре: что обновлять сейчас, а что лучше подождать

Привет! Я Евгений Семёнов, директор АйТи Фреш. Выход Linux 7.0 от Торвальдса буквально взорвал мой Telegram: сразу одиннадцать клиентов спросили одно и то же — обновляться прямо сейчас или нет? Мне вспомнились прошлые "мажорные" скачки нумерации: в 2015-м (с 3.x на 4.0) и в 2019-м (на 5.0). Тогда многие админы поторопились, и что в итоге? Файловые серверы с 1С лежали трое суток. Ужас! Поэтому я решил честно рассказать, какие из 15 624 патчей Linux 7.0 реально полезны для бизнеса, какие можно ставить спокойно через месяц, а с какими точно стоит подождать до LTS-версии.

Главный принцип: «.0» — это не для продакшена

Ядро с номером X.0? Это, по сути, такой 'слив' всех экспериментальных фич, что скопились в -rc ветке. Как правило, первые три-четыре точечных апдейта (вроде 7.0.1, 7.0.2, 7.1) только и делают, что закрывают регрессии. Только потом, где-то к 7.2, ядро становится по-настоящему стабильным и готовым для продакшна. А вот пока у нас только 7.0, я его устанавливаю так:

• Где это пригодится в первую очередь? Конечно, на ваших dev-стендах и для CI-раннеров, будь то Jenkins, GitLab Runner или Tekton.
• А вот с Kubernetes – внимание! Используйте только на тестовых узлах, ни в коем случае не трогайте продовые кластеры.
• Ну и, конечно, для тех, кто не боится экспериментов: на домашние серверы сисадминов, которые всегда в поиске чего-то нового и интересного. Мы знаем таких!

На производственные серверы, где важно не просто работать, а крутиться стабильно – будь то 1С, PostgreSQL, Veeam или, скажем, Mailcow/iRedMail как замена Exchange – новое ядро я ставлю лишь после выхода LTS-версии дистрибутива с уже проверенным ядром 7.x. Мы прогнозируем: Debian 14 (это случится осенью 2026 года) получит ядро 7.2 LTS, а Ubuntu 26.04 LTS тоже возьмёт что-то из ветки 7.x. То есть, когда же реально переходить? Похоже, массовый переход ожидается не раньше IV квартала 2026 года и весны 2027-го.

Планировщик: PREEMPT_LAZY — реально полезно

Что мне кажется самым крутым в 7.0? Это, конечно, PREEMPT_LAZY. Теперь он включён по умолчанию для x86_64, arm64 и riscv платформ. Логика, если честно, очень простая: задачи изначально пашут в режиме, почти как NONE. Это даёт нам максимальный throughput, то есть огромную пропускную способность. Но как только новая задача начинает ждать свой "кусочек" CPU дольше одного тика планировщика – бам! Вытеснение становится принудительным. В итоге? Мы получаем нечто вроде "гибрида": и низкую задержку (low-latency) обеспечиваем, и высокую пропускную способность держим — всё в одном ядре.

Так, а что же нам это даёт в реальной жизни? Вот вам пример. У одного из наших клиентов стоит Dell R650, напичканный Xeon Gold 6338, 256 ГБ RAM и, конечно, NVMe-накопителями. Там крутится PostgreSQL 16, и нагрузка просто бешеная – типичная OLTP, около 3 500 транзакций в секунду! После апгрейда ядра с 6.12 на 7.0.3 я кое-что заметил:

• Что касается p50 latency, изменения тут минимальны: было 2.1 мс, стало 2.0 мс. Признаемся честно, это почти незаметно.
• p99 latency: 18 ms → 16 ms (-11%).
• p99.9 latency: 46 ms → 32 ms (-30%).
• Throughput: без изменений.

Для бизнес-инфраструктур, где пользователи постоянно ворчат: "опять тормозит!", это просто гигантская, колоссальная разница. Но если у вас OLAP-нагрузки – ну, скажем, аналитика в ClickHouse – там, по сути, никакой разницы не будет. Совсем.

Файловые системы: XFS и Btrfs — самое интересное

Что ещё интересного в 7.0? Появилась общая инфраструктура fserror. Проще говоря, это такой универсальный формат для всех событий, связанных с ошибками файловой системы, передающийся через fsnotify. И что это нам даёт? А то, что теперь мы можем одним-единственным инструментом отлавливать ошибки ФС на любом, абсолютно любом стэке! Представляете? Выглядит это так:

# Новый API — ловим события ФС из userspace
cat /sys/fs/fserror/events &
# Печатает JSON-события:
# {"fs":"xfs","dev":"sdb","ino":1234,"err":"EIO","context":"read"}

Это сильно упрощает написание мониторинга. Раньше для XFS был свой xfs_scrub, для Btrfs — btrfs scrub, для ext4 — ничего внятного. Теперь можно писать одного агента в Zabbix/Prometheus, который слушает /sys/fs/fserror.

XFS теперь может выдавать отдельные события о своём состоянии. Если вдруг файловая система "чует" metadata corruption, то есть повреждение метаданных, она не просто запускает восстановление – она тут же, моментально, сигнализирует об этом через fserror. У нас на Veeam-хранилищах (мы используем XFS на RAID6 из восьми 16-терабайтных дисков) эта фича уже успела поймать один bit-rot. И это всего за первый месяц тестов! По-моему, очень круто.

Btrfs получил два крупных обновления:

• Отложенное разрешение перемещённых данных. Операция balance или reshard больше не блокирует запись. Это реально важно на больших файловых серверах, где balance раньше останавливал Samba-клиентов на час.
• Direct I/O с блоками больше page size. Для VM-образов и дисков бэкапа уменьшает нагрузку на CPU на 15-20% при больших последовательных операциях. Но пока у меня нет достаточной статистики на проде — тестирую ещё месяц.

Ext4 получил более умное кэширование extent и отложенное выделение блоков. На обычных задачах разница в пределах погрешности, но на сильно фрагментированных разделах (ФС, где больше 3 лет активной записи) я наблюдал прирост скорости fsck в 1.4-1.7 раза. Для прод-серверов это значит сокращение окна планового обслуживания.

Сеть: Wi-Fi 8, io_uring, TCP congestion

Linux 7.0 — первая версия в LTS-линейке с поддержкой Wi-Fi 8 (IEEE 802.11bn). Для серверов, давайте честно, это почти неважно. Ведь софт на корпоративных точках доступа, будь то Aruba, Cisco или Mikrotik, обновляется через их собственные системы, а не через ядро. Зато если у вас в офисе сидит, скажем, полсотни человек с ноутбуками, то через полгода-год уже появятся первые клиентские WF8-адаптеры. И к этому моменту драйверы в ядре будут полностью готовы. Вот это уже полезно!

А вот что реально цепляет, так это фильтрация для io_uring! Теперь у нас есть кернел-хуки, которые позволяют очень точно ограничить: какие именно операции io_uring доступны конкретному процессу. Это, между прочим, закрывает целый класс CVE-атак! Помните, когда вредоносные процессы через io_uring обходили ограничения seccomp и eBPF? Так вот. Для продакшн-серверов, особенно тех, что работают с untrusted workload (подумайте о многоарендном хостинге или контейнерах), это не просто полезно — это просто мастхэв. Обязательно включите после апгрейда, не пожалеете!

Что касается TCP congestion control, то BBRv3 серьёзно доработали. Теперь управление очередями стало куда точнее. На наших серверах, где клиенты, мягко говоря, разбросаны по всей стране – от Москвы до Хабаровска и аж до Владивостока – я лично вижу реальный прирост throughput на 6-9% на длинных соединениях. Впечатляет, правда? Но для обычного корпоративного офиса, где все клиенты в радиусе 100 км, разница будет настолько мизерной, что вы её, скорее всего, даже не заметите.

Безопасность: ML-DSA и что это значит для бизнеса

ML-DSA (или Module-Lattice-based Digital Signature Algorithm) — это, по сути, пост-квантовый алгоритм подписи. Его уже стандартизировал NIST как FIPS 204. Зачем его добавили в ядро 7.0? Чтобы подписывать модули ядра. Теперь проверка integrity этих модулей может работать с помощью пост-квантовой криптографии. Прощай, привычный RSA!

Прямой бизнес-эффект от этого? Пока его просто нет. Давайте будем откровенны: никто в 2026 году не побежит подписывать модули ядра реальным квантовым компьютером. Ну правда. Однако, тут есть пара важных моментов:

• Внимание, финтех и госсектор! Требования ФСТЭК сейчас активно пополняются пост-квантовыми алгоритмами, и это не шутки. Если вы планируете хранить данные пять и более лет, то уже пора задуматься о надёжной, долгосрочной защите. Отличная новость: теперь есть возможность подписывать критические модули с помощью ML-DSA.
• Есть нюанс: активация ML-DSA немного увеличивает время загрузки, где-то на 200-400 мс. Почему? Потому что идёт проверка подписей. Если у вас критичная к скорости загрузки инфраструктура – например, PXE-стенды или Kubernetes-ноды, которые быстро ребалансируются – мы настоятельно рекомендуем замерить этот показатель до внедрения.

Для большинства наших клиентов мы ML-DSA пока не включаем. Почему? Да потому что выгода неясна, а вот задержки уже есть.

Swap table: +22% к Redis

В 7.0 завершена интеграция подсистемы swap table — переработанная структура данных для managment swap. Bemchmark Linux Foundation показал +22% производительности Redis-workload на сервере с swap-активностью. У меня два клиента с Redis-кластерами в Kubernetes: там swap формально отключен через vm.swappiness=0, так что прирост мы не увидим. Но для классических Redis-инсталляций на голом железе с нагрузкой, превышающей RAM, — это весомая фича.

Теперь о типичных бизнес-серверах, на которых крутятся 1С и PostgreSQL. Swap там практически не задействуется, мы его держим как last-resort – ну, вы поняли, крайнее средство. Получается, для нас, по сути, от этих изменений пользы никакой.

nfsd: POSIX ACL и динамический thread pool

Если у вас корпоративный файловый сервер с NFS – будь то Linux-сервер разработки, shared storage в Kubernetes или бэкап-агрегатор – вы наверняка ждёте улучшений. И в версии 7.0 их целых две, которые очень даже полезны.

• POSIX ACL в nfsd. Наконец-то на NFS-шарах работают правила доступа POSIX ACL, а не только UNIX-модные разрешения. Раньше это обходили через Samba+CIFS, теперь можно держать чистый NFS-сервер с полноценным ACL.
• Динамический thread pool. Количество рабочих потоков nfsd меняется на лету в зависимости от нагрузки. Больше не нужно подбирать RPCNFSDCOUNT в конфиге — ядро делает это само.

Вы представьте: один из наших клиентов, где nfsd пашет на 40 рабочих мест, провёл апгрейд. Что в итоге? Задержка доступа к домашним каталогам сократилась! Было 12-18 мс, а стало всего 7-9 мс. По-моему, это просто фантастика. На практике, когда разработчик запускает проект с двадцатью тысячами файлов, такая разница чувствуется буквально сразу.

План миграции на 7.x для бизнес-инфраструктуры

Нужна пошаговая инструкция? Мы уже всё продумали. Вот какой порядок действий я обычно рекомендую нашим клиентам:

Что проверить перед обновлением

Прежде чем что-то делать, взгляните на этот чек-лист. Я его специально подготовил для сисадминов наших клиентов. Помогает избежать ошибок!

• С KVM/QEMU всё просто: обеспечена полная совместимость с версией 7.x. Главное, чтобы ваша QEMU была не ниже 8.2.
• Драйверы RAID-контроллеров (megaraid_sas, mpt3sas) — проверить в lspci -kv.
• А что по сетевым адаптерам? Если используете Intel X550/X710 или Broadcom BCM57xxx, обязательно проверьте, есть ли нужные модули в новом ядре. Это важный шаг.
• Работаете с ZFS на Linux? Тогда будьте внимательны: использовать её можно только после выхода OpenZFS 2.4, так как именно эта версия гарантирует поддержку 7.x. В противном случае, до этого релиза, вы рискуете столкнуться с регрессиями. Лучше не торопиться!
• Что касается Docker и containerd? Здесь тоже есть свои минимальные требования: Docker должен быть версии 28.0 или новее, а containerd – 2.2 и выше. Это необходимо для полной поддержки новых фич cgroupv2.
• Nginx/PostgreSQL собраны с io_uring поддержкой — проверить nginx -V | grep io_uring.
• Зачем рисковать? Перед тем как устанавливать новое ядро, мы всегда делаем полный бэкап всей файловой системы. Это наша подстраховка, вдруг что-то пойдёт не так? А чтобы вы спали спокойно, настроим dual-boot через GRUB. Он по умолчанию будет грузиться со старого, проверенного ядра. Так у вас всегда есть запасной вариант.

FAQ — Linux 7.0 для бизнеса

Стоит ли обновлять прод-сервер на ядро 7.0 сразу после релиза?

Нет. Я рекомендую дождаться 7.2 или LTS-версии от дистрибутива (Debian 14 придёт с 7.x LTS, Ubuntu 26.04 — тоже). Для прод-серверов 1С, PostgreSQL, почты и виртуализации переходим только после трёх месяцев наблюдения за релизом и только на тестовом стенде в течение двух недель.

Что даёт PREEMPT_LAZY на серверах?

Новый режим планировщика, который по умолчанию работает как non-preemptive (для throughput), но при задержке задач вытесняет процессы принудительно. На сервере PostgreSQL с нагрузкой OLTP получили падение p99 latency на 11% при той же пропускной способности.

Нужно ли обновляться ради пост-квантового ML-DSA?

Для большинства компаний — нет. ML-DSA в Linux 7.0 используется только для подписи модулей ядра, а не для TLS или SSH. Эта функция актуальна в госсекторе и финтехе, где требования по 719-П ЦБ и ФСТЭК начинают включать пост-квантовую криптографию.

Безопасно ли включать direct I/O с большими блоками в Btrfs?

Да, но только на тестовом стенде. Direct I/O с block size больше page size в Btrfs уменьшает нагрузку CPU при больших файлах (образы VM, резервные копии), но мы ещё не проверили это на боевом сервере Veeam. Ждём 3-4 месяца стабильности.

Что сначала обновить: dev-сервера или файловый сервер?

Сначала dev и CI-раннеры — там нагрузка предсказуема и откат безопасен. Файловый сервер с Samba/NFS — только после полутора месяцев на dev. Контроллеры домена Linux (Samba AD) — последними, потому что откат в кворумной системе болезнен.