4 pontos por GN⁺ 2025-10-24 | 2 comentários | Compartilhar no WhatsApp
  • O SourceFS é um sistema de arquivos virtual de alto desempenho projetado para resolver os problemas de velocidade e eficiência de builds em codebases de dispositivos em grande escala
  • Aumenta a velocidade de builds de Android em até 9 vezes e a de checkout de código em mais de 10 vezes, reduz o uso de disco em 83% e corta os custos de computação em 14 vezes
  • O princípio central é a virtualização de arquivos com materialização sob demanda (on-demand), uma estrutura em que os arquivos parecem reais, mas seu conteúdo só é carregado no momento necessário
  • Durante o processo de build, a maioria das etapas pode ser reproduzida instantaneamente por meio de cache baseado em sandbox que registra e reutiliza entrada/saída e ambiente

O problema de builds lentos e checkout de código

  • Dispositivos conectados modernos são movidos por codebases com centenas de milhões de linhas de código
    • O kernel Linux tem cerca de 40 milhões de linhas, o Android AOSP tem mais de 140 milhões, e um dispositivo real ultrapassa 200 milhões ao adicionar suporte de hardware, recursos customizados e código de serviços
    • Veículos elétricos (EVs) chegam a mais de 500 milhões de linhas, e isso continua crescendo com atualizações de software
  • No checkout de código, é preciso baixar centenas de GB de dados, e o build passa por centenas de milhares de etapas
    • Devido à imperfeição do grafo de dependências, até pequenas mudanças podem provocar rebuilds em larga escala ou gerar resultados incorretos
  • Como resultado, surgem horas perdidas por desenvolvedor todos os dias e um aumento acentuado nos custos de computação de CI

Source File System (SourceFS)

  • O SourceFS não é um novo sistema de build, mas sim um sistema de arquivos virtual de alto desempenho que pode ser integrado ao workflow existente
    • Ele melhora drasticamente a velocidade de checkout e build de codebases Android, com quase nenhuma carga de migração
    • Seu princípio central é virtualizar todos os arquivos, materializá-los apenas quando necessário e tratar todo esse processo de forma transparente
  • Aceleração de checkout: cria uma representação virtual de arquivos de toda a codebase e só carrega o conteúdo no momento do acesso
    • Os arquivos parecem reais, mas a maioria permanece em estado virtual, economizando espaço em disco
    • Totalmente compatível com Git e Repo
  • Aceleração de build: cada etapa do build roda em uma sandbox leve que registra entrada/saída e ambiente
    • Etapas idênticas reaproveitam os resultados sem reexecução, e apenas as etapas alteradas são executadas novamente
    • Isso se aplica não só à compilação, mas a todo o processo de build, incluindo linkedição, empacotamento e geração de documentação
  • Internamente, usa algoritmos de cache e replay de alto desempenho, sandboxing eficiente e um backend baseado em Rust
    • Pode ser expandido para toda a organização com overhead quase zero

Builds mais rápidos, armazenamento eficiente e redução de custos

  • No ambiente SourceFS, o checkout de código é mais de 20 vezes mais rápido que o convencional
    • Os desenvolvedores podem trabalhar dentro da pasta do SourceFS mantendo o mesmo workflow de uma árvore Git tradicional
  • A redução no uso de disco é uma grande vantagem para desenvolvedores de dispositivos que precisam alternar entre várias codebases
    • Mesmo ao alternar entre diferentes versões de dispositivos ou corrigir bugs em larga escala, é possível trabalhar com a leveza de um pequeno repositório no GitHub
  • A velocidade de build melhora em até 9 vezes, permitindo concluir rapidamente builds grandes até em máquinas comuns de desenvolvedor
    • O encurtamento do loop de feedback no pipeline de CI maximiza a produtividade de desenvolvimento
  • A redução de custos pode chegar a 14 vezes
    • Usar o SourceFS em máquinas comuns pode ser mais rápido e barato do que usar máquinas de alto desempenho
    • É possível realizar mais trabalho com o mesmo orçamento de computação

