Why Is My WSL Disk 150 GB? A Journey Through Docker, VHDX Files, and Hidden Disk Usage

by

this post has been formatted by AI

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.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *