DeepSeek के distributed file system 3FS का परिचय

 (maknee.github.io)
20 पॉइंट द्वारा GN⁺ 2025-04-18 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • 3FS DeepSeek द्वारा विकसित एक high-performance open source distributed file system है, जो बड़े पैमाने के data processing और उच्च throughput को support करता है
  • यह सामान्य file system की तरह काम करता है, लेकिन वास्तव में data को कई machines में distributed storage के रूप में रखता है, और user को इसकी चिंता नहीं करनी पड़ती—यह एक abstraction structure प्रदान करता है
  • 4 मुख्य components (Meta, Mgmtd, Storage, Client) के माध्यम से metadata, node management, वास्तविक data storage, और user request processing को अलग-अलग संचालित किया जाता है
  • CRAQ algorithm के जरिए strong consistency और fault tolerance हासिल की जाती है, और chain structure में write requests को सुरक्षित रूप से propagate किया जाता है
  • 3FS अन्य distributed file systems की तुलना में व्यावहारिक उपयोगिता और performance scalability में अलग नजर आता है

3FS क्या है?

  • 3FS का मतलब Fire-Flyer File System है, और यह DeepSeek द्वारा जारी किया गया एक distributed file system है
  • यह DeepSeek के open source release week के दौरान साथ में जारी किया गया
  • यह सामान्य file path जैसा दिखता है, लेकिन वास्तव में कई machines में distributed data को abstract करके उपलब्ध कराता है

Distributed file system क्या होता है?

  • user को यह local file system जैसा दिखता है, लेकिन वास्तव में data कई servers पर distributed रूप में stored होता है
  • उदाहरण: /3fs/stage/notes.txt path एक single file जैसा दिख सकता है, लेकिन वास्तव में यह कई servers में विभाजित होकर stored हो सकता है
  • user mkdir, cat जैसे commands से इसे सामान्य file की तरह इस्तेमाल कर सकता है

Distributed file system का उपयोग क्यों किया जाता है?

  • बहुत बड़े data (petabyte स्तर) और उच्च throughput को support करने के लिए
  • fault tolerance और redundancy के जरिए reliability सुनिश्चित करने के लिए
  • वास्तविक उपयोग के उदाहरण:
    • HDFS + Spark जैसे parallel processing frameworks
    • ML training pipelines में checkpointing
    • Google का Colossus
    • Meta का photo storage system Haystack
    • AI storage के उदाहरण: JuiceFS vs CephFS

3FS के components

  • यह कुल 4 मुख्य nodes से बना है

Meta

  • file path, attributes, location आदि जैसी metadata management करता है
  • RPC के जरिए client requests को process करता है (open, stat, close आदि)
  • metadata FoundationDB में stored होती है
  • Inode file size, owner आदि की जानकारी store करता है
  • DirEntry path और inode को जोड़ता है (symbolic link की तरह एक ही file के लिए कई paths मौजूद हो सकते हैं)

Mgmtd

  • cluster में node registration और status checking का काम संभालता है
  • nodes boot होने पर खुद को register करते हैं और समय-समय पर heartbeat भेजते हैं
  • यह central router की भूमिका निभाता है, इसलिए nodes को आपस में direct connection बनाए रखने की जरूरत नहीं होती
  • CRAQ chain configuration के लिए settings information भी manage करता है

Storage

  • वास्तविक data storage का काम करता है
  • Rust-आधारित ChunkEngine के जरिए disk blocks को manage करता है
    • disk block का size, offset, checksum, version आदि को track करता है
    • user सीधे blocks के साथ interact नहीं करता; इसके लिए interface दिया जाता है
    • metadata LevelDB में stored होती है
  • कई तरह के workers मौजूद हैं
    • AllocateWorker नए blocks allocate करता है
    • PunchHoleWorker उपयोग में न आने वाले blocks reclaim करता है
    • AioReadWorker io_uring queue के जरिए asynchronous reads को handle करता है
  • write operation के समय CRAQ chain के अनुसार अगले node तक forward किया जाता है

Client

  • user requests को process करता है और अन्य nodes के साथ communicate करता है
  • operation flow:
    • Mgmtd से node location query करना
    • Meta को file operations के लिए request भेजना
    • Storage के साथ data transfer करना

CRAQ algorithm

  • इसका मतलब Chain Replication with Apportioned Queries है, और यह strong consistency (linearizability) प्रदान करता है
  • write flow:
    • Head → Middle → Tail क्रम में write propagation
    • बीच के stages में data को dirty के रूप में mark किया जाता है (read नहीं किया जा सकता)
    • Tail पर commit होने के बाद clean status backward दिशा में propagate होती है
  • read flow:
    • अगर clean है तो तुरंत return
    • अगर dirty है तो tail से latest data request किया जाता है

Performance के नजरिए से CRAQ

  • write speed सबसे धीमे node से सीमित होती है
  • जिस dirty data को बार-बार access किया जाता है, उसके लिए read requests tail पर केंद्रित हो सकती हैं, जिससे read bottleneck पैदा हो सकता है
  • उदाहरण: Zipfian workload में performance गिर सकती है
  • 5 nodes वाले cluster में 3 replicas रखने से failure की स्थिति में performance loss को कम किया जा सकता है

