Duas arquiteturas, dois modelos de armazenamento
WSL1 não tem kernel Linux nenhum: ele traduz as chamadas de sistema do Linux para as do Windows em tempo real, e os arquivos ficam numa pasta comum — historicamente %LOCALAPPDATA%\Packages\<Distro>\LocalState\rootfs —, totalmente visível para as ferramentas do Windows. Isso o deixa leve no disco e rápido quando os scripts mexem em arquivos do /mnt/c, mas a tradução é incompleta: Docker, systemd e tudo que exige syscalls exóticas não funciona. WSL2 roda um kernel Linux de verdade numa VM utilitária leve, o que conserta a compatibilidade — mas o sistema de arquivos inteiro da distro passa a morar dentro de um ext4.vhdx, uma imagem de disco virtual que o Windows monta e não interpreta.
O vhdx fica em %LOCALAPPDATA%\Packages para as distros instaladas da Store e em %LOCALAPPDATA%\wsl para as instalações recentes, e tem uma propriedade traiçoeira: cresce sob demanda e nunca encolhe sozinho. Apagar arquivos dentro da distro libera espaço no disco virtual, mas o arquivo .vhdx conserva a marca da maré alta até você compactá-lo à mão. Conferir o tamanho do arquivo no Explorador logo depois de uma faxina grande dentro da distro é a decepção clássica: o número não se mexeu.
Onde cada um esconde os gigabytes
Nenhuma das duas versões recolhe a própria bagunça, e o espaço some em surpreendentemente poucos lugares:
- O ext4.vhdx do WSL2 — cada distro tem o seu; um ambiente carregado de Docker passa dos 30 GB sem piscar
- O disco de dados próprio do Docker Desktop (docker_data.vhdx), que segue a mesma regra de só crescer
- A pasta rootfs do WSL1 — modesta em comparação, mas distros velhas abandonadas seguram a instalação completa
- Caches de pacotes e builds dentro da distro — caches do apt, node_modules, pastas target/ e build/ que inflam o vhdx para sempre
- Backups de wsl --export e imagens de distro baixadas, esquecidas na pasta Downloads
Recuperar espaço sem quebrar a distro
Limpe primeiro por dentro: apt autoremove e apt clean, docker system prune no Docker Desktop, purga dos caches de npm e pip — tudo que esvazie o disco virtual antes de encolher o recipiente. Depois rode wsl --shutdown, porque uma distro em execução trava o vhdx dela, e compacte a imagem: Optimize-VHD com a opção -Mode Full se você tem o instrumental do Hyper-V, ou diskpart com select vdisk file="<caminho>", attach vdisk, compact vdisk, detach vdisk em qualquer Windows. As versões recentes do WSL oferecem wsl --manage <Distro> --set-sparse true, que deixa o vhdx liberar espaço automaticamente — no longo prazo, honestamente a melhor configuração.
Duas saídas finais merecem o nome. wsl --export empacota a distro num .tar que você importa em outra unidade com wsl --import: o caminho limpo para tirar uma instalação WSL2 de um C: lotado. E wsl --unregister <Distro> apaga a distro e o vhdx dela por completo — esse comando não tem desfazer, trate-o como a bomba que é. De quebra, ponhamos teto no apetite da VM com um arquivo .wslconfig limitando memória e processadores; uma WSL2 desocupada retém gigabytes de RAM à toa.
Perguntas e respostas
Como diminuo o arquivo ext4.vhdx do WSL2?
Limpe dentro da distro, rode wsl --shutdown e compacte o vhdx com diskpart (select vdisk file, attach vdisk, compact vdisk, detach vdisk) ou Optimize-VHD. No WSL recente, wsl --manage <Distro> --set-sparse true liga a liberação automática.
Devo usar WSL1 ou WSL2?
WSL2 é o padrão e a única opção para Docker, systemd e tudo que exige um kernel de verdade. WSL1 segue ganhando para trabalho leve de linha de comando que toca sobretudo arquivos nas unidades do Windows: sem VM, sem vhdx e sem fome de memória.
Veja exatamente o que está incluído antes de comprar.
O teste único de 30 minutos cobre os recursos básicos. Os recursos marcados PRO ficam bloqueados até a ativação de uma licença paga.
Continue lendo
Fale com a gente: [email protected]