systemd-journald डिस्क लेखन में एकल लॉग लाइन 49KB+ (ext4) / 110KB+ (btrfs)

मूल लेख ↗ Hacker News चर्चा ↗

Linux प्रशासक systemd‑journald से अत्यधिक write amplification की रिपोर्ट कर रहे हैं, जहाँ एक अकेली लॉग प्रविष्टि ext4 और Btrfs जैसे फाइलसिस्टम पर दर्जनों किलोबाइट डिस्क लेखन ट्रिगर कर सकती है, जिससे SSD wear और performance को लेकर चिंताएँ बढ़ रही हैं। योगदानकर्ता इसे journald के mmap-आधारित, hash-indexed binary log format और उसके mutation-heavy on-disk design से जोड़ते हैं, और तर्क देते हैं कि यह एक साधारण append-only log की बजाय खराब डिज़ाइन किए गए database जैसा व्यवहार करता है। कई लोग journald storage को सीमित करने या offload करने, या इसे पारंपरिक syslog अथवा database-backed logging से बदलने की सलाह देते हैं, और यह भी सवाल उठाते हैं कि ऐसा महत्वपूर्ण घटक मौजूदा, battle-tested storage engines का उपयोग करने के बजाय इस तरह क्यों डिज़ाइन किया गया।

डिस्क लेखन प्रवर्धन और प्रभाव

  • systemd‑journald में एक अकेली लॉग प्रविष्टि दर्जनों या सैकड़ों KB डिस्क लेखन ट्रिगर कर सकती है, खासकर btrfs पर, जिससे गंभीर write amplification होती है।
  • CoW फाइलसिस्टम (btrfs, अन्य) इसे और बढ़ा देते हैं, जिससे अधिकतर निष्क्रिय डेस्कटॉप पर भी SSD में बड़े संचयी लेखन होते हैं।
  • कई अन्य डेस्कटॉप ऐप्स और सेवाएँ (KDE घटक, ब्राउज़र एक्सटेंशन, IPFS, Redis, आदि) भी बार-बार लिखती हैं, जिससे समस्या और बढ़ जाती है।

journald के डिज़ाइन और व्यवहार पर आलोचनाएँ

  • ऑन-डिस्क फ़ॉर्मेट को अत्यधिक जटिल माना जाता है: बिखरे हुए छोटे लेखन, हैश टेबल अपडेट, और mmap उपयोग अतिरिक्त IO और खराब स्केलिंग लाते हैं।
  • कई टिप्पणीकार कहते हैं कि journalctl से पढ़ना, साधारण टेक्स्ट लॉग्स (यहाँ तक कि gzipped) को grepping करने से धीमा है।
  • journald को नाज़ुक बताया गया है (लॉग corruption, पुराने watchdog मुद्दे) और डिबग या समझना कठिन है।
  • फ़िल्टरिंग और rate limiting को मोटा-झोटा माना जाता है: एक शोर मचाने वाले स्रोत को चुप कराना कठिन है बिना दूसरों को प्रभावित किए; per-service patterns मौजूद हैं लेकिन सीमित और असंगत हैं।

mmap, डेटाबेस, और फ़ॉर्मैट्स पर बहस

  • लॉग्स के लिए writable mmap के उपयोग की कड़ी आलोचना: flush order पर कम नियंत्रण, page-granularity dirtying, और जटिल फाइलसिस्टम पर अप्रत्याशित व्यवहार।
  • कुछ लोगों का तर्क है कि सावधानीपूर्वक flushing के साथ mmap स्वाभाविक रूप से गलत नहीं है; अन्य इसे एक अनावश्यक “clever trick” मानते हैं।
  • मौजूदा storage engines को कस्टम फ़ॉर्मैट के बजाय उपयोग करने के कई प्रस्ताव: SQLite, DuckDB, LevelDB, Parquet, या साधारण append-only text के साथ offline indexing।
  • WAL/LSM approaches पर असहमति: कुछ कहते हैं WAL लेखन दोगुना कर देता है; अन्य तर्क देते हैं कि फिर भी यह journald के मौजूदा pattern से अधिक सिद्धांतपूर्ण और कुशल है।

Systemd ecosystem और governance संबंधी चिंताएँ

  • journald को अक्सर systemd का सबसे खराब हिस्सा कहा जाता है; कई लोग systemd को रखेंगे लेकिन journald को बदल देंगे, यदि वह वास्तव में वैकल्पिक होता।
  • यह आलोचना कि systemd उतना modular नहीं है जितना दावा किया जाता है, क्योंकि journald व्यवहार में अनिवार्य है।
  • परियोजना संस्कृति पर शिकायतें: bug reports पर रक्षात्मक प्रतिक्रियाएँ, खुले design review की कमी, proven components को पुनः उपयोग करने के बजाय फिर से invent करने की प्रवृत्ति।

वर्कअराउंड और विकल्प

  • आम mitigation: Storage=volatile, छोटे size limits, या journald को केवल router के रूप में उपयोग करना जबकि logs को rsyslog/syslog‑ng या बाहरी collectors में संग्रहीत करना।
  • कुछ उपयोगकर्ता journald से बचने के लिए non-systemd distros (Devuan, Void) या अन्य OSes (जैसे FreeBSD) पर चले जाते हैं।
  • btrfs पर कुछ paths को nocow चिह्नित करने और जहाँ संभव हो शोर वाले log messages को aggressively filter या blacklist करने के सुझाव।