Why Freed Space Stays Occupied in WSL, Docker, and Virtual Machines

table of contents

Part 1: Understanding Why WSL Disk Space Doesn’t Shrink Immediately

Have you ever deleted big files in WSL—such as Docker images, container caches, or large machine learning models—and noticed no change in disk usage on the Windows side? It’s a common puzzle: where does that deleted space actually go?

In this article, we’ll explore why freed space isn’t immediately reflected in Windows, explain how WSL 1 and WSL 2 handle storage differently, and introduce practical steps to reclaim disk space on your host machine.

Why Deleting Files in WSL Doesn’t Always Reduce Windows Disk Usage

Windows Subsystem for Linux (WSL) runs a Linux environment on top of the Windows filesystem. Depending on your version of WSL:

  • WSL 1 integrates Linux calls into the Windows NT kernel, meaning it works more like a compatibility layer.
  • WSL 2 uses an actual Linux kernel inside a virtual machine (VM), storing data in a special virtual hard disk file (VHD or VHDX).

The key point? Deleting files inside WSL doesn’t always translate into immediate space savings on the Windows side. That’s because the underlying virtual disk (in WSL 2) or filesystem integration (in WSL 1) might not release space back to the host OS right away.

WSL 2 in Focus

In WSL 2, your Linux environment runs in a lightweight VM, and files reside within a VHD(X) file. Even if you remove massive directories—like Docker images or large AI model repositories—Windows still sees the VHD file at the same size. Why? Because the virtual hard disk file doesn’t automatically shrink when data is deleted.

Analogy: Think of the VHD as a balloon that can inflate when new data is added. When you delete files, you’re letting air out inside the balloon, but the balloon itself remains the same size unless you actively compress or “deflate” it.

To truly reduce that file size, you typically need to optimize or compact the VHD. This process can be done via commands like Optimize-VHD in Windows (if Hyper-V is enabled) or by using diskpart with compact vdisk.

WSL 1 at a Glance

Although WSL 1 is more tightly integrated with the Windows filesystem, there can still be delays before Windows reports any disk space savings. When you remove files on the Linux side, the space is freed logically inside WSL, but Windows doesn’t always reclaim it immediately. Sometimes, restarting the WSL service or running cleanup commands triggers Windows to refresh its disk usage calculations.

Quick Comparison of WSL 1 and WSL 2

AspectWSL 1WSL 2
ArchitectureUses a Windows compatibility layer for Linux callsRuns a true Linux kernel in a lightweight VM
Storage LocationFiles live on the Windows filesystem (no separate VHD by default)Stored in a virtual hard disk (.vhdx) located in the user’s AppData folder
Deleting FilesMay not immediately reflect disk space changes in WindowsDisk size remains the same unless you compact the VHD manually
Performance NotesFaster file operations on NTFS-bound filesBetter compatibility with Linux kernel features
How to Free SpaceRestart WSL, run cleanup tools, sometimes just waitUse Optimize-VHD or diskpart to compact the VHD after internal cleanup

Note: If you’re on WSL 2 and you delete files but Windows disk usage still doesn’t go down, you probably need to compress the VHD. For WSL 1, sometimes a simple restart or system cleanup is enough.

Bonus Tip: Keep an Eye on Docker

Docker on WSL 2 often stores images, layers, and caches in your Linux filesystem. This can quietly balloon the size of your VHD, especially if you pull large images or experiment with big data sets. Regularly running docker system prune and cleaning out old images can help, but compacting the VHD is what ultimately shrinks its footprint on Windows.

Part 2: How to Compact Your WSL VHD

Even if you remove Docker images and large files inside WSL, the .vhdx file on your Windows host can remain the same size—unless you explicitly compress it. Below, we’ll look at two primary methods to achieve this:

  1. Using Optimize-VHD (requires Hyper-V)
  2. Using diskpart (works on Windows Home as well)

When Optimize-VHD Isn’t Recognized

Sometimes, running Optimize-VHD in PowerShell returns an error like:

Optimize-VHD: The term ‘Optimize-VHD’ is not recognized as a name of a cmdlet, function, script file, or executable program.

This typically means Hyper-V (or its PowerShell module) is either not installed or not properly loaded. Since Optimize-VHD is part of the Hyper-V command set, you must have:

  • Windows 10/11 Pro, Education, or Enterprise (Hyper-V is officially unavailable on Home)
  • Hyper-V enabled in “Windows Features”
  • Hyper-V PowerShell module installed

Note: If you’re on Windows Home, you can’t officially use Hyper-V. However, you can still shrink .vhdx files using diskpart—we’ll show that soon.

