Fixing a WSL2 Virtual Disk That Won't Shrink After Deleting Files

Deleting large files or directories from inside a WSL2 distro, then finding your Windows drive’s free space hasn’t increased at all, is expected dynamic-VHD behavior rather than a bug — the fix is a specific, direct compaction step.

Step 1: confirm the files are actually deleted inside the distro

df -h

Confirm the WSL-side filesystem itself shows the expected freed space from Linux’s own perspective — if it doesn’t, the deletion itself didn’t fully complete (check for a process still holding an open file handle to something you thought was deleted).

Step 2: locate the actual .vhdx file on the Windows side

Typically under:
%LocalAppData%\Packages\<DistroPackageName>\LocalState\ext4.vhdx

Each distro has its own separate .vhdx file — confirm you’re looking at the correct one for the specific distro where you freed up space.

Step 3: shut down WSL completely before attempting compaction

wsl --shutdown

The virtual disk file can’t be compacted while it’s actively mounted and in use by a running WSL2 VM — a full shutdown is a mandatory prerequisite, not an optional step.

Step 4: use diskpart to compact the virtual disk

diskpart
select vdisk file="C:\path\to\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

This is the actual, direct fix — diskpart’s compact vdisk command specifically shrinks a dynamically-expanding virtual disk file’s physical size down to match its actual current content, reclaiming the space that simple file deletion inside WSL didn’t return.

Step 5: verify the file size actually decreased

Check the .vhdx file's properties in File Explorer,
  or its size via PowerShell, before and after compaction

Confirming the actual file size decreased verifies the compaction genuinely worked, rather than just assuming it did based on the command completing without an error message.

Step 6: restart your distro normally afterward

wsl -d <DistroName>

Launching your distro again after compaction confirms everything still works correctly — compaction shouldn’t affect the filesystem’s actual content, only the underlying virtual disk file’s physical size on the Windows side.

Step 7: consider making this a periodic maintenance step, not a one-time fix

For workflows that regularly generate and later delete large amounts of temporary data inside WSL (large builds, container images, sizable datasets), periodically repeating this compaction process — rather than only doing it once when you notice a space problem — keeps the .vhdx file’s size closer to actual current usage on an ongoing basis.

Note that .wslconfig’s memory setting controls RAM usage specifically and has no effect on this disk-space behavior at all — don’t confuse the separate memory-ceiling fix with this disk-compaction fix; they address entirely different resources.

Why this manual step is necessary rather than automatic

Dynamically-expanding virtual disk formats are specifically designed to grow readily but require an explicit compaction step to reclaim freed space — this is standard, expected behavior for this class of virtual disk technology, and understanding it prevents the confusing experience of file deletion inside WSL appearing to have no effect on your actual Windows drive space at all.

Diagnose before compacting

This fix article is about identifying the failure mode. First compare three different numbers: free space reported by df inside Linux, the logical capacity of the ext4 filesystem, and the Windows file size of ext4.vhdx. Deleting a file can increase guest free space without immediately reducing the host file. If df did not change, find open-but-deleted files with lsof +L1, check snapshots, container layers, package caches, and the correct distribution. Compaction cannot reclaim blocks the guest still considers allocated.

Back up the distribution before an invasive repair. wsl --export is useful only after databases and services are quiesced; otherwise a syntactically valid archive may capture inconsistent application state. Record the distro name with wsl --list --verbose and locate its VHD through supported WSL information rather than editing arbitrary package directories.

Conditions for a successful shrink

The distribution must be stopped so Windows has exclusive access to the virtual disk. Free blocks inside the guest must be recognizable to the virtual-disk layer, and the backing file must not be held by Docker Desktop, an editor, an antivirus scan, or another WSL process. Keep substantial Windows free space available because maintenance can require temporary allocation.

If compaction completes but the size barely changes, that is evidence—not a reason to rerun it blindly. Data may be scattered, sparse support may differ by WSL version, or the virtual disk may contain allocated container images and snapshots. Re-check allocation and use the current Microsoft-documented disk-space workflow. Never unregister a distribution merely to make the VHD smaller unless a verified export and restore test already exist.

Primary references: Microsoft Learn: manage WSL disk space, Microsoft Learn: WSL basic commands, including export, DiskPart compact vdisk.

Related:

Sources: