Разработчиците на проекта 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
