SourceFS - Sanal dosya sistemiyle 2 saati aşan Android derlemelerini 15 dakikaya indiriyor

 (source.dev)
4 puan yazan GN⁺ 2025-10-24 | 2 yorum | WhatsApp'ta paylaş
  • SourceFS, büyük ölçekli cihaz kod tabanlarında derleme hızı ve verimlilik sorunlarını çözmek için tasarlanmış yüksek performanslı bir sanal dosya sistemi
  • Android derleme hızını 9 kata kadar, kod checkout hızını ise 10 katın üzerine çıkarırken disk kullanımını %83 azaltıyor ve işlem maliyetlerini 14 kat düşürüyor
  • Temel yaklaşım, dosya sanallaştırma ve isteğe bağlı somutlaştırma (materialization) yöntemi; dosyalar gerçekmiş gibi görünse de içerikleri yalnızca gerektiği anda yükleniyor
  • Derleme sürecinde girdi/çıktı ve ortamı kaydedip yeniden kullanan sandbox tabanlı önbellekleme sayesinde derleme adımlarının çoğu anında yeniden oynatılabiliyor (replay)

Yavaş derleme ve kod checkout sorunu

  • Modern bağlantılı cihazlar, yüz milyonlarca satırlık kod tabanlarıyla çalışıyor
    • Linux çekirdeği yaklaşık 40 milyon satır, Android AOSP ise 140 milyondan fazla satır içeriyor; gerçek cihazlarda buna donanım desteği, özel özellikler ve servis kodları eklendiğinde toplam 200 milyon satırı aşıyor
    • Elektrikli araçlar (EV) 500 milyon satırın üzerine çıkıyor ve yazılım güncellemeleriyle bu sayı sürekli artıyor
  • Kod checkout sırasında yüzlerce GB veri indiriliyor ve derleme süreci yüz binlerce adımdan geçiyor
    • Bağımlılık grafiğindeki eksiklikler nedeniyle küçük değişiklikler bile geniş çaplı yeniden derlemelere yol açabiliyor veya hatalı sonuçlar üretebiliyor
  • Sonuç olarak her gün saatlerce geliştirici zamanı kaybediliyor ve CI işlem maliyetleri hızla yükseliyor

Source File System (SourceFS)

  • SourceFS, yeni bir derleme sistemi değil; mevcut iş akışlarına entegre edilebilen yüksek performanslı bir sanal dosya sistemi
    • Android kod tabanlarının checkout ve derleme hızını dramatik biçimde artırıyor; üstelik geçiş yükü neredeyse yok
    • Temel mantık, tüm dosyaları sanallaştırmak, yalnızca gerektiğinde somutlaştırmak (materialize) ve bu süreci şeffaf biçimde yürütmek
  • Checkout hızlandırma: Tüm kod tabanının sanal dosya gösterimini oluşturuyor ve içerikleri yalnızca erişim anında yüklüyor
    • Dosyalar gerçekmiş gibi görünüyor, ancak çoğu dosya sanal durumda kaldığı için disk alanından tasarruf ediliyor
    • Git ve Repo ile tamamen uyumlu
  • Derleme hızlandırma: Her derleme adımı, girdi/çıktı ve ortamı kaydeden hafif bir sandbox içinde çalışıyor
    • Aynı adımlar yeniden çalıştırılmadan sonuçlar tekrar kullanılıyor; yalnızca değişen adımlar yeniden yürütülüyor
    • Yalnızca derleme değil; linkleme, paketleme, dokümantasyon üretimi gibi tüm derleme sürecine uygulanabiliyor
  • İç tarafta yüksek performanslı önbellekleme ve replay algoritmaları, verimli sandboxing ve Rust tabanlı bir backend kullanıyor
    • Neredeyse sıfır ek yükle organizasyon geneline ölçeklenebiliyor

Hızlı derleme, verimli depolama, daha düşük maliyet

  • SourceFS ortamında kod checkout işlemi mevcut yaklaşıma göre 20 kattan fazla daha hızlı
    • Geliştiriciler, mevcut Git ağacıyla aynı iş akışını koruyarak SourceFS klasöründe çalışabiliyor
  • Disk kullanımındaki azalma, birden fazla kod tabanı arasında geçiş yapmak zorunda olan cihaz geliştiricileri için büyük avantaj sağlıyor
    • Farklı cihaz sürümleri arasında geçişte veya geniş kapsamlı hata düzeltmelerinde bile küçük bir GitHub deposu kadar hafif çalışmak mümkün
  • Derleme hızı 9 kata kadar artıyor; büyük ölçekli derlemeler sıradan geliştirici makinelerinde bile hızla tamamlanabiliyor
    • CI pipeline geri bildirim döngüsünün kısalmasıyla geliştirici verimliliği en üst düzeye çıkıyor
  • Maliyet tasarrufu etkisi 14 kata kadar ulaşıyor
    • Yüksek performanslı makineler yerine standart makinelerde SourceFS kullanmak daha hızlı ve daha ucuz olabiliyor
    • Aynı işlem bütçesiyle daha fazla iş yapmak mümkün hale geliyor

