WSL2 ate 80 GB of disk and deleting files doesn't get it back

C: was mysteriously full. WinDirStat pointed at a single file: an ext4.vhdx under AppData\Local\Packages\...\LocalState\ weighing 80 GB. Deleting gigabytes of Docker images and build artifacts inside Ubuntu changed the Linux-side df output — and did absolutely nothing to the file on the Windows side.

Root cause

WSL2 distros live inside a dynamically expanding virtual disk. It grows whenever Linux writes to new blocks, but freeing blocks inside the guest doesn’t return them to the host — the vhdx just keeps its high-water mark. Docker Desktop makes it worse because its images live in a second vhdx (docker-desktop-data) with the same behavior. Nothing is leaking; the space is simply stranded between the two filesystems until you compact the disk.

The fix

Order matters: free space inside Linux first, trim, shut down, then compact.

1. Free and trim inside the distro:

docker system prune -a   # if you use Docker in WSL
sudo apt clean
sudo fstrim -a

fstrim marks the freed blocks as unused so the compaction step can actually discard them.

2. Stop the VM completely:

wsl --shutdown

Give it ~10 seconds — compaction fails with a lock error if the VM is still winding down.

3. Compact the vhdx. On Windows Pro/Enterprise (elevated PowerShell, Hyper-V module):

Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\<distro>\LocalState\ext4.vhdx" -Mode Full

On Windows Home, Optimize-VHD doesn’t exist — use diskpart:

select vdisk file="C:\Users\me\AppData\Local\Packages\<distro>\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk

The 80 GB file came back at 19 GB. Repeat for Docker Desktop’s data vhdx if you have one.

Keeping it fixed

Recent WSL versions can maintain a sparse vhdx that returns freed space automatically:

wsl --manage Ubuntu --set-sparse true

Since enabling that, the disk has stayed honest without manual compaction. If your wsl --version predates the --manage flag, run wsl --update first.