Linux: 6.1.64-1 में Ext4 डेटा करप्शन

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

Linux 6.1.64 ext4 फ़ाइलसिस्टम में एक गंभीर बग direct I/O के साथ लिखते समय चुपचाप डेटा करप्शन करता है, जिसके चलते Debian ने अपनी 12.3 रिलीज़ टाल दी और प्रभावित kernel package को रोक दिया। टिप्पणीकर्ता देखते हैं कि upstream के patches की असंगत जोड़ी long-term stable kernels में कैसे आ गई, जिससे Linux stable backport process, “stable” distributions की सीमाएँ, और distro infrastructure व user practices के जरिए ऐसी समस्याओं को कितनी जल्दी पकड़ा और कम किया जा सकता है—इन पर व्यापक चिंताएँ उठती हैं।

बग का दायरा और प्रकृति

  • ext4 डेटा करप्शन कुछ Linux 6.1 स्थिर कर्नलों में direct I/O (O_DIRECT) का उपयोग करते समय होता है, क्योंकि एक backported ext4 बदलाव एक अन्य direct-IO बदलाव पर निर्भर था जिसे backport नहीं किया गया था।
  • यदि दोनों commits मौजूद हों (जैसे नए कर्नलों में), तो व्यवहार सही रहता है; यदि केवल ext4 commit मौजूद हो (जैसे 6.1.64/65), तो writes गलत offset पर जा सकती हैं।
  • करप्शन को “non-catastrophic” बताया गया है: filesystem metadata सुरक्षित रहती है, लेकिन अलग-अलग फाइलों की सामग्री चुपचाप corrupt हो सकती है, जो विशेष रूप से O_DIRECT का उपयोग करने वाली VM images और databases के लिए बुरा है।

Upstream बनाम Debian की ज़िम्मेदारी

  • कई टिप्पणियों में ज़ोर दिया गया है कि यह upstream stable-kernel बग है, केवल Debian patching की समस्या नहीं; Debian kernel.org stable releases को ट्रैक करता है।
  • थ्रेड में कुछ भ्रम पैदा होता है; अन्य लोग kernel changelogs और mailing list links का उपयोग करके स्पष्ट करते हैं कि upstream 6.1.64 प्रभावित है और 6.1.66 में fix शामिल है।
  • कहा गया है कि कुछ Ubuntu kernels प्रभावित नहीं हैं क्योंकि वे डिफ़ॉल्ट रूप से 6.1 ship नहीं करते।

Stable Kernel Process की आलोचना

  • भारी backporting model की कड़ी आलोचना की गई: पुराने LTS branches में हज़ारों commits खींचे जाते हैं, जिनमें non-trivial dependency risk होता है।
  • चिंता है कि “stable” kernels बहुत तेज़ी से बदलते हैं और अब Debian के बाकी हिस्से की तुलना में कम stable हैं; कुछ लोग इसके बजाय केवल latest mainline kernel चलाना पसंद करते हैं।
  • संबंधित घटना: 6.1.66 में एक और missing dependent patch ने Wi‑Fi तोड़ दिया, जिसे बाद में 6.1.67 में ठीक किया गया, जिससे प्रक्रिया पर संदेह और बढ़ा।

Debian का Handling और Updates

  • उपयोगकर्ता शिकायत करते हैं कि grave bug ज्ञात होने के बाद भी unattended-upgrades ने खराब kernel खींच लिया।
  • स्पष्टीकरण दिया गया: Debian का archive tooling तुरंत revocation के लिए नहीं बना है; नए kernels को कई architectures के लिए build करना पड़ता है और फिर mirrors पर propagate होना होता है, जो दिन में केवल कुछ बार sync करते हैं।
  • चर्चा किए गए workaround: एक apt preferences file के साथ 6.1.64-1 को pin करना, पुराने kernel से boot करना, और unattended-upgrades को ठीक से disable करना .timer unit को stop/disable करके या package को reconfigure करके।

Filesystems और Recovery

  • कुछ लोग इसे इस दावे को कमजोर करने वाला मानते हैं कि ext4, ZFS या btrfs की तुलना में inherently ज़्यादा सुरक्षित है; अन्य ज़ोर देते हैं कि सभी filesystems में bugs होते हैं।
  • ext4 की उसकी mature fsck और सरल metadata layout के लिए प्रशंसा की जाती है, और कहा जाता है कि इससे लगभग किसी भी नुकसान से recovery संभव है; संशयवादी सवाल करते हैं कि इससे वास्तविक user data कितना बचता है।

Severity और “Non-Serious Data Loss”

  • Debian के शब्दों पर बहस: “grave” बनाम “non-serious data loss”, और क्या ऐसा corruption जिसे fsck (या backups) से ठीक किया जा सके, व्यवहार में “recoverable” माना जा सकता है।
  • इस बात पर ज़ोर दिया गया है कि silent corruption विशेष रूप से खतरनाक है क्योंकि backups भी चुपचाप खराब डेटा ingest कर सकते हैं।