Mevcut alternatiflerle karşılaştırma

  • SourceFS, geleneksel yaklaşımların sınırlarını aşıyor
    • Bazel, Buck2 gibi yeni derleme sistemlerine geçiş, büyük projelerde pratikte zor; çoklu OS (ör. Yocto, Android, QNX) içeren cihaz kod tabanlarında ise karmaşıklık katlanıyor
    • SourceFS, böyle bir geçiş gerektirmeden aynı performans kazanımlarını sunuyor
  • Derleyici wrapper'ları (REClient, Goma vb.) yalnızca bazı derleme adımlarını hızlandırıyor ve checkout üzerinde etkili olmuyor
    • Komut satırı bayraklarını ayrıştırmaya dayandıkları için beklenmedik hatalara yol açma ihtimali bulunuyor

Gelecek planları

İlgili okumalar

2 yorum

 
ganadist 2025-10-25

Görünüşe göre Android tarafında benzeri bir şey zaten kullanılıyor.
 
GN⁺ 2025-10-24
Hacker News görüşleri

  • Ekibin bir kısmı ex-Googler gibi görünüyor ama bu, bildiğimiz Piper tabanlı srcfs ile aynı değil
    Benzer yanları var ama ayrıntı neredeyse hiç yok ve self-hosting sürümü için bile fiyatlandırma “Talk to us” tarzında olduğu için hayal kırıklığı yaratıyor

    • Keşke Google ya da Meta, dahili magic VFS sistemlerini açık kaynak olarak yayımlasa. Meta’nın EdenFS’i buna en çok yaklaşan şey gibi duruyor
    • Bu bana gerçekten çok tanıdık geliyor. commit deadbeef noktasında tüm ağacı materialize etmeden de monorepo’nun sadece bir kısmını build edebiliyorduk
      Bir de fiyat meselesi var; milyarlarca satırlık bir kod tabanıyla çalışan bir ekip için “TalkToUs” fiyatlandırması karşılanabilir değil mi?
      Linux gibi açık kaynak projeler bile dizüstü bilgisayarımda gayet iyi çalışıyor

  • Bunu görünce aklıma eski ClearCase MVFS geldi
    Build sırasında open(2), getenv(3) gibi çağrıları yakalayıp hangi aracın, hangi ortamda, dosyanın hangi sürümünü kullandığını tamamen kaydediyordu
    Koşullar aynıysa mevcut sonucu “winked-in” yaparak yeniden kullanıyordu ve dosya sistemi seviyesinde sürüm kontrolü de mümkündü
    Örneğin file.c@@/trunk/branch/subbranch/3 gibi bir yolla erişilebiliyordu

  • Başlıktaki süre rakamları biraz abartılı geliyor
    Acaba EdenFS ya da git fuse benzeri bir şeyi ürünleştirmeye mi çalışıyorlar diye düşündüm

    • Build adımlarını sistemden bağımsız olarak cache’lediklerini iddia ediyorlar
      “Öncekiyle aynı olan build adımları otomatik olarak atlanır ve sonuç yeniden kullanılır” gibi bir şey söylüyorlar ama kulağa fazla iyi geldiği için inanması zor
    • Sonuçta build çıktısı cache’lemesinin biraz daha genişletilmiş bir biçimi gibi görünüyor

  • Bu bana düpedüz ticari içerik pazarlaması gibi geliyor. Neredeyse hiç teknik ayrıntı yok
    Eskiden build mühendisi olarak çalışırken etkili bulduğum birkaç ipucunu paylaşayım:
    tmpfs üzerinde build almak, büyük dosyalarda kopyalama yerine symlink/hardlink kullanmak, libeatmydata ile gereksiz I/O’yu azaltmak
    ve doğru çapraz derleyiciyi seçmek gibi şeyler işe yarıyordu
    Asıl önemli olan, build sistemini optimize etmek ve değişmeyen ara çıktıların cache’lenmesini iyi yapmak

    • Ama bu temel ipuçları, bu ürünün çözdüğünü iddia ettiği problemi çözmüyor

  • Merhaba, ben Source.dev’in kurucu ortaklarından Serban
    Upvote’lar ve tartışma için teşekkürler. Erken aşamadaki bir startup için bu tür geri bildirimler gerçekten çok değerli
    Yaptığımız şeyin gerçekten değerli bulunduğunu hissetmek sevindirici

    • Merakımdan soruyorum, bu yaklaşım Python’daki fabricate gibi strace ile dosya erişimini izleme yöntemine benziyor mu?

  • “SourceFS ile build hızı 9 kat artıyor” ifadesini görünce güldüm
    Build ne kadar uzun sürerse kılıç çalışmak için o kadar fazla zamanım oluyor, yani yavaş build’in de kendine göre bir avantajı var

  • Onların performans iddiaları, benim kullandığım dağıtık Android build sistemlerinden çok daha ileride görünüyor
    Nasıl bir gizli sosları olduğunu merak ediyorum

    • Belki de sadece daha şık paketlenmiş bir ccache düzeyindedir

  • Build “yeterince hızlı” hale gelince, kod tabanını anlamak için gereken o sancılı işi yapmaya yönelik iş motivasyonu ortadan kalkıyor
    Artık geriye sadece 1 milyar satırlık kod tabanına giden yol kalıyor

  • Açıklamaya bakınca Android kaynağına özelmiş gibi duruyor. Neden böyle olduğunu ve başka kod tabanlarına da uygulanıp uygulanamayacağını merak ediyorum

    • Benim anladığım kadarıyla bu, ancak tüm kodun kurumun çalıştırabileceği en büyük build makinesinin belleğine sığmadığı durumlarda anlamlı
    • Sayfanın kendisinde bunun nedeni oldukça iyi açıklanmış