SourceFS - एक virtual file system जो 2 घंटे से ज़्यादा के Android builds को 15 मिनट में लाता है

 (source.dev)
4 पॉइंट द्वारा GN⁺ 2025-10-24 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • SourceFS एक high-performance virtual file system है, जिसे बड़े device codebase की build speed और efficiency समस्याओं को हल करने के लिए डिज़ाइन किया गया है
  • यह Android build speed को अधिकतम 9x और code checkout speed को 10x से अधिक बढ़ाता है, disk usage को 83% घटाता है और computing cost को 14x तक कम करता है
  • इसका मुख्य सिद्धांत file virtualization और on-demand (materialization) है, जिसमें फ़ाइलें वास्तविक फ़ाइलों जैसी दिखती हैं, लेकिन उनका content केवल ज़रूरत पड़ने पर लोड होता है
  • build process में input/output और environment को रिकॉर्ड करके दोबारा उपयोग करने वाली sandbox-based caching के ज़रिए ज़्यादातर build stages को तुरंत replay किया जाता है

धीमे build और code checkout की समस्या

  • आधुनिक connected devices सैकड़ों मिलियन lines वाले codebase पर चलते हैं
    • Linux kernel लगभग 4 करोड़ lines का है, Android AOSP 14 करोड़ lines से अधिक है, और वास्तविक devices में hardware support, custom features और service code जुड़ने से यह 20 करोड़ lines से आगे निकल जाता है
    • electric vehicle (EV) में 50 करोड़ से अधिक lines होती हैं, और software updates के साथ यह लगातार बढ़ती रहती हैं
  • code checkout के समय सैकड़ों GB data डाउनलोड करना पड़ता है, और builds में लाखों नहीं बल्कि सैकड़ों हज़ार steps होते हैं
    • dependency graph की अपूर्णता के कारण छोटे बदलाव भी बड़े पैमाने पर rebuild करा सकते हैं या गलत परिणाम दे सकते हैं
  • नतीजतन हर दिन डेवलपर्स के कई घंटे बर्बाद होते हैं और CI computing cost तेज़ी से बढ़ती है

Source File System (SourceFS)

  • SourceFS कोई नया build system नहीं, बल्कि मौजूदा workflow में integrate किया जा सकने वाला high-performance virtual file system है
    • यह Android codebase के checkout और build को बहुत तेज़ बनाता है, और migration का बोझ लगभग न के बराबर है
    • इसका मूल विचार है सभी files को virtualize करना, उन्हें केवल ज़रूरत पड़ने पर materialize करना, और इस पूरी प्रक्रिया को पारदर्शी तरीके से संभालना
  • checkout acceleration: पूरे codebase का virtual file representation बनाया जाता है, और content केवल access के समय लाया जाता है
    • फ़ाइलें वास्तविक जैसी दिखती हैं, लेकिन अधिकांश files virtual स्थिति में ही रहती हैं, जिससे disk space बचता है
    • Git और Repo के साथ पूरी तरह compatible
  • build acceleration: हर build stage एक lightweight sandbox में चलती है, जो input/output और environment को रिकॉर्ड करती है
    • समान stage को दोबारा चलाने के बजाय उसका result reuse किया जाता है, और केवल बदले हुए stages नए सिरे से चलाए जाते हैं
    • यह सिर्फ compilation ही नहीं, बल्कि linking, packaging, document generation जैसे पूरे build process पर लागू होता है
  • अंदरूनी रूप से यह high-performance caching और replay algorithms, efficient sandboxing, और Rust-based backend का उपयोग करता है
    • लगभग zero overhead के साथ इसे पूरे संगठन में scale किया जा सकता है

तेज़ builds, कुशल storage, और कम लागत

  • SourceFS environment में code checkout मौजूदा तरीकों की तुलना में 20x से अधिक तेज़ है
    • डेवलपर्स मौजूदा Git tree जैसा ही workflow बनाए रखते हुए SourceFS folder में काम कर सकते हैं
  • disk usage में कमी उन device developers के लिए बड़ा फ़ायदा है, जिन्हें कई codebase के बीच switch करना पड़ता है
    • अलग-अलग device versions के बीच switch करते समय या बड़े bug fixes के दौरान भी छोटे GitHub repository जितनी हल्की workflow के साथ काम किया जा सकता है
  • build speed अधिकतम 9x तक बेहतर होती है, जिससे सामान्य developer machine पर भी बड़े builds जल्दी पूरे हो जाते हैं
    • CI pipeline का feedback loop छोटा होने से developer productivity अधिकतम होती है
  • cost reduction का असर 14x तक पहुँचता है
    • high-performance machine की तुलना में सामान्य machine पर SourceFS का उपयोग ज़्यादा तेज़ और सस्ता हो सकता है
    • उसी computing budget में अधिक काम किया जा सकता है

मौजूदा विकल्पों से तुलना

  • SourceFS मौजूदा approaches की सीमाओं को पार करता है
    • Bazel, Buck2 जैसे नए build system में migration बड़े projects में व्यावहारिक रूप से कठिन है, और multi-OS (जैसे Yocto, Android, QNX) वाले device codebase में यह जटिलता और बढ़ जाती है
    • SourceFS ऐसे migration के बिना भी वही performance gains दे सकता है
  • compiler wrappers (REClient, Goma आदि) केवल कुछ build stages को तेज़ करते हैं और checkout पर असर नहीं डालते
    • command-line flags parsing पर निर्भर होने की वजह से अनपेक्षित errors की संभावना रहती है

