Тридцатого августа Линус Торвальдс закрыл двухнедельное окно слияния и выпустил первый релиз-кандидат ядра 7.3, а кодовая база mainline перевалила за отметку в сорок один миллион строк. Формально это рядовое событие календаря разработки, которое повторяется каждые два-три месяца, но именно rc1 фиксирует архитектурный ландшафт на ближайшие полтора-два месяца тестирования: то, что попало в окно сейчас, осенью окажется в дистрибутивах и продакшене, а то, что не успело, отправится ждать следующего цикла.
Что фиксирует релиз-кандидат 7.3-rc1 и сколько кода реально вошло в окно слияния
По количеству неслитых наборов изменений 7.3-rc1 стал вторым в истории ядра: в mainline-репозиторий вошло 15267 отдельных change-set, и обогнать этот показатель смог только релиз-кандидат 6.7-rc1. Сам Торвальдс в письме о релизе отметил, что ничего экстраординарного по содержанию в этом окне не произошло, но объём получился заметно выше обычного. Значительная часть объёма пришлась на одно единственное изменение: дамп заголовков и кода регистров AMD DCN6 занял примерно треть всего патча rc1. Если мысленно вычесть этот блок из статистики, картина выглядит вполне типично для последних циклов разработки.
Подсистема управления памятью тоже показала непривычно высокую активность. Эндрю Мортон провёл через своё дерево 1250 патчей против 920 в предыдущем цикле, и часть сопроводительных описаний к этим патчам, по собственному признанию Мортона, была составлена с помощью языковой модели, поскольку вручную описать тысячу с четвертью изменений оказалось попросту нереалистично по времени. Торвальдс за это же окно слияния успел выполнить обновление собственной рабочей системы прямо посреди приёма патчей, назвал это решение действием "круглого дурака" и потратил часть рабочего времени на устранение последствий собственной спешки.
Как устроена файловая система FailFS и почему из ядра убрали efs и freevxfs
Одним из заметных файловых изменений стало появление в дереве новой файловой системы с рабочим названием FailFS, добавленной в рамках общего пакета VFS-обновлений Кристиана Браунера. По задумке она относится к тому же семейству вспомогательных, тестовых файловых систем, что и уже существующая NULLFS, и предназначена в первую очередь для отладки и проверки поведения других подсистем ядра в условиях контролируемых сбоев ввода вывода, а не для повседневного хранения данных пользователя.
В том же окне слияния F2FS получила самый заметный набор изменений среди флеш-ориентированных файловых систем: пятьдесят один коммит принёс возможность динамически изменять размер хвостовых секций вместе с унифицированным закреплённым выделением, что сокращает расход памяти при работе с флеш-накопителями, а также асинхронное завершение записи и динамическое перераспределение свободного пространства между разделами без постоянных простоев ввода вывода. Заодно поправили несколько давних гонок, которые теоретически могли приводить к взаимной блокировке процессов или утечкам памяти. CephFS в свою очередь сделал более прагматичный шаг: синхронную запись при приближении кластера к заполнению теперь можно оставить буферизуемой, пока сама метадата-служба это допускает, и принудительный синхронный режим остаётся только для по настоящему заполненных кластеров, а не включается заранее с большим запасом, как было раньше.
Параллельно с добавлением нового кода из ядра вычистили откровенно устаревшие компоненты. Файловые системы efs и freevxfs, доставшиеся ядру в наследство от древних UNIX-платформ и практически не имевшие живых пользователей последние годы, были удалены целиком. Та же участь постигла режим ondemand у cachefiles - устаревший механизм подкачки кеша, который давно уступил место более современным подходам. Такая уборка легаси - обычная практика ближе к очередному крупному циклу: код, который никто не поддерживает и почти никто не использует, превращается в источник потенциальных уязвимостей и лишнюю нагрузку на мейнтейнеров.
Какой прирост производительности получил Btrfs благодаря новому буферу прямого ввода вывода
Дэвид Стерба из SUSE традиционно одним из первых прислал пул запросов по Btrfs, и в этот раз изменения оказались особенно ощутимыми. Ключевое нововведение - новый буфер отражения на основе iomap для прямого ввода вывода, который поднял пропускную способность операций direct I/O примерно до девяноста пяти процентов от теоретического максимума накопителя, тогда как раньше показатель держался на уровне около пятидесяти процентов. Это почти двукратный прирост для сценариев, где приложения сознательно обходят кеш страниц операционной системы, например для баз данных и систем виртуализации.
Второе крупное изменение затронуло внутреннее устройство работы с экстент-буферами: локальные списки LRU заменили структуру XArray для отслеживания заблокированных буферов, и на отдельных операциях это дало прирост скорости примерно в три раза. По собственным замерам Стербы, проведённым в процессе подготовки пула, заметный выигрыш получили сценарии с SQLite, PostgreSQL и ClickHouse - все три системы активно используют небольшие случайные операции записи, для которых внутренняя эффективность метаданных Btrfs исторически была узким местом. В независимых бенчмарках Phoronix по той же методике, что применяется для сравнения релизов год к году, отдельные операции на 7.3 показали прирост от трёх до пяти раз относительно 7.2, что в целом подтверждает заявленные цифры разработчиков.
На фоне технических успехов в этом же цикле произошла кадровая перемена: Крис Мейсон, один из создателей Btrfs и её многолетний со-мейнтейнер, объявил об уходе с этой роли после смены места работы, где он курировал развитие файловой системы последние годы. Формально это не повлияло на темп разработки текущего окна слияния, но обозначило конец целой главы в истории проекта, который Мейсон запустил ещё в две тысячи седьмом году и с тех пор так или иначе сопровождал через все крупные архитектурные решения, включая переход на стабильный статус и нынешний виток оптимизаций производительности.
Что изменилось в Zstd и MGLRU и как это повлияло на скорость сборки на ARM серверах
Инженер Усама Ариф обнаружил на первый взгляд незаметную, но дорогую по цене неэффективность: ядро при каждом создании нового контекста сжатия заново прощупывало поддержку набора инструкций BMI2 через два сериализующих вызова CPUID, вместо того чтобы выполнить эту проверку один раз при загрузке системы. Перенос проверки на этап загрузки сократил время декомпрессии Zstd на 71 процент и время компрессии для crypto_acomp на 18 процентов - редкий случай, когда одно небольшое изменение даёт настолько заметный эффект просто потому, что раньше никто не заметил лишнюю работу в горячем пути.
Отдельного внимания заслуживает правка Баолиня Вана из Alibaba в подсистеме многопоколенческого LRU, отвечающей за вытеснение страниц памяти под нагрузкой. На серверах ARM с ограниченным объёмом памяти страницы исполняемого кода вытеснялись слишком агрессивно, что заметно било по времени сборки крупных проектов. После изменения логики, при котором такие страницы получают приоритет сохранения в памяти сразу после первого использования, тестовый ARM-сервер с тридцатью двумя ядрами и лимитом памяти в два гигабайта показал падение системного времени с 9248 до 7861 секунды - улучшение примерно на пятнадцать процентов для нагрузки, которую большинство разработчиков вообще не привыкли ассоциировать с настройками управления памятью ядра.
Какая поддержка появилась для AMD Zen 6 и контроллера Steam две тысячи двадцать шестого года
Помимо файловых систем и подсистемы памяти, 7.3-rc1 принёс заметный пакет обновлений для будущего оборудования. В код вошли первые заготовки под платформы AMD на архитектуре Zen 6, что типично для ядра: поддержка новых процессорных семейств появляется задолго до розничного анонса самих чипов, чтобы к моменту выхода железа дистрибутивы уже имели рабочие драйверы. Отдельным крупным блоком прошли графические изменения AMD, Intel и Qualcomm: 121 коммит в едином DRM-пуле закрыл проблемы управления питанием во время работы, поправил работу подсветки и добавил тонкую настройку блока DCN6, а также принёс начальную поддержку GPU-блоков Qualcomm Shikra.
Из пользовательских новостей стоит выделить драйвер для геймпад-контроллера Valve Steam 2026 года, добавленный прямо в это окно, а также улучшения от Valve для игр на системах с очень ограниченным объёмом видеопамяти. Кроме того, ядро получило начальную поддержку линейки Apple M3 Ultra, Pro и Max, что продолжает многолетнюю работу сообщества Asahi Linux по портированию mainline-ядра на технику Apple без необходимости держать форк.
Как соотносятся текущий стабильный выпуск 7.2.2 и грядущая Ubuntu 26.10 с ядром 7.2
Пока rc1 проходит стабилизацию, актуальным стабильным выпуском для повседневного использования остаётся 7.2.2, вышедший двадцать восьмого августа с точечным исправлением в сетевом стеке, касающимся пересборки фрагментированных пакетов IPv4. Ветка 7.2 в целом уже выбрана командой Canonical базовым ядром для Ubuntu 26.10 под кодовым именем Stonking Stingray, релиз которой запланирован на середину октября. Это значит, что пользователи следующей версии Ubuntu получат все наработки цикла 7.2, включая планирование с учётом топологии кеша процессора и протокол USB4STREAM, но нововведения из 7.3, включая ускоренный Btrfs и обновлённый Zstd, попадут в Ubuntu уже следующим релизом весной.
Отдельно стоит упомянуть тревожную статистику по количеству обнаруживаемых уязвимостей: по данным, которые Грег Кроа-Хартман представил в преддверии конференции Kernel Recipes, число CVE на релиз стабильно растёт с каждым циклом. Если версии с 6.9 по 6.19 в среднем давали около пятисот записей за релиз, то 7.0 превысил тысячу, 7.2 перешагнул полторы тысячи, а для 7.3 прогнозируют приближение к двум тысячам. Основной причиной роста называют не ухудшение качества самого кода, а массовое применение автоматизированного анализа на основе языковых моделей, которые методично проходят по всем сорока миллионам строк ядра и находят проблемы в старом, редко затрагиваемом коде драйверов, годами остававшемся без пристального внимания.
Как самостоятельно собрать и протестировать 7.3-rc1 на своей машине
Для тех, кто хочет заранее проверить поведение железа или конкретной файловой системы на новом ядре, порядок действий остаётся стандартным для любого релиз-кандидата:
- клонировать основное дерево Торвальдса и переключиться на нужный тег командами git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git и следом git checkout v7.3-rc1;
- подготовить конфигурацию сборки на основе текущего работающего ядра командой make olddefconfig, взяв за основу файл /boot/config текущей системы, либо запустить make menuconfig для ручной настройки нужных опций;
- собрать образ и модули командой make -j$(nproc), после чего установить их через make modules_install и make install, не забыв обновить загрузчик;
- после перезагрузки проверить фактическую версию работающего ядра командой uname -r и убедиться, что система действительно поднялась на 7.3-rc1, а не откатилась на предыдущий вариант из-за ошибки загрузчика.
Устанавливать релиз-кандидат имеет смысл на тестовом окружении или отдельном разделе, а не на основной рабочей машине: до финального релиза остаётся ещё порядка шести-семи еженедельных итераций стабилизации, и часть регрессий на столь раннем этапе цикла считается нормальным явлением, а не поводом для паники. Именно для их отлова и существует сама стадия релиз-кандидатов, а пользователи, готовые тестировать rc1 на реальной нагрузке, ежегодно помогают отловить заметную часть проблем до того, как код доберётся до стабильных веток дистрибутивов.