https://www.opennet.ru/opennews/art.shtml?num=66082.
Разработчики проекта systemd приступили к изучению и устранению давней архитектурной проблемы в компоненте systemd-journald, приводящей к многократному завышению объёма записываемых на диск данных (write amplification) по сравнению с фактическим объёмом логов.
История тянется с марта 2020 года, когда в системе отслеживания ошибок был зарегистрирован отчёт, в котором было продемонстрировано, что генерирование около 500 КБ текстовых логов выливается в более чем 700 МБ физических операций записи на SSD. Разработчики systemd тогда наотрез отказались признавать проблему: мейнтейнеры заявили исследовательские претензии в духе «вы не понимаете, как работают файловые системы», отказались от проведения профилирования и закрыли заявку с вердиктом «not actionable». Комментарии разработчиков собрали сотни отрицательных оценок от пользователей, однако позиция проекта осталась непреклонной.
В начале 2026 года был отправлен повторный отчёт о проблеме, в ходе обсуждения которого независимый разработчик ValdikSS провёл подробное профилирование с использованием изолированных cgroup и loop-устройств, наглядно доказав механизм возникновения проблемы: из-за использования отображаемых в память файлов (mmap) и двоичных хэш-таблиц запись даже одного текстового сообщения размером 750 байт приводит к модификации отпечатков в памяти, вызывая сброс на диск полных 4-килобайтных страниц и генерацию от 50 до 70 КБ итогового ввода/вывода на уровне блочного устройства.
После вчерашнего попадания отчёта о проблеме на главную страницу Hacker News и публикации неопровержимых синтетических тестов мейнтейнеры проекта изменили риторику и начали работу над оптимизацией механизмов сброса кэша и структуры хранения индексов journald. В данном случае разработчики systemd продемонстрировали типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами, пока ущерб репутации проекта в сообществе не превысил издержки на его исправление.