आगे की योजना

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

2 टिप्पणियां

 
ganadist 2025-10-25

लगता है Android में पहले से ही ऐसा ही कुछ इस्तेमाल हो रहा है।
 
GN⁺ 2025-10-24
Hacker News राय

  • लगता है कि टीम का कुछ हिस्सा ex-Googler है, लेकिन यह उस Piper-आधारित srcfs जैसा नहीं है जिसे हम जानते हैं
    कुछ समानताएँ हैं, लेकिन विवरण लगभग नहीं के बराबर हैं, और self-hosting version के लिए भी “Talk to us” जैसी pricing policy है, जो निराशाजनक है

    • काश Google या Meta अपने अंदरूनी magic VFS को open source के रूप में जारी करते। Meta का EdenFS फिलहाल सबसे नज़दीकी लगता है
    • यह सच में बहुत परिचित लग रहा है। commit deadbeef के समय पूरे tree को materialize किए बिना भी monorepo के सिर्फ़ एक हिस्से को build किया जा सकता था
      और pricing की बात करें तो, अगर कोई टीम अरबों लाइनों वाले codebase को संभाल रही है, तो क्या “TalkToUs” pricing भी वहन नहीं कर सकती?
      Linux जैसे open source प्रोजेक्ट भी मेरे laptop पर ठीक चलते हैं

  • इसे देखकर पुराने ClearCase के MVFS की याद आ गई
    build के समय open(2), getenv(3) जैसी calls को intercept करके यह रिकॉर्ड किया जाता था कि किस tool ने किस environment में file का कौन-सा version इस्तेमाल किया
    अगर conditions वही हों, तो पुराने results को “winked-in” करके reuse किया जाता था, और filesystem स्तर पर version control भी संभव था
    उदाहरण के लिए, file.c@@/trunk/branch/subbranch/3 जैसे path से access किया जा सकता था

  • शीर्षक में दिया गया समय का आँकड़ा थोड़ा बढ़ा-चढ़ाकर कहा हुआ लगता है
    सोच रहा हूँ कि क्या ये EdenFS या git fuse जैसी किसी चीज़ को product बनाना चाहते हैं

    • ये दावा करते हैं कि build steps को system-independent तरीके से cache किया जाता है
      यानी “पहले जैसे ही build steps अपने-आप skip हो जाते हैं और results reuse हो जाते हैं” — यह इतना अच्छा लगता है कि यक़ीन करना मुश्किल है
    • आख़िरकार यह build output caching का थोड़ा और विस्तारित रूप ही लगता है

  • यह बस commercial content marketing जैसा लगता है। तकनीकी details लगभग नहीं हैं
    पहले जब मैं build engineer के रूप में काम करता था, तब कुछ असरदार tips ये थे:
    tmpfs में build करना, बड़ी files को copy करने के बजाय symlink/hardlink का उपयोग करना, libeatmydata से अनावश्यक I/O कम करना,
    और सही cross compiler चुनना
    असल में महत्वपूर्ण बात build system को optimize करना और बदलते नहीं होने वाले intermediate artifacts को cache करना है

    • लेकिन ये बुनियादी tips उस समस्या को हल नहीं करतीं जिसका दावा यह product करता है

  • नमस्ते, मैं Source.dev का सह-संस्थापक Serban हूँ
    upvotes और discussion के लिए धन्यवाद। शुरुआती startup के लिए ऐसा feedback वाकई बहुत मायने रखता है
    यह देखकर खुशी होती है कि जो हम बना रहे हैं, वह सच में valuable लग रहा है

    • जिज्ञासा से पूछ रहा हूँ, क्या यह Python के fabricate की तरह strace से file access track करने वाले तरीके जैसा है?

  • “SourceFS से build speed 9 गुना बढ़ जाती है” यह पंक्ति देखकर हँसी आ गई
    build जितना लंबा चले, तलवारबाज़ी का अभ्यास करने का उतना ज़्यादा समय मिलता है, इसलिए slow builds के भी अपने फ़ायदे हैं

  • उनके performance claims उन distributed Android build systems से भी बहुत आगे लगते हैं जिन्हें मैंने इस्तेमाल किया है
    जानना चाहता हूँ कि इनके पास कौन-सा secret sauce है

    • कहीं ऐसा तो नहीं कि यह बस थोड़ा ज़्यादा fancy ccache हो?

  • जब build “काफ़ी तेज़” के स्तर तक पहुँच जाती है, तो codebase को समझने के दर्दनाक काम के लिए business motivation ही ख़त्म हो जाती है
    अब बस 1 billion lines वाले codebase की ओर बढ़ने का रास्ता बचता है

  • विवरण पढ़कर लगता है कि यह Android source के लिए ही बना है। जानना चाहता हूँ कि ऐसा क्यों है, और क्या इसे दूसरे codebases पर भी लागू किया जा सकता है

    • मेरी समझ से, यह सिर्फ़ तब मायने रखता है जब पूरा code उस सबसे बड़ी build machine की memory में नहीं समाता जिसे कोई organization चला सकती है
    • page पर इसका कारण काफ़ी अच्छे से समझाया गया है