Enabling Hyper-V and PowerShell Modules

If you have a compatible Windows edition but still face “command not recognized” errors, try these steps:

  1. Enable Hyper-V
    1. Open Control PanelProgramsTurn Windows features on or off.
    2. Check Hyper-V.
    3. Reboot if prompted.
  2. Install Hyper-V PowerShell Module
    Open an elevated PowerShell (Run as Administrator) and type:
    Install-WindowsFeature -Name Hyper-V-PowerShell
    After installing, restart your PowerShell session.
  3. Run Optimize-VHD
    • Shut down WSL first:
      wsl --shutdown
    • Then open PowerShell as admin and run:
      Optimize-VHD -Path "C:\path\to\your\ext4.vhdx" -Mode Full

Pro Tip: Hyper-V can conflict with other virtual machine software (like VirtualBox or VMware) if you plan to run them at the same time. Make sure to review documentation for any known compatibility issues.

Using diskpart (Ideal for Windows Home)

If you’re on Windows Home or simply don’t want to enable Hyper-V, you can still shrink .vhdx files via the built-in diskpart command. This tool is particularly handy for WSL 2 virtual disks.

Below is a quick comparison of the two methods:

MethodRequirementsCommand ExampleProsCons
Optimize-VHD– Hyper-V enabled
– Pro/Edu/Enterprise
Optimize-VHD -Path "C:\path\ext4.vhdx"– Simple
– Designed for VHDs
– Requires Hyper-V
– Not on Home Edition
diskpart– Works on any edition of Windowsdiskpart
select vdisk file="..."
compact vdisk
– No Hyper-V needed
– Universal built-in tool
– CLI can be more manual
– Fewer advanced flags

Step-by-Step: Shrinking a WSL VHD with diskpart

  1. Shutdown WSL
    Before any disk operations, ensure WSL isn’t running.
    wsl --shutdown
  2. Open diskpart
    Open PowerShell or Command Prompt as Administrator and type:
    diskpart
  3. Select the VHD File
    Inside diskpart, specify the path to your .vhdx file:
    DISKPART> select vdisk file="C:\path\to\your\ext4.vhdx"
  4. Compact the VHD
    Run the compact command:
    DISKPART> compact vdisk
    When complete, you should see a success message indicating the disk was compressed.
Heads Up: Make sure you know the exact path to your .vhdx file. For a typical Ubuntu WSL installation, the VHD often lives in:

C:\Users\<YourName>\AppData\Local\Packages\CanonicalGroupLimited...

The exact folder name varies depending on the distro and WSL version.

A Quick Note on Guest OS Shutdown

Don’t forget to shut down your WSL or other guest OS. If processes are still running, compaction tools might fail or report an error. Use:

sudo shutdown now

inside the WSL environment, or simply run:

wsl --shutdown

from Windows. This ensures all Linux sessions are fully terminated before you compact the disk.

Part 3: Compacting VirtualBox Disks and Using Zero-Fill

If you’re using VirtualBox instead of WSL or Hyper-V, you might notice the same phenomenon: deleting files inside the guest OS doesn’t automatically shrink the .vdi file on the host. Here’s why and how to fix it.

Why VirtualBox Disks Don’t Automatically Shrink

VirtualBox often uses dynamically allocated .vdi files. These grow over time as the guest OS stores more data. However, when you delete files within the VM, the .vdi file stays the same size from the host’s perspective. Just like WSL, you need to compress or “compact” the file to truly reclaim that space.

Tip: If you routinely add and remove large amounts of data—like big databases or machine learning datasets—it’s a good idea to zero-fill your disk periodically and run the compaction step. This keeps your VM images lean and more manageable.

3 Steps to Compact a .vdi in VirtualBox

  1. Shut Down Your Guest OS
    • You can’t safely compress a disk while it’s actively running. Make sure the VM is powered off before proceeding.
  2. Zero-Fill the Guest OS
    • Inside a Linux guest, fill unused space with zeros:
      sudo dd if=/dev/zero of=/zero.fill bs=1M
      sync
      sudo rm -f /zero.fill
    • On Windows guests, you can use a tool like SDelete to zero out free space.
  3. Run the VBoxManage Compact Command
    • On your host machine (with the VM turned off), open a terminal or command prompt, navigate to the folder where VBoxManage.exe lives (usually C:\Program Files\Oracle\VirtualBox), then run:
      VBoxManage modifymedium --compact "C:\path\to\your\disk.vdi"
    • If you see an error about “UUID already exists,” it often means VirtualBox still has that disk file registered in another path. Make sure the .vdi is properly detached or that you’ve moved both the .vdi and corresponding .vbox files together.

