- SourceFS est un système de fichiers virtuel haute performance conçu pour résoudre les problèmes de vitesse et d’efficacité des builds de grandes codebases d’appareils
- Il accélère jusqu’à 9 fois les builds Android et de plus de 10 fois les checkouts de code, tout en réduisant l’utilisation disque de 83 % et les coûts de calcul d’un facteur 14
- Son principe clé repose sur la virtualisation des fichiers et la matérialisation à la demande (materialization) : les fichiers semblent réels, mais leur contenu n’est chargé qu’au moment nécessaire
- Pendant le processus de build, la plupart des étapes peuvent être rejouées instantanément grâce à un cache basé sur des sandbox qui enregistrent et réutilisent les entrées/sorties et l’environnement
Le problème des builds lents et des checkouts de code
- Les appareils connectés modernes fonctionnent sur des codebases de plusieurs centaines de millions de lignes
- Le noyau Linux compte environ 40 millions de lignes, Android AOSP plus de 140 millions, et un appareil réel dépasse les 200 millions avec le support matériel, les fonctions personnalisées et le code des services
- Les véhicules électriques (EV) dépassent les 500 millions de lignes, et ce volume continue d’augmenter avec les mises à jour logicielles
- Un checkout de code implique le téléchargement de centaines de Go de données, et un build passe par des centaines de milliers d’étapes
- À cause de l’imperfection du graphe de dépendances, de petits changements peuvent provoquer de larges reconstructions ou produire des résultats incorrects
- Résultat : plusieurs heures perdues chaque jour par les développeurs et une explosion des coûts de calcul en CI
Source File System (SourceFS)
- SourceFS n’est pas un nouveau système de build, mais un système de fichiers virtuel haute performance intégrable aux workflows existants
- Il améliore radicalement la vitesse de checkout et de build des codebases Android, avec une charge de migration quasi nulle
- Le principe central consiste à virtualiser tous les fichiers, à ne les matérialiser qu’en cas de besoin, et à traiter cela de manière transparente
- Accélération du checkout : création d’une représentation virtuelle de l’ensemble de la codebase, dont le contenu n’est chargé qu’au moment de l’accès
- Les fichiers semblent réels, mais la plupart restent virtuels, ce qui économise l’espace disque
- Compatibilité complète avec Git et Repo
- Accélération du build : chaque étape de build s’exécute dans une sandbox légère qui enregistre les entrées/sorties et l’environnement
- Les étapes identiques réutilisent les résultats sans réexécution, seules les étapes modifiées sont relancées
- Cela s’applique à l’ensemble du processus de build : compilation, édition de liens, packaging, génération de documentation, etc.
- En interne, SourceFS utilise des algorithmes de cache et de replay haute performance, un sandboxing efficace et un backend en Rust
- Le système peut être étendu à l’échelle de toute l’organisation avec un surcoût presque nul
Builds plus rapides, stockage plus efficace, coûts réduits
- Dans un environnement SourceFS, le checkout de code est plus de 20 fois plus rapide que l’approche classique
- Les développeurs peuvent travailler dans un dossier SourceFS tout en conservant le même workflow qu’avec un arbre Git classique
- La réduction de l’utilisation disque est un avantage majeur pour les développeurs d’appareils qui doivent passer d’une codebase à une autre
- Même lors du passage entre plusieurs versions d’appareils ou de grosses corrections de bugs, ils peuvent travailler avec la même légèreté que sur un petit dépôt GitHub
- La vitesse de build peut être multipliée par 9, permettant d’achever rapidement de grands builds même sur une machine de développeur standard
- Le raccourcissement de la boucle de feedback en CI maximise la productivité du développement
- Les réductions de coûts peuvent atteindre un facteur 14
- Utiliser SourceFS sur une machine standard est à la fois plus rapide et moins coûteux que d’utiliser une machine hautes performances
- Il devient possible d’effectuer davantage de travail avec le même budget de calcul
Comparaison avec les alternatives existantes
- SourceFS surmonte les limites des approches existantes
- Une migration vers de nouveaux systèmes de build comme Bazel ou Buck2 est difficilement réaliste pour les grands projets, et la complexité double dans les codebases d’appareils multi-OS (par ex. Yocto, Android, QNX)
- SourceFS offre les mêmes gains de performance sans imposer cette migration
- Les wrappers de compilateur (REClient, Goma, etc.) n’accélèrent qu’une partie des étapes de build et n’apportent rien au checkout
- Ils dépendent de l’analyse des flags en ligne de commande, avec un risque d’erreurs inattendues
Feuille de route
2 commentaires
Il semble qu’ils utilisent déjà quelque chose de similaire sur Android.
Avis Hacker News
Une partie de l’équipe semble être composée d’ex-Googlers, mais ce n’est pas le srcfs basé sur Piper que nous connaissons
Il y a des similitudes, mais presque aucun détail, et la version self-hosted suit aussi une politique tarifaire du genre « Talk to us », ce qui est regrettable
Et concernant le prix, si c’est une équipe qui gère une base de code de plusieurs dizaines de milliards de lignes, elle peut sûrement se permettre une tarification « TalkToUs », non ?
Même un projet open source comme Linux tourne très bien sur mon laptop
Ça me rappelle l’ancien MVFS de ClearCase
Lors de la build, il interceptait des appels comme open(2) ou getenv(3) pour enregistrer quels outils utilisaient quelles versions de fichiers et dans quel environnement
Si les conditions étaient identiques, il réutilisait le résultat existant via un « winked-in », et permettait aussi la gestion de versions au niveau du système de fichiers
Par exemple, on pouvait accéder à quelque chose comme file.c@@/trunk/branch/subbranch/3
Les chiffres annoncés dans le titre semblent un peu exagérés
Je me demande s’ils essaient de transformer en produit quelque chose comme EdenFS ou un git fuse du même genre
Du genre : « les étapes de build identiques à la précédente sont automatiquement sautées et leur résultat réutilisé », ce qui paraît presque trop beau pour être crédible
Ça ressemble juste à du content marketing commercial. Il n’y a presque aucun détail technique
Pour partager quelques astuces qui m’avaient été utiles quand je travaillais comme ingénieur build :
builder sur tmpfs, utiliser des symlinks/hardlinks au lieu de copier les gros fichiers, réduire les I/O inutiles avec libeatmydata,
et bien choisir le compilateur croisé
Le plus important, c’est vraiment d’optimiser le système de build et de bien mettre en cache les artefacts intermédiaires qui ne changent pas
Bonjour, je suis Serban, cofondateur de Source.dev
Merci pour les upvotes et la discussion. Pour une startup en phase initiale, ce type de retour est vraiment précieux
Je suis ravi de voir que ce que nous construisons est perçu comme ayant une vraie valeur
La formule « SourceFS rend les builds 9 fois plus rapides » m’a fait rire
Plus une build est longue, plus ça laisse de temps pour s’entraîner au sabre, donc les builds lentes ont aussi leurs avantages
Leurs affirmations de performance vont bien au-delà des systèmes de build Android distribués que j’ai utilisés
Je me demande quelle sauce secrète ils ont
Quand une build devient « suffisamment rapide », il n’y a plus de motivation business pour faire le travail pénible consistant à comprendre la base de code
Il ne reste plus qu’à prendre la route vers une base de code d’un milliard de lignes
D’après la description, cela semble dédié au code source Android. Je me demande pourquoi, et si cela peut s’appliquer à d’autres bases de code