SourceFS - Memangkas build Android yang memakan waktu lebih dari 2 jam menjadi 15 menit dengan sistem file virtual

 (source.dev)
4 poin oleh GN⁺ 2025-10-24 | 2 komentar | Bagikan ke WhatsApp
  • SourceFS adalah sistem file virtual berperforma tinggi yang dirancang untuk mengatasi masalah kecepatan build dan efisiensi pada codebase perangkat berskala besar
  • Meningkatkan kecepatan build Android hingga 9x dan kecepatan checkout kode lebih dari 10x, sekaligus mengurangi penggunaan disk sebesar 83% dan memangkas biaya komputasi hingga 14x
  • Prinsip utamanya adalah virtualisasi file dan materialisasi on-demand, dengan struktur yang terlihat seperti file nyata tetapi hanya memuat isinya saat benar-benar dibutuhkan
  • Dalam proses build, sebagian besar tahap dapat langsung diputar ulang (replay) melalui caching berbasis sandbox yang merekam dan menggunakan ulang I/O serta environment

Masalah build lambat dan checkout kode

  • Perangkat modern yang saling terhubung dijalankan oleh codebase berskala ratusan juta baris
    • Kernel Linux memiliki sekitar 40 juta baris, Android AOSP lebih dari 140 juta baris, dan perangkat nyata melampaui 200 juta baris setelah ditambah dukungan hardware, fitur kustom, dan kode layanan
    • Kendaraan listrik (EV) mencapai lebih dari 500 juta baris, dan terus bertambah melalui pembaruan perangkat lunak
  • Saat checkout kode, ratusan GB data harus diunduh, dan proses build melewati ratusan ribu tahap
    • Karena graf dependensi yang tidak sempurna, perubahan kecil pun dapat memicu rebuild berskala besar atau menghasilkan output yang salah
  • Akibatnya, terjadi kehilangan waktu developer selama berjam-jam setiap hari dan lonjakan biaya komputasi CI

Source File System (SourceFS)

  • SourceFS bukan sistem build baru, melainkan sistem file virtual berperforma tinggi yang dapat diintegrasikan ke workflow yang sudah ada
    • Mempercepat checkout dan build codebase Android secara drastis, dengan beban migrasi yang nyaris tidak ada
    • Prinsip intinya adalah memvirtualisasikan semua file, mematerialisasikannya hanya saat diperlukan, dan melakukan proses ini secara transparan
  • Percepatan checkout: membuat representasi file virtual untuk seluruh codebase, lalu hanya memuat isinya saat diakses
    • File terlihat seperti file nyata, tetapi sebagian besar tetap dalam keadaan virtual sehingga menghemat ruang disk
    • Sepenuhnya kompatibel dengan Git dan Repo
  • Percepatan build: setiap tahap build dijalankan di dalam sandbox ringan yang merekam I/O dan environment
    • Tahap yang sama menggunakan ulang hasil tanpa dijalankan kembali, dan hanya tahap yang berubah yang dijalankan ulang
    • Berlaku untuk seluruh proses build, bukan hanya kompilasi tetapi juga linking, packaging, pembuatan dokumentasi, dan lainnya
  • Secara internal menggunakan algoritme caching dan replay berperforma tinggi, sandboxing yang efisien, serta backend berbasis Rust
    • Dapat diskalakan ke seluruh organisasi dengan overhead yang nyaris nol

Build lebih cepat, penyimpanan lebih efisien, biaya lebih rendah

  • Di lingkungan SourceFS, checkout kode lebih dari 20x lebih cepat dibandingkan metode lama
    • Developer dapat bekerja di folder SourceFS sambil mempertahankan workflow yang sama seperti pada tree Git biasa
  • Pengurangan penggunaan disk menjadi keuntungan besar bagi developer perangkat yang harus berpindah-pindah di antara banyak codebase
    • Bahkan saat berpindah antar versi perangkat atau memperbaiki bug dalam skala besar, mereka tetap bisa bekerja seringan repository GitHub berukuran kecil
  • Kecepatan build meningkat hingga 9x, memungkinkan build besar selesai cepat bahkan di mesin developer biasa
    • Memperpendek feedback loop pipeline CI untuk memaksimalkan produktivitas pengembangan
  • Penghematan biaya bisa mencapai 14x
    • Menggunakan SourceFS di mesin biasa lebih cepat dan lebih murah dibanding memakai mesin berperforma tinggi
    • Lebih banyak pekerjaan dapat diselesaikan dengan anggaran komputasi yang sama

