Related to #4699.
That issue already covers the disk reclaim problem itself, so this is not meant as a duplicate feature request. The goal here is to propose a more concrete implementation path that seems safer and easier to reason about in practice.
Summary
Introduce an optional VHDX compaction step triggered after WSL shutdown, instead of trying to compact dynamically while WSL is still running.
Motivation
Right now, freeing space inside WSL does not automatically free space on the Windows side. Even after large amounts of data are deleted inside the distro, the host-side .vhdx can remain heavily inflated until the user manually compacts it.
In practice, reclaiming that space usually ends up looking like this:
- delete data inside WSL
- run
wsl --shutdown
- compact the VHDX manually from Windows using
optimize-vhd, diskpart, or another host-side workflow
That works, but it is not a great experience. It is easy to forget, depends on which Windows tools are available, and usually only gets done once the user is already running low on disk space.
I ran into this after generating a very large amount of logs inside WSL. After cleaning everything up, the distro looked fine from inside Linux, but the .vhdx on the Windows side was still huge and had to be compacted manually.
Proposal
Instead of introducing live or dynamic compaction while WSL is still active, a more conservative approach could be:
Support optional compaction after WSL is fully stopped.
High-level behavior
Why this approach
Trying to compact while WSL is still running seems much more complex and much more likely to create edge cases.
Triggering compaction after shutdown has some clear advantages:
- no active filesystem activity inside the distro
- no running workload competing with the compaction step
- lower risk around open handles or in-flight writes
- it matches the manual workflow many users already rely on today
So this would not introduce a completely new maintenance pattern. It would mainly automate the one that users already perform manually.
Example configuration
Just as an illustration, this could potentially be exposed through .wslconfig or a similar mechanism:
[wsl2]
autoCompact=true
autoCompactThresholdGB=2
autoCompactCooldownHours=24
Non-goals
This proposal is intentionally conservative. It does not aim to:
- compact while WSL is running
- compact on every shutdown unconditionally
- replace or conflict with other existing disk-management behavior
Implementation considerations
Some areas that seem relevant:
- a trigger point after VM teardown in
wslservice
- estimating reclaimable space before deciding whether to compact
- safe use of the existing host-side VHD compaction path
- logging when compaction:
- runs
- is skipped due to threshold
- is skipped due to cooldown
- interaction with Docker Desktop and other WSL-integrated workloads
Open questions
- what is the safest and most reliable way to estimate reclaimable space?
- should this be global or per-distro?
- should compaction run synchronously during shutdown or as a deferred background task after shutdown?
Closing thought
Overall, this feels like a practical middle ground: it avoids the complexity of live compaction while still solving a real usability issue by automating a shutdown-based reclaim workflow that already exists.
Related to #4699.
That issue already covers the disk reclaim problem itself, so this is not meant as a duplicate feature request. The goal here is to propose a more concrete implementation path that seems safer and easier to reason about in practice.
Summary
Introduce an optional VHDX compaction step triggered after WSL shutdown, instead of trying to compact dynamically while WSL is still running.
Motivation
Right now, freeing space inside WSL does not automatically free space on the Windows side. Even after large amounts of data are deleted inside the distro, the host-side
.vhdxcan remain heavily inflated until the user manually compacts it.In practice, reclaiming that space usually ends up looking like this:
wsl --shutdownoptimize-vhd,diskpart, or another host-side workflowThat works, but it is not a great experience. It is easy to forget, depends on which Windows tools are available, and usually only gets done once the user is already running low on disk space.
I ran into this after generating a very large amount of logs inside WSL. After cleaning everything up, the distro looked fine from inside Linux, but the
.vhdxon the Windows side was still huge and had to be compacted manually.Proposal
Instead of introducing live or dynamic compaction while WSL is still active, a more conservative approach could be:
High-level behavior
only evaluate compaction when:
wsl --shutdownis called, oronly run compaction if:
feature is:
Why this approach
Trying to compact while WSL is still running seems much more complex and much more likely to create edge cases.
Triggering compaction after shutdown has some clear advantages:
So this would not introduce a completely new maintenance pattern. It would mainly automate the one that users already perform manually.
Example configuration
Just as an illustration, this could potentially be exposed through
.wslconfigor a similar mechanism:Non-goals
This proposal is intentionally conservative. It does not aim to:
Implementation considerations
Some areas that seem relevant:
wslserviceOpen questions
Closing thought
Overall, this feels like a practical middle ground: it avoids the complexity of live compaction while still solving a real usability issue by automating a shutdown-based reclaim workflow that already exists.