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