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