Recently I felt some poor performance on my Windows laptop workstation. WizTree reported that my largest file was:
C:\Users\dan\AppData\Local\Packages\
CanonicalGroupLimited.Ubuntu_...\LocalState\ext4.vhdx
148.6 GB
Nearly 150 GB.
The obvious conclusion was:
“I must have enormous projects.”
I was wrong.
Step 1: Finding the VHD
PowerShell quickly identified the culprit:
Get-ChildItem "$env:LOCALAPPDATA\Packages" -Recurse -Filter ext4.vhdx |
Select FullName,@{N='GB';E={[math]::Round($_.Length/1GB,1)}}
Output:
ext4.vhdx 148.6 GB
At this point I considered deleting WSL entirely. After all, most of my active development had moved to a remote Linux server.
That would have been a mistake.
Step 2: Is WSL Actually Using That Space?
Inside Ubuntu:
du -xh /home/$USER --max-depth=1 | sort -h
Surprisingly:
62G /home/dfish
My actual projects, caches, SDKs, and development tools only accounted for about 62 GB.
So where was the other 80+ GB?
Step 3: Look Beyond Home
Checking the entire filesystem:
sudo du -xh / --max-depth=1 | sort -h
revealed:
58G /var
62G /home
124G /
The real mystery was:
56G /var/lib
Digging deeper:
sudo du -xh /var/lib --max-depth=1 | sort -h
showed:
55G /var/lib/containerd
Aha.
Step 4: Docker Wasn’t the Problem
At first I assumed:
“I must have dozens of giant Docker images.”
But:
docker system df -v
showed something surprising:
Images: relatively small
Containers: nearly empty
Volumes: empty
Build cache: 45.8 GB
Almost 46 GB of build cache.
Many of the entries hadn’t been used in six months.
BuildKit Never Forgets
Every image build creates layers.
Repeated CI-style builds:
frontend-1608
frontend-1624
frontend-1650
frontend-1703
left behind enormous amounts of build cache.
The actual containers were tiny.
The images were reasonable.
The cache was enormous.
The Fix
The safest cleanup command:
docker builder prune
More aggressive:
docker builder prune -a
This removes unused build cache while preserving your current images and containers.
The Second Secret: VHD Files Don’t Shrink
Even after deleting data inside Linux, the VHD file on Windows often remains the same size.
The fix:
wsl --shutdown
Then:
diskpart
select vdisk file="C:\...\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit
This returns unused blocks back to Windows.
What Compacting Does
Compacting does NOT:
- delete files
- reorganize ext4
- affect Docker
- slow down WSL
- damage your Linux installation
It simply tells Windows:
“These blocks are empty now. You can have them back.”
The Takeaway
My original assumption:
WSL had become bloated.
Reality:
- 62 GB of actual development data.
- 46 GB of stale Docker build cache.
- A VHD file that had never been compacted.
The lesson isn’t that WSL is wasteful.
The lesson is that WSL behaves like a real Linux machine.
And real Linux machines collect old build artifacts, Docker layers, caches, and forgotten containers.
Before deleting your distribution, look inside it.
The problem may not be your projects at all.
Leave a Reply