Comparação com alternativas existentes

  • O SourceFS supera as limitações das abordagens tradicionais
    • A migração para novos sistemas de build, como Bazel e Buck2, é pouco realista em projetos de grande escala, e a complexidade dobra em codebases de dispositivos que incluem múltiplos sistemas operacionais (ex.: Yocto, Android, QNX)
    • O SourceFS oferece os mesmos ganhos de desempenho sem exigir essa migração
  • Wrappers de compilador (REClient, Goma etc.) aceleram apenas parte das etapas do build e não ajudam no checkout
    • Como dependem da análise de flags de linha de comando, há possibilidade de erros inesperados

Planos futuros

2 comentários

 
ganadist 2025-10-25
 
GN⁺ 2025-10-24
Comentários do Hacker News
  • Parece que parte da equipe é formada por ex-Googlers, mas isso é diferente do srcfs baseado no Piper que conhecemos
    Há algumas semelhanças, mas quase não há detalhes, e é uma pena que a versão self-hosted também siga uma política de preço no estilo “Talk to us”

    • Queria que o Google ou a Meta abrissem como open source algum VFS mágico interno. O EdenFS da Meta é o mais próximo disso
    • Isso parece muito familiar. Era possível compilar apenas parte de um monorepo no commit deadbeef sem materializar a árvore inteira
      E, sobre o preço, se for uma equipe que lida com uma base de código de dezenas de bilhões de linhas, será que um preço “TalkToUs” não é algo que dá para bancar?
      Até software open source como o Linux roda bem no meu notebook
  • Isso me fez lembrar o antigo MVFS do ClearCase
    Durante a build, ele interceptava chamadas como open(2) e getenv(3) para registrar completamente quais ferramentas usaram quais versões de arquivos em qual ambiente
    Se as condições fossem as mesmas, ele reaproveitava o resultado existente com “winked-in”, e também permitia controle de versão no nível do sistema de arquivos
    Por exemplo, dava para acessar algo como file.c@@/trunk/branch/subbranch/3

  • Os números de tempo no título parecem um pouco exagerados
    Fiquei pensando se eles estão tentando transformar em produto algo como o EdenFS ou algum tipo de git fuse

    • Eles afirmam fazer cache das etapas de build de forma independente do sistema
      Dizem algo como “etapas de build idênticas às anteriores são automaticamente ignoradas e os resultados reutilizados”, mas parece bom demais para ser verdade
    • No fim, isso parece ser uma forma mais expandida de cache de saída de build
  • Parece apenas marketing de conteúdo comercial. Quase não há detalhes técnicos
    Para compartilhar algumas dicas que funcionaram quando eu trabalhava como engenheiro de build:
    compilar em tmpfs, usar symlink/hardlink em vez de copiar arquivos grandes, reduzir I/O desnecessário com libeatmydata,
    e escolher bem o compilador cruzado
    O que realmente importa é otimizar o sistema de build e fazer um bom cache dos artefatos intermediários que não mudam

    • Mas essas dicas básicas não resolvem o problema que esse produto afirma resolver
  • Olá, aqui é Serban, cofundador da Source.dev
    Obrigado pelos upvotes e pela discussão. Para uma startup em estágio inicial, esse tipo de feedback realmente ajuda muito
    Fico feliz em ver que o que estamos construindo parece ter valor de verdade

    • Pergunto por curiosidade: isso é parecido com a abordagem do fabricate em Python, que rastreia acesso a arquivos com strace?
  • Dei risada ao ver a frase “com o SourceFS, a build fica 9 vezes mais rápida”
    Quanto mais tempo a build demora, mais tempo sobra para praticar esgrima, então build lenta também tem suas vantagens

  • As alegações de desempenho deles estão muito à frente dos sistemas distribuídos de build de Android que eu já usei
    Fico curioso para saber qual é o ingrediente secreto

    • Será que no fim não é só um ccache um pouco mais sofisticado?
  • Quando a build fica “rápida o suficiente”, desaparece o incentivo de negócio para fazer o trabalho doloroso de entender a base de código
    Agora só resta o caminho para uma base de código com 1 bilhão de linhas

  • Pela explicação, isso parece específico para o código-fonte do Android. Fico me perguntando por quê e se também pode ser aplicado a outras bases de código

    • Pelo que entendo, isso só faz sentido quando todo o código não cabe na memória da maior máquina de build que a organização consegue operar
    • A própria página explica bem esse motivo