A systemd projekt fejlesztői elkezdték tanulmányozni és orvosolni a régi architekturális problémát a "systemd-journald" komponensben, amely a tényleges naplómérethez képest többszörös írási felnagyításhoz (write amplification) vezet.
A történet 2020 márciusáig nyúlik vissza, amikor egy hibafigyelő rendszerben jelentést regisztráltak, amelyben bemutatták, hogy körülbelül 500 KB szöveges napló generálása több mint 700 MB fizikai írási műveletet eredményez SSD-n. A systemd fejlesztői akkor kategorikusan tagadták a problémát, azt válaszolták, hogy "nem értik, hogyan működnek a fájlrendszerek", elutasították a profilozást, és lezárták az igényt a "not actionable" verdiktet hozva. A fejlesztők megjegyzései több száz negatív értékelést gyűjtöttek a felhasználóktól, de a projekt álláspontja változatlan maradt.
2026 elején újból jelentést küldtek a problémáról, amelynek során egy független fejlesztő, ValdikSS részletes profilozást végzett izolált cgroupok és loop-eszközök használatával, világosan bizonyítva a probléma keletkezésének mechanizmusát: a memóriába leképezett fájlok (mmap) és bináris hash-táblák használata miatt egyetlen 750 bájtos szöveges üzenet írása is a memóriában lévő nyomtatványok módosításához vezet, ami a teljes 4 kilobájtos oldalak lemezre történő írását és 50-70 KB végső bemeneti/kimeneti (I/O) generálását okozza blokk eszköz szinten.
Miután a tegnapi problémajelentés megjelent a Hacker News főoldalán, és közzétették a megcáfolhatatlan szintetikus teszteket, a projekt karbantartói megváltoztatták a retorikájukat, és elkezdtek dolgozni a cache-kiürítési mechanizmusok és a journald indexek tárolási struktúrájának optimalizálásán.
Forrás: opennet.ru