Quick Comparison: VirtualBox vs. WSL Disk Compaction

PlatformFile ExtensionCompaction MethodNotable ToolsExtra Steps
VirtualBox.vdi– Zero-fill guest OS
VBoxManage modifymedium
VBoxManage, SDelete (Windows)Move .vdi and .vbox together if changing directories
WSL (V2).vhdx– Zero-fill guest OS
Optimize-VHD or diskpart
PowerShell / diskpartUse wsl --shutdown first; path often in AppData

Why Zero-Filling Works

When you delete files in your guest OS, that “deleted” space isn’t always represented as empty in the disk image; it’s just marked unused. By writing zeros to every unallocated block:

  • Compression tools can recognize and remove those zeroed-out chunks.
  • The physical file size of the .vdi (or .vhdx) can then shrink effectively.

Real-World Example: From 300GB Down to 5GB

It may sound too good to be true, but after zero-filling a heavily used VM and running VirtualBox’s compact process, you can see jaw-dropping results—like 300GB images shrinking to just 5GB! This happens when large portions of the disk were previously occupied by files that have since been deleted, leaving plenty of compressible zero-filled space.

In Practice:

  • Use zero-fill commands (dd on Linux, SDelete on Windows).
  • Fully shut down the VM.
  • Run your preferred compaction tool.
  • Watch your disk usage drop dramatically on the host.

Part 4: Final Takeaways and Best Practices

Now that you’ve learned how to shrink virtual disks in WSL, VirtualBox, and beyond, let’s wrap up with a quick rundown of common pitfalls, best practices, and additional notes to ensure you’re reclaiming as much space as possible.

Common Misconceptions

  1. “Deleting files frees space instantly.”
    • Reality: In virtualized environments, the guest OS sees the space as free, but the host’s disk image remains the same size until you manually compact it.
  2. “WSL on Windows is always heavy.”
    • Reality: Many users choose WSL on Windows for convenience or tool compatibility. While a pure Linux environment can be leaner, WSL 2 offers near-native performance for many workloads.
  3. “Zero-filling is optional.”
    • Reality: Zero-filling is key if you want your compression tool to recognize which blocks can be freed. Without it, you might see minimal disk savings.
  4. “All Windows editions support Hyper-V.”
    • Reality: Windows Home typically doesn’t include Hyper-V, but you can still shrink .vhdx files using diskpart. Know your edition’s limitations before attempting Optimize-VHD.

Best Practices for Efficient Disk Management

ActionWhy It HelpsExample
Regular Clean-UpsPrevents bloat from old Docker images, logs, or cachesdocker system prune -a, apt-get clean, rm -rf ...
Zero-Fill Before CompactionMaximizes the impact of compression toolssudo dd if=/dev/zero of=/zero.fill...
Shut Down the VM/WSLEnsures all data is flushed and the disk is not in usewsl --shutdown, power off the VirtualBox machine, etc.
Back Up FirstDisk operations can be risky—backing up prevents accidental data lossCopy .vhdx/.vdi to a safe location or use a cloud backup
Check Your Disk FormatDifferent virtualization tools (VMware, VirtualBox, WSL) have unique formats.vhdx, .vdi, .vmdk—all require different commands

Tip: If you’re installing multiple Linux distros or Docker containers on Windows, consider creating separate VHD files for each to keep things organized. That way, compacting or backing up one environment won’t affect the others.

A Quick Word on VMware

Although most of this article focuses on WSL and VirtualBox, VMware also uses a similar approach with dynamically allocated .vmdk files. The same principle applies:

  1. Shut down the guest OS.
  2. Zero-fill free space.
  3. Use VMware’s built-in vmware-vdiskmanager tool (on the host) to shrink the disk.

It’s a universal concept: if you’re using a virtual machine or container platform with dynamic disk allocation, unlinked or deleted data doesn’t automatically reduce the file size.

In Closing

With these techniques in your toolkit—whether you’re using WSL, VirtualBox, or another VM solution—you can take control of your disk space:

  • Delete large, unnecessary files regularly.
  • Zero-fill to ensure maximum compaction.
  • Run the proper shrink/optimize command for your platform.
  • Enjoy a cleaner, faster host system with more free space for other projects!

Final Thought:
Don’t shy away from using Linux on Windows through WSL just because you think it’s heavy. As we’ve seen, it can be quite efficient once you know how to manage disk usage—and it offers the best of both worlds: Windows familiarity with Linux power.

If you like this article, please
Follow !

Please share if you like it!
table of contents