Perbandingan dengan alternatif yang ada

  • SourceFS mengatasi keterbatasan pendekatan yang ada
    • Migrasi ke sistem build baru seperti Bazel atau Buck2 sulit dilakukan secara realistis pada proyek berskala besar, dan kompleksitasnya berlipat pada codebase perangkat yang mencakup banyak OS (misalnya Yocto, Android, QNX)
    • SourceFS memberikan peningkatan performa yang sama tanpa perlu migrasi seperti itu
  • Compiler wrapper (seperti REClient, Goma, dan lain-lain) hanya mempercepat sebagian tahap build dan tidak membantu checkout
    • Bergantung pada parsing flag command line sehingga berpotensi menimbulkan error tak terduga

Rencana ke depan

Bacaan terkait

2 komentar

 
GN⁺ 2025-10-24
Opini Hacker News

  • Sepertinya sebagian timnya adalah mantan Googler, tetapi ini berbeda dari srcfs berbasis Piper yang kita kenal
    Memang ada kemiripan, tetapi detailnya hampir tidak ada, dan versi self-hosting-nya juga memakai kebijakan harga model “Talk to us”, jadi agak disayangkan

    • Andai Google atau Meta merilis magic VFS internal mereka sebagai open source. Yang paling mendekati sejauh ini adalah EdenFS milik Meta
    • Ini terasa sangat familiar. Pada commit deadbeef, kita bisa membangun hanya sebagian dari monorepo tanpa harus mematerialisasi seluruh tree
      Soal harga juga, kalau tim menangani codebase dengan puluhan miliar baris kode, bukankah harga “TalkToUs” seharusnya masih sanggup ditanggung?
      Open source seperti Linux pun berjalan baik di laptop saya

  • Ini mengingatkan saya pada MVFS milik ClearCase di masa lalu
    Saat build, ia mencegat panggilan seperti open(2), getenv(3), dan semacamnya untuk mencatat tool mana yang memakai versi file apa dalam lingkungan seperti apa
    Jika kondisinya sama, hasil lama akan di-"winked-in" untuk dipakai ulang, dan version control juga bisa dilakukan di level filesystem
    Misalnya, file bisa diakses dengan bentuk seperti file.c@@/trunk/branch/subbranch/3

  • Angka waktu di judul terasa agak dilebih-lebihkan
    Saya jadi bertanya-tanya apakah ini semacam upaya memprodukkan EdenFS atau git fuse

    • Mereka mengklaim melakukan caching tahap build secara independen dari sistem
      Katanya, “tahap build yang sama seperti sebelumnya otomatis dilewati dan hasilnya dipakai ulang”, tetapi terdengar terlalu bagus sampai sulit dipercaya
    • Pada akhirnya ini terlihat seperti bentuk caching output build yang diperluas

  • Ini terasa seperti content marketing komersial biasa. Hampir tidak ada detail teknis
    Kalau berbagi beberapa tips yang dulu efektif saat saya bekerja sebagai build engineer, antara lain build di tmpfs, memakai symlink/hardlink alih-alih menyalin file besar, mengurangi I/O yang tidak perlu dengan libeatmydata,
    dan juga memilih cross-compiler dengan baik
    Yang benar-benar penting adalah mengoptimalkan build system dan melakukan caching artefak perantara yang tidak berubah dengan baik

    • Namun, tip-tip dasar seperti ini memang tidak menyelesaikan masalah yang diklaim produk ini

  • Halo, saya Serban, co-founder Source.dev
    Terima kasih atas upvote dan diskusinya. Bagi startup tahap awal, feedback seperti ini benar-benar sangat berarti
    Senang rasanya melihat bahwa apa yang kami bangun benar-benar dianggap bernilai

    • Saya penasaran, apakah ini mirip dengan pendekatan Python fabricate, yang melacak akses file dengan strace?

  • Saya tertawa saat melihat kalimat “SourceFS mempercepat build 9x”
    Semakin lama build berjalan, semakin banyak waktu untuk latihan pedang, jadi build yang lambat pun punya kelebihannya sendiri

  • Klaim performa mereka jauh melampaui distributed Android build system yang pernah saya pakai
    Saya penasaran rahasia apa yang mereka punya

    • Mungkin jangan-jangan ini cuma ccache yang dibuat lebih mewah

  • Begitu build sudah mencapai tingkat “cukup cepat”, hilanglah insentif bisnis untuk melakukan pekerjaan menyakitkan demi memahami codebase
    Sekarang yang tersisa hanya jalan menuju codebase 1 miliar baris

  • Dari penjelasannya, ini terdengar seperti khusus untuk source Android. Saya penasaran kenapa begitu, dan apakah ini bisa diterapkan ke codebase lain

    • Menurut pemahaman saya, ini hanya masuk akal jika seluruh kode tidak muat di memori dari mesin build terbesar yang bisa dijalankan organisasi tersebut
    • Alasannya dijelaskan cukup jelas di halamannya