- SourceFS ist ein leistungsstarkes virtuelles Dateisystem, das entwickelt wurde, um Probleme bei Build-Geschwindigkeit und Effizienz großer Device-Codebasen zu lösen
- Beschleunigt Android-Builds um bis zu das 9-Fache und Code-Checkouts um mehr als das 10-Fache, reduziert den Speicherplatzverbrauch um 83 % und senkt die Computing-Kosten um das 14-Fache
- Das Kernprinzip ist Dateivirtualisierung und On-Demand-Materialisierung: Dateien erscheinen wie echte Dateien, aber ihr Inhalt wird erst dann geladen, wenn er benötigt wird
- Während des Build-Prozesses werden die meisten Build-Schritte durch Sandbox-basiertes Caching, das I/O und Umgebung aufzeichnet und wiederverwendet, sofort wiedergegeben (replay)
Das Problem langsamer Builds und Code-Checkouts
- Moderne vernetzte Geräte laufen auf Codebasen mit hunderten Millionen Zeilen Code
- Der Linux-Kernel umfasst etwa 40 Millionen Zeilen, Android AOSP mehr als 140 Millionen Zeilen, und reale Geräte überschreiten mit Hardware-Support, benutzerdefinierten Funktionen und Service-Code die Marke von 200 Millionen Zeilen
- Elektrofahrzeuge (EVs) kommen auf mehr als 500 Millionen Zeilen, mit kontinuierlichem Wachstum durch Software-Updates
- Beim Code-Checkout müssen hunderte GB an Daten heruntergeladen werden, und Builds bestehen aus mehreren hunderttausend Schritten
- Aufgrund unvollständiger Abhängigkeitsgraphen können schon kleine Änderungen große Rebuilds auslösen oder zu fehlerhaften Ergebnissen führen
- Das Ergebnis sind täglich mehrere verlorene Entwicklerstunden und stark steigende CI-Computing-Kosten
Source File System (SourceFS)
- SourceFS ist kein neues Build-System, sondern ein leistungsstarkes virtuelles Dateisystem, das sich in bestehende Workflows integrieren lässt
- Es verbessert Checkout- und Build-Geschwindigkeit von Android-Codebasen drastisch, bei nahezu keinem Migrationsaufwand
- Das Kernprinzip besteht darin, alle Dateien zu virtualisieren, sie nur bei Bedarf zu materialisieren und diesen Prozess transparent abzuwickeln
- Checkout-Beschleunigung: Es wird eine virtuelle Dateidarstellung der gesamten Codebasis erstellt, und Inhalte werden nur beim Zugriff geladen
- Dateien sehen echt aus, aber die meisten bleiben virtuell, was Speicherplatz spart
- Vollständig kompatibel mit Git und Repo
- Build-Beschleunigung: Jeder Build-Schritt läuft in einer leichtgewichtigen Sandbox, die I/O und Umgebung aufzeichnet
- Identische Schritte verwenden Ergebnisse erneut, ohne neu ausgeführt zu werden; nur geänderte Schritte werden neu durchgeführt
- Gilt nicht nur für das Kompilieren, sondern für den gesamten Build-Prozess einschließlich Linken, Packaging und Dokumentationserzeugung
- Intern kommen leistungsstarke Caching- und Replay-Algorithmen, effizientes Sandboxing und ein Rust-basiertes Backend zum Einsatz
- Mit nahezu null Overhead auf die gesamte Organisation skalierbar
Schnellere Builds, effizienterer Speicher, geringere Kosten
- Code-Checkouts in einer SourceFS-Umgebung sind mehr als 20-mal schneller als bisher
- Entwickler können im SourceFS-Ordner arbeiten und dabei denselben Workflow wie mit einem bestehenden Git-Tree beibehalten
- Der geringere Speicherplatzverbrauch ist ein großer Vorteil für Device-Entwickler, die zwischen mehreren Codebasen wechseln müssen
- Selbst beim Wechsel zwischen verschiedenen Device-Versionen oder bei groß angelegten Bugfixes ist ein leichtgewichtiges Arbeiten wie mit einem kleinen GitHub-Repository möglich
- Die Build-Geschwindigkeit steigt um bis zu das 9-Fache, sodass auch auf typischen Entwicklerrechnern große Builds schnell abgeschlossen werden können
- Kürzere Feedback-Loops in CI-Pipelines maximieren die Entwicklungsproduktivität
- Die Kosteneinsparungen erreichen bis zum 14-Fachen
- SourceFS auf normalen Maschinen zu verwenden ist schneller und günstiger als leistungsstarke Maschinen ohne SourceFS einzusetzen
- Mit demselben Computing-Budget lässt sich mehr Arbeit erledigen
Vergleich mit bestehenden Alternativen
- SourceFS überwindet die Grenzen bestehender Ansätze
- Die Migration auf neue Build-Systeme wie Bazel oder Buck2 ist bei großen Projekten in der Praxis schwierig, und bei Device-Codebasen mit mehreren Betriebssystemen (z. B. Yocto, Android, QNX) verdoppelt sich die Komplexität
- SourceFS liefert dieselben Leistungsverbesserungen ohne eine solche Migration
- Compiler-Wrapper (REClient, Goma usw.) beschleunigen nur einen Teil der Build-Schritte und helfen nicht beim Checkout
- Da sie auf das Parsen von Kommandozeilen-Flags angewiesen sind, besteht die Möglichkeit unerwarteter Fehler
Nächste Pläne
2 Kommentare
Es scheint, als würde unter Android bereits etwas Ähnliches verwendet werden.
Hacker-News-Kommentare
Ein Teil des Teams scheint aus Ex-Googlern zu bestehen, aber es ist wohl nicht dasselbe wie das srcfs auf Piper-Basis, das wir kennen
Es gibt zwar Ähnlichkeiten, aber fast keine Details, und auch die Self-Hosting-Version hat nur eine „Talk to us“-Preisgestaltung, was etwas schade ist
Und was die Preise angeht: Wenn ein Team mit einer Codebasis von zig Milliarden Zeilen arbeitet, sollte es sich eine „TalkToUs“-Preisgestaltung nicht leisten können?
Open Source wie Linux läuft auch problemlos auf meinem Laptop
Das erinnert mich an das frühere MVFS von ClearCase
Beim Build wurden Aufrufe wie open(2) und getenv(3) abgefangen, sodass vollständig protokolliert wurde, welches Tool in welcher Umgebung welche Dateiversion verwendet hat
Unter identischen Bedingungen wurden vorhandene Ergebnisse per „winked-in“ wiederverwendet, und Versionsverwaltung war sogar auf Dateisystemebene möglich
Man konnte zum Beispiel auf etwas wie file.c@@/trunk/branch/subbranch/3 zugreifen
Die Zeitangabe im Titel wirkt etwas übertrieben
Ich frage mich, ob hier EdenFS oder eine Art Git-FUSE produktisiert werden soll
Nach dem Motto: „Build-Schritte, die identisch zu früheren sind, werden automatisch übersprungen und ihre Ergebnisse wiederverwendet“ — das klingt fast zu gut, um wahr zu sein
Es wirkt einfach wie kommerzielles Content-Marketing. Technische Details gibt es kaum
Als ich früher als Build Engineer gearbeitet habe, waren ein paar Tipps besonders effektiv:
auf tmpfs bauen, bei großen Dateien statt Kopieren Symlinks/Hardlinks verwenden, mit libeatmydata unnötige I/O reduzieren
und den Cross-Compiler sorgfältig auswählen
Wirklich wichtig ist, das Build-System zu optimieren und unveränderte Zwischenartefakte zu cachen
Hallo, hier ist Serban, Mitgründer von Source.dev
Danke für die Upvotes und die Diskussion. Für ein Startup in einer frühen Phase ist solches Feedback wirklich eine große Hilfe
Ich freue mich, dass es sich so anfühlt, als ob das, was wir bauen, echten Wert hat
Bei der Formulierung „Mit SourceFS werden Builds 9-mal schneller“ musste ich lachen
Je länger ein Build dauert, desto mehr Zeit zum Schwertkampftraining hat man — langsame Builds haben also auch ihre Vorteile
Ihre Performance-Behauptungen liegen weit über den verteilten Android-Build-Systemen, die ich verwendet habe
Ich frage mich, welche geheime Zutat dahintersteckt
Sobald Builds „schnell genug“ sind, verschwindet der geschäftliche Anreiz, die schmerzhafte Arbeit des Verständnisses der Codebasis anzugehen
Dann bleibt nur noch der Weg zu einer Codebasis mit einer Milliarde Zeilen
Der Beschreibung nach klingt es wie etwas speziell für den Android-Quellcode. Ich frage mich, warum das so ist und ob es auch auf andere Codebasen anwendbar wäre