Uma única linha de log gera 49 KB+ (ext4) / 110 KB+ (btrfs) em gravações de disco do systemd-journald

Artigo original ↗ Discussão no Hacker News ↗

Administradores Linux estão relatando amplificação extrema de gravações por parte do systemd‑journald, em que uma única entrada de log pode disparar dezenas de kilobytes de gravações em disco em sistemas de arquivos como ext4 e Btrfs, levantando preocupações sobre desgaste de SSD e desempenho. Os participantes atribuem isso ao formato binário de log do journald, baseado em `mmap` e indexado por hash, e ao seu design em disco que sofre muitas mutações, argumentando que ele se comporta mais como um banco de dados mal projetado do que como um log simples append-only. Muitos sugerem mitigar limitando ou descarregando o armazenamento do journald, ou substituindo-o por syslog tradicional ou logging apoiado por banco de dados, e questionam por que um componente tão crítico foi arquitetado dessa forma em vez de usar mecanismos de armazenamento existentes e testados em produção.

Amplificação de gravação em disco e impacto

  • Uma única entrada de log no systemd‑journald pode disparar dezenas ou centenas de KB de gravações em disco, especialmente em btrfs, causando forte amplificação de gravação.
  • Sistemas de arquivos CoW (btrfs e outros) amplificam isso, levando a grandes gravações cumulativas em SSDs em desktops em grande parte ociosos.
  • Muitos outros apps e serviços de desktop (componentes do KDE, extensões do navegador, IPFS, Redis etc.) também gravam com frequência, agravando o problema.

Críticas ao design e comportamento do journald

  • O formato em disco é visto como excessivamente complicado: pequenas gravações espalhadas, atualizações de tabelas de hash e uso de mmap levam a IO extra e pior escalabilidade.
  • Vários კომენტadores dizem que ler com journalctl é mais lento do que fazer grep em logs de texto simples (mesmo gzipped).
  • O journald é descrito como frágil (corrupção de logs, problemas antigos com watchdog) e difícil de depurar ou raciocinar sobre.
  • Filtragem e limitação de taxa são consideradas rudimentares: é difícil silenciar uma única fonte barulhenta sem afetar outras; existem padrões por serviço, mas eles são limitados e inconsistentes.

Debate sobre mmap, bancos de dados e formatos

  • Há críticas fortes ao uso de mmap gravável para logs: pouco controle sobre a ordem de flush, dirtying por granularidade de página e comportamento imprevisível em sistemas de arquivos complexos.
  • Alguns argumentam que mmap não é inerentemente errado se combinado com flush cuidadoso; outros veem isso como um “truque esperto” desnecessário.
  • Várias propostas sugerem usar mecanismos de armazenamento já existentes em vez de um formato customizado: SQLite, DuckDB, LevelDB, Parquet, ou texto simples apenas append-only com indexação offline.
  • Há discordância sobre abordagens WAL/LSM: alguns observam que WAL duplica gravações; outros argumentam que ainda assim é mais consistente e eficiente do que o padrão atual do journald.

Preocupações com o ecossistema do Systemd e governança

  • O journald é frequentemente chamado de pior parte do systemd; muitos manteriam o systemd, mas substituiriam o journald se ele fosse realmente opcional.
  • Crítica de que o systemd é menos modular do que anunciado, porque o journald é efetivamente obrigatório.
  • Reclamações sobre a cultura do projeto: respostas defensivas a relatos de bugs, falta de revisão aberta de design, tendência a reinventar em vez de reutilizar componentes comprovados.

Alternativas e contornos

  • Mitigações comuns: Storage=volatile, limites pequenos de tamanho, ou usar o journald apenas como roteador enquanto os logs são armazenados com rsyslog/syslog‑ng ou coletores externos.
  • Alguns usuários migram para distribuições sem systemd (Devuan, Void) ou outros sistemas operacionais (por exemplo, FreeBSD) em parte para evitar o journald.
  • Sugestões para marcar certos caminhos como nocow no btrfs e filtrar agressivamente ou colocar em blacklist mensagens de log ruidosas quando possível.