OpenZFS में एक डेटा-करप्शन बग?

OpenZFS बग का प्रभाव

• इसे एक बहुत ही दुर्लभ race condition बताया गया है, जिसे व्यवहार में ट्रिगर करना कठिन है।
• भारी write/move workloads में इसके लक्षण स्पष्ट होंगे (जैसे build trees में अचानक zero-filled files आ जाना)।
• bcloneused/bclonesaved की जाँच को विश्वसनीय परीक्षण नहीं कहा गया है; bclones केवल एक ट्रिगर थे।
• करप्शन पारंपरिक on-disk damage नहीं है: cp zeroes पढ़ता है और उन्हें लिख देता है, और ZFS उन्हें सही तरह से स्टोर करता है, इसलिए scrubs और backups के साथ byte-level compares इसे नहीं पकड़ पाएँगे।
• बग की उम्र और बड़े ZFS उपयोगकर्ताओं से रिपोर्टों की कमी को देखते हुए, कई टिप्पणियाँ तर्क देती हैं कि वास्तविक दुनिया का जोखिम कम है।

बैकअप की विश्वसनीयता और परीक्षण

• इस बात पर ज़ोर दिया गया कि backups अक्सर चुपचाप विफल हो जाते हैं: tools files को छोड़ सकते हैं, रन के बीच में रुक सकते हैं, या खराब logging कर सकते हैं।
• सलाह:
  • नियमित रूप से restores का परीक्षण करें, उन systems से भी जिन्हें आप बहुत कम छूते हैं।
  • restores किसी expert के अलावा किसी और से कराएँ, ताकि docs और tooling की पुष्टि हो सके।
  • scripts और repair tools को up to date रखें।
  • रन के बाद backups verify करें (sizes, decrypt/untar करने की क्षमता, जहाँ संभव हो hashes)।
  • कम से कम दो अलग backup implementations का उपयोग करें।
• database backups को विशेष रूप से कठिन बताया गया है; transactional consistency के लिए केवल filesystem snapshots पर्याप्त नहीं हैं।

होम NAS और बड़े-डेटा बैकअप रणनीतियाँ

• कई लोग तर्क देते हैं कि “average home NAS” का मतलब 40 TB नहीं है; अधिकांश के लिए केवल एक subset (photos, documents) को cloud backup की ज़रूरत होती है।
• बताई गई रणनीतियाँ:
  • महत्व के आधार पर tiering के साथ cloud (Backblaze, S3 Glacier/Deep Archive, Hetzner Storagebox, B2)।
  • दूसरा NAS या server offsite (family/friends) पर, rsync/ZFS send/syncthing को VPN/Tailscale/Nebula के over उपयोग करके।
  • external HDD/SSD पर cold storage, जिसे rotate किया जाए और जो ज़्यादातर offline रहे।
  • बड़े, critical datasets के लिए LTO tape, जिसे कुछ लोग long term में cost-effective लेकिन operationally tedious और noisy बताते हैं।
• thumb rules: अपनी “hot” storage cost का लगभग 3× backup में निवेश करें; एक ही RAIDed copy की बजाय कई non-redundant copies को प्राथमिकता दें।

Sparse files और filesystem abstractions

• इस पर बहस कि sparse files और SEEK_HOLE/SEEK_DATA एक design mistake थे या उपयोगी optimization।
• कुछ लोग sparse files को block-level details को user space में leak करने वाला और ऐसी complexity जोड़ने वाला मानते हैं जो इस तरह के bugs पैदा कर सकती है।
• अन्य लोगों का तर्क है कि ये torrents, databases, VM images, और deduplication जैसे workloads के लिए आवश्यक हैं।
• fallocate, mmap, और विभिन्न filesystems तथा COW semantics का preallocation और fragmentation के साथ कैसे interaction होता है, इस पर चर्चा।

वैकल्पिक filesystems और licensing politics

• यह नोट किया गया कि हाल के showstopper bugs OpenZFS में थे, Oracle के बंद ZFS में नहीं, लेकिन Oracle ने Solaris को प्रभावी रूप से छोड़ दिया है।
• CDDL vs GPL पर लंबी चर्चा: incompatibility OpenZFS को Linux में merge करने को जटिल बनाती है; कुछ लोग legal risk को बढ़ा-चढ़ाकर बताया हुआ मानते हैं, जबकि अन्य Oracle को एक गंभीर threat देखते हैं।
• Ubuntu द्वारा लंबे समय से ZFS को shipping करने और किसी legal action के न होने का हवाला दिया गया, लेकिन कुछ का मानना है कि future lawsuits अभी भी संभव हैं।
• bcachefs को कुछ लोग एक promising Linux-native alternative मानते हैं (heterogeneous disks, RAID-5/6-style redundancy, SMR-aware), लेकिन अन्य सावधान करते हैं कि यह अभी भी युवा है, वास्तविक दुनिया exposure सीमित है, और corruption reports मौजूद हैं।