Una sola línea de log provoca 49 KB+ (ext4) / 110 KB+ (btrfs) de escrituras en disco de systemd-journald

Artículo original ↗ Discusión en Hacker News ↗

Los administradores de Linux están reportando una amplificación extrema de escrituras por parte de systemd‑journald, donde una sola entrada de log puede desencadenar decenas de kilobytes de escrituras en disco en sistemas de archivos como ext4 y Btrfs, lo que genera preocupaciones sobre el desgaste de los SSD y el rendimiento. Los participantes atribuyen esto al formato binario del registro basado en mmap e indexado por hashes de journald y a su diseño en disco intensivo en mutaciones, argumentando que se comporta más como una base de datos mal diseñada que como un simple log append‑only. Muchos sugieren mitigar el problema limitando o descargando el almacenamiento de journald, o reemplazándolo por syslog tradicional o por registro respaldado por bases de datos, y cuestionan por qué un componente tan crítico fue arquitectado de esa manera en lugar de usar motores de almacenamiento existentes y probados.

Amplificación de escrituras en disco e impacto

  • Una sola entrada de log en systemd‑journald puede desencadenar decenas o cientos de KB de escrituras en disco, especialmente en btrfs, causando una amplificación de escritura severa.
  • Los sistemas de archivos CoW (btrfs, otros) magnifican esto, lo que lleva a grandes escrituras acumuladas en SSD en escritorios mayormente inactivos.
  • Muchas otras aplicaciones y servicios de escritorio (componentes de KDE, extensiones del navegador, IPFS, Redis, etc.) también escriben con frecuencia, agravando el problema.

Críticas al diseño y comportamiento de journald

  • El formato en disco se considera demasiado complicado: escrituras pequeñas dispersas, actualizaciones de tablas hash y uso de mmap generan IO adicional y mala escalabilidad.
  • Varios comentaristas dicen que leer con journalctl es más lento que buscar con grep en logs de texto plano (incluso comprimidos con gzip).
  • Se informa que journald es frágil (corrupción de logs, problemas pasados con watchdog) y difícil de depurar o razonar sobre él.
  • El filtrado y el rate limiting se consideran rudimentarios: es difícil silenciar una sola fuente ruidosa sin afectar a otras; existen patrones por servicio, pero son limitados e inconsistentes.

Debate sobre mmap, bases de datos y formatos

  • Crítica fuerte al uso de mmap escribible para logs: poco control sobre el orden de vaciado, ensuciamiento a nivel de página y comportamiento impredecible en sistemas de archivos complejos.
  • Algunos sostienen que mmap no es intrínsecamente malo si se combina con un vaciado cuidadoso; otros lo ven como un “truco ingenioso” innecesario.
  • Múltiples propuestas para usar motores de almacenamiento existentes en lugar de un formato propio: SQLite, DuckDB, LevelDB, Parquet, o texto simple append‑only con indexación offline.
  • Desacuerdo sobre enfoques WAL/LSM: algunos señalan que WAL duplica escrituras; otros argumentan que sigue siendo más principiado y eficiente que el patrón actual de journald.

Preocupaciones sobre el ecosistema de systemd y la gobernanza

  • A journald se le llama con frecuencia la peor parte de systemd; muchos mantendrían systemd pero reemplazarían journald si realmente fuera opcional.
  • Crítica de que systemd es menos modular de lo que anuncia porque journald es, de hecho, obligatorio.
  • Quejas sobre la cultura del proyecto: respuestas defensivas a reportes de errores, falta de revisión abierta del diseño, tendencia a reinventar en lugar de reutilizar componentes probados.

Soluciones alternativas y paliativos

  • Mitigaciones comunes: Storage=volatile, límites pequeños de tamaño, o usar journald solo como router mientras los logs se almacenan con rsyslog/syslog‑ng o recolectores externos.
  • Algunos usuarios migran a distribuciones sin systemd (Devuan, Void) o a otros sistemas operativos (p. ej., FreeBSD) en parte para evitar journald.
  • Se sugiere marcar ciertas rutas como nocow en btrfs y filtrar o poner en lista negra de forma agresiva los mensajes de log ruidosos cuando sea posible.