Olá! Muito obrigado pelo feedback. Excelente pergunta!

De fato, os custos de RAM e CPU em arquivos gigantes sempre são o pesadelo dos sistemas de arquivos virtuais. Seria um problema grave se fôssemos carregar o dump ou reorganizá-lo por completo em runtime. Mas a boa notícia é que nós já saímos muito do escopo da arquitetura v2, onde os testes iniciais foram feitos.

Na nossa melhoria arquitetônica atual, o motor VFS não entra em colapso porque ele jamais tenta mastigar os 100GB de uma vez. O Random Reader do backend opera utilizando um Cache LRU (Least Recently Used) de Blocos.

Sobre o impacto na RAM: O arquivo .crom por baixo dos panos é dividido em blocos fechados (geralmente de 16MB) com offsets pré-calculados in-band. Quando o sistema operacional começa a leitura progressiva do dump de 100GB, o Crompressor extrai e aplica o Delta Patching progressivamente. O pulo do gato é que a capacidade do Cache LRU possui um hardcap de apenas 4 blocos. Ou seja, não importa se você está lendo um arquivo de 10GB, 100GB ou 10TB de uma vez — o consumo de RAM ficará matematicamente travado e reciclando em torno de ~64MB. Conforme o ponteiro de leitura avança, os blocos mais velhos são sumariamente evictados da memória.

Sobre o impacto no Processamento (Throughput): Para evitar que a CPU enlouqueça e fique abrindo a mesma fechadura mil vezes para entregar bytes picados, a nossa leitura (loadBlockPool) roda atrelada a travamentos assíncronos (Mutex/Locking). Se múltiplas requisições baterem no mesmo bloco de 16MB simultaneamente para fatiar bytes na leitura, a extração criptográfica rodará estritamente uma vez, amortizando a descompressão. O custo de processamento cresce muito levemente em relação ao stream do leitor primário do SO e continua bastante contínuo.

Caso queira ver como tudo foi estruturado, dá uma olhada na arquitetura do VFS lá no repositório:

• Toda a lógica mecânica do Random Reader lidando com chunks e o Lock de processamento está no arquivo: internal/vfs/reader.go (foco no método loadBlockPool).
• O sistema de reciclagem pesada da RAM O(1) pode ser visto no arquivo: internal/vfs/cache.go
• Fique tranquilo que o teto de OOM (Out Of Memory) foi arquitetado cirurgicamente pro VFS aguentar stress pesado. Mais uma vez, obrigado pelo apoio e pelo interesse prático no projeto!