वर्कलोड्स के तहत Btrfs/ZFS/bcachefs: क्लासिक बेंचमार्क छोड़ें

बेंचमार्क का दायरा और कार्यप्रणाली

• बेंचमार्क का लक्ष्य multi-device, CoW filesystems और RAID-जैसी सेटअप्स हैं (scrub / integrity व्यवहार सहित), और throughput, IOPS, तथा fsync latency के लिए fio का उपयोग किया गया है।
• कई वर्कलोड custom हैं (जैसे, हर 200 ms पर 4 KiB write + fsync को एक “trivial op” latency probe के रूप में)। इन्हें project-specific माना गया है, industry standards नहीं।
• टेस्ट अभी मुख्यतः GitHub-hosted VMs पर loop-backed sparse files के साथ चल रहे हैं; लेखक ज़ोर देता है कि केवल relative “shapes and ratios” की तुलना करनी चाहिए, absolute MB/s की नहीं।
• एक calibration चरण है जिससे सबसे noisy VMs हटाई जाती हैं, और कुछ सीमित “real hardware” रन भी हैं, जिनमें और काम जारी है, including HDD/SSD hybrid और tiered setups।

Data integrity और corruption tests

• एक टेस्ट replicated set में एक single device पर 2 GiB raw blocks overwrite करता है, फिर filesystem scrubs चलाता है।
• कुछ टिप्पणीकार सवाल करते हैं कि क्या यह वास्तव में “recoverable” है और “integrity” success/failure का सही मतलब क्या है।
• लेखक स्पष्ट करता है कि label को “corruption probe” में बदला जाएगा: “survived” का अर्थ केवल यह है कि एक specific file readable और unchanged रही, यह नहीं कि पूरा filesystem पूरी तरह healthy है।

Results की प्रस्तुति और उपयोगिता

• कई लोगों को page घना और visually scan करने में कठिन लगता है: छोटे text, एक साथ बहुत सारे charts, और “Overall Core” तथा “Core I/O” जैसे composite scores की अस्पष्ट definitions।
• दूसरे लोग, खासकर engineers, data की “wall” को पसंद करते हैं और simplification से अधिक detail को प्राथमिकता देते हैं।
• सुझावों में शामिल हैं कि test के तहत क्या है, इसका clearer description दिया जाए, derived metrics की बेहतर व्याख्या हो, run metadata को top से हटाया जाए, और JSON data का उपयोग करके वैकल्पिक “simplified” views बनाए जाएँ।

Environment realism और hardware coverage

• कुछ लोगों का तर्क है कि shared cloud runners और noisy neighbors परिणामों को भरोसेमंद बनाना कठिन करते हैं, और dedicated bare-metal testbeds का समर्थन किया गया।
• दूसरे लोग सीमाओं को स्वीकार करते हैं, यह नोट करते हुए कि focus performance की बजाय integrity पर है और extensive bare-metal automation कठिन और महँगी है।
• कई additional scenarios की माँग दिखती है: HDD vs SSD, NVMe, अलग-अलग RAID sizes, non-CoW filesystems, dm-integrity, dRAID, F2FS, DRBD, CephFS, और integrity layers के साथ XFS।

Bcachefs, Btrfs, ZFS और alternatives

• Bcachefs benchmarks में मजबूत परिणाम दिखाता है और device tiers mixing तथा per-file replication जैसी features के लिए सराहा जाता है, लेकिन maturity और mainline से हालिया removal को लेकर चिंताएँ बनी रहती हैं।
• कुछ users अपने distro-specific out-of-tree/DKMS setup में bcachefs से खुश हैं (जैसे NixOS-based setups, NAS appliances), और अच्छे practical अनुभव का हवाला देते हैं।
• Btrfs को “default modern” in-tree option माना जाता है, लेकिन इसकी आलोचना होती है:
  • भरोसेमंद free-space reporting की कमी।
  • volumes भर जाने पर fragile behavior।
  • कमजोर repair tooling और अभी भी अनुशंसित नहीं RAID5/6।
  • कुछ environments में बहुत बड़े file deletes पर कभी-कभी गंभीर stalls।
• ZFS को data safety के लिए व्यापक रूप से trusted माना जाता है, लेकिन इसकी आलोचना होती है:
  • कुछ workloads में कम performance।
  • licensing friction, जिसके कारण यह कई distributions और rescue environments से बाहर रहता है।
  • कुछ distros पर rapid kernel updates के पीछे DKMS का पिछड़ना।
• कई production-minded टिप्पणीकार predictability के लिए LVM/MD RAID की बजाय ext4/XFS जैसे simpler stacks को तरजीह देते हैं, कभी-कभी separate compression/dedup layers (जैसे dm-vdo) के साथ।

Social factors और kernel governance

• कई टिप्पणियाँ इस बात पर जोर देती हैं कि filesystem की “social health” (bus factor, maintainer drama, CoC issues, corporate sponsorship) raw performance जितनी ही महत्वपूर्ण है।
• Bcachefs का mainline से हटाया जाना और kernel maintainers के साथ पहले के conflict कुछ लोगों के लिए trust और future-stability concerns पैदा करते हैं; दूसरे तर्क देते हैं कि ये मुख्यतः maintainer समस्याएँ हैं और end users को बस अच्छे tooling और reliability की ज़रूरत है।
• bcachefs के development के स्थिर होने और broader maintainer team बनने के बाद इसके eventual mainline return में व्यापक रुचि है।