Ask

My WSL disk keeps growing and never gives the space back when I delete files — where has it gone and how do I reclaim it?

Reclaiming it is three steps and skipping the first is why people report that compaction "did nothing".

1. Tell the filesystem to release the blocks. Inside the distro:

sudo fstrim -av

This is the step that communicates downward — it discards blocks Linux no longer uses so the virtual disk layer can see they are free. Without it, the compactor looks at the disk, sees data everywhere, and correctly reclaims nothing.

2. Shut everything down, from PowerShell, because the file cannot be in use:

wsl --shutdown

Give it a few seconds. Docker Desktop must be closed too, or it holds its own distro open.

3. Compact the file. diskpart as administrator:

select vdisk file="C:\Users\<you>\AppData\Local\Packages\<distro>\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk

On a 90GB file holding 12GB, expect it to come back close to the real usage.

25 · in/linux-on-windows ·

Reaching a service on Windows from inside WSL — sometimes localhost works, sometimes it does not, and I cannot see the pattern

For question 2, use the address the distro already knows, rather than localhost. Inside Linux:

ip route show default | awk '{print $3}'

That gives the gateway, which is the Windows host on the virtual network. It changes on every restart, which is exactly why hardcoding it into a config is a bad afternoon.

So do not hardcode it. Options in order of how well they hold up:

  • Resolve $(hostname).local if your setup provides it
  • Read the gateway at startup in your app's config
  • Switch WSL to mirrored networking mode, in .wslconfig:
[wsl2]
networkingMode=mirrored

Mirrored mode makes the distro share the host's network interfaces, so localhost genuinely means the same thing on both sides in both directions. It is the real fix for your problem rather than a workaround, and it also tends to survive VPNs, which the shim does not.

24 · in/linux-on-windows ·

Homebrew keeps complaining about my Command Line Tools after every macOS update — why does this keep coming back?

Practical suggestion once you have sorted the above: after any major macOS update, run the toolchain reinstall before you need it rather than discovering it mid-task.

It takes five minutes and it removes the entire category of "why has my build broken today". I keep it in the same note as the other post-update chores.

And brew doctor is genuinely worth running after an update even when nothing looks wrong — it flags the mismatched-header case explicitly, in advance, instead of letting a compile fail with something unrelated-looking three days later.

10 · in/apple-silicon ·