Os desenvolvedores do projeto systemd começaram a investigar e abordar um antigo problema arquitetônico no componente "systemd-journald", que resulta em uma ampliação significativa do volume de dados gravados no disco (write amplification) em comparação com o volume real dos logs.
A história remonta a março de 2020, quando um relatório foi registrado no sistema de rastreamento de erros, demonstrando que a geração de cerca de 500 KB de logs de texto resultava em mais de 700 MB de operações físicas de gravação em SSD. Naquela época, os desenvolvedores do systemd se negaram a reconhecer o problema, responderam de forma a sugerir "vocês não entendem como funcionam os sistemas de arquivos", recusaram-se a realizar uma avaliação e fecharam o pedido com o veredicto de "not actionable". Os comentários dos desenvolvedores acumularam centenas de avaliações negativas dos usuários, mas a posição do projeto permaneceu inabalável.
No início de 2026, um novo relatório sobre o problema foi enviado, e durante a discussão, o desenvolvedor independente ValdikSS realizou uma profilação detalhada utilizando cgroups isoladas e dispositivos loop, demonstrando claramente o mecanismo da existência do problema: devido ao uso de arquivos mapeados na memória (mmap) e tabelas hash binárias, a gravação de uma única mensagem de texto de 750 bytes leva à modificação de impressões na memória, causando o descarregamento no disco de páginas completas de 4 kilobytes e gerando de 50 a 70 KB de entrada/saída final no nível do dispositivo de bloco.
Depois que o relatório sobre o problema apareceu na página inicial do Hacker News e a publicação de testes sintéticos irrefutáveis, os mantenedores do projeto mudaram sua retórica e começaram a trabalhar na otimização dos mecanismos de descarregamento de cache e na estrutura de armazenamento dos índices do journald.
Fonte: opennet.ru