अन्य distributed file systems से अंतर

  • architecture भले मिलती-जुलती हो, लेकिन वास्तविक उपयोग और implementation approach में अंतर मौजूद है
  • तुलना के बिंदु:
    • किस workload में यह मजबूत है
    • performance tuning की flexibility
    • deployment की आसानी
    • throughput scalability
    • SLO के भीतर latency management
    • reliability
  • तकनीकी details:
    • bottleneck के कारण और उन्हें handle करने का तरीका
    • locks हैं या नहीं
    • इस्तेमाल किए गए data structures
    • target hardware
    • इस्तेमाल किया गया fault tolerance algorithm या error correction method

Blog series का अगला विषय

  • वास्तविक performance analysis के जरिए DeepSeek के दावों की जांच की जाएगी
  • समीक्षा के बिंदु:
    • FUSE bottleneck के बारे में DeepSeek का दावा
    • performance graphs को reproduce किया जा सकता है या नहीं
    • performance degradation की स्थितियों का analysis
    • bottleneck factors (CPU, memory, disk, network)
    • किन workloads में performance बेहतर है
    • मौजूदा systems के साथ comparative analysis
    • मौजूदा systems की problem-solving approach से अंतर
    • सीधे improvements की संभावना की समीक्षा

अतिरिक्त सामग्री

संबंधित पढ़ाई

2 टिप्पणियां

 
softer 2025-04-19

और यह वही समस्या थी जिसके बारे में मैं सोच रहा था, लेकिन इसे ..
 
GN⁺ 2025-04-18
Hacker News राय

  • S3FS एक scalable metadata file system है, जिसकी तुलना विभिन्न distributed file systems से की जा रही है

    • इनमें Collosus, Tectonic (Meta), ADLSv2 (Microsoft), HopsFS (Hopsworks), PolarFS (Alibaba) शामिल हैं
    • S3FS FoundationDB का उपयोग करता है, Collosus BigTable का, Tectonic KV store का, और HopsFS RonDB का उपयोग करता है
    • S3FS की महत्वपूर्ण बात यह है कि (1) यह fuse client को support करता है, जिससे उपयोग आसान हो जाता है, और (2) यह NVMe storage को support करता है, इसलिए disk I/O इसकी सीमा नहीं बनता
    • HopsFS ने hierarchical storage जोड़ा है, जिसमें हाल का डेटा NVMe पर और archive डेटा S3 पर रखा जाता है

  • इन सिस्टमों का मूल्यांकन करते समय सैद्धांतिक सीमाएँ, efficiency, और व्यावहारिक सीमाएँ ध्यान में रखनी चाहिए

    • सैद्धांतिक रूप से Lustre जैसे parallel distributed file systems अनंत तक scale कर सकते हैं
    • efficiency का आकलन करने के लिए यह गणना की जाती है कि X TiB disk वाले nodes से कितना storage और throughput मिल सकता है
    • FSx for Lustre की तुलना में AWS पर 3FS को 12-30% कम लागत में चलाया जा सकता है
    • यह सवाल अब भी बना हुआ है कि क्या लोग जिस deployment size की चाहत रखते हैं, उस स्तर पर वास्तव में file system बनाया जा सकता है
    • DeepSeek अपने मनचाहे गुण हासिल करने के लिए ऐसे systems खुद बनाए, यह समझ में आता है
    • Archil में उम्मीद है कि अधिकांश लोगों के लिए, बिना विशाल cluster manage किए इस्तेमाल करने योग्य बेहतर default settings मिलें

  • SeaweedFS के साथ तुलना में रुचि है

    • SeaweedFS का उपयोग weather data store करने के लिए किया जाता है, और लगभग 3 PB डेटा ML training में इस्तेमाल हो रहा है

  • CephFS का उपयोग न करने के कारण पर सवाल

    • CephFS को real-world scenarios में अच्छी तरह test किया गया है और petabyte scale पर इसकी reliability साबित हुई है
    • यह एक open source solution है, जो सबसे तेज़ NVMe storage पर चल सकता है और 10 gigabit से अधिक interconnects के साथ बहुत उच्च IOPS हासिल कर सकता है

  • JuiceFS के साथ तुलना पर सवाल

    • व्यक्तिगत homelab setup में S3 Garage के ऊपर JuiceFS चलाने की योजना है
    • Garage केवल replication को support करता है, erasure coding या sharding को नहीं
    • इसे इसलिए चुना गया क्योंकि setup आसान लगता है

  • छोटे व्यवसाय संचालक और homelab उपयोगकर्ता के रूप में, शायद इतने बड़े distributed file systems का उपयोग कभी नहीं होगा

    • petabyte scale डेटा के साथ backup और recovery कैसे होती है, इसे लेकर जिज्ञासा है

  • यह setup जटिल है, लेकिन deep learning workloads के लिए कौन-सी सुविधाएँ वास्तव में अनिवार्य हैं, यह स्पष्ट नहीं है

    • आवश्यक सुविधाएँ हैं petabyte scale storage, read/write parallelism, और redundancy
    • consistency हासिल करना कठिन है, और यहाँ इसकी आवश्यकता भी नहीं लगती

  • DeepSeek के distributed file system को disable करना कितना आसान है, इस पर सवाल

    • उदाहरण के लिए, यदि किसी अमेरिकी विश्वविद्यालय को research के लिए DeepSeek उपयोग करने की मंजूरी मिलती है, तो यह सुनिश्चित करना होगा कि डेटा local research cluster file system से बाहर न जाए

  • क्या इसे कई devices में फैले ZFS drives के साथ replicate किया जा सकता है, इस पर सवाल