blog.stevanfreeborn.com/src/Blog/wwwroot/posts/how-i-reclaimed-my-disk-space/index.md

{
  "title": "How I Reclaimed My Disk Space",
  "lead": "I hate it when my computer is slow and I spend more time waiting for something to complete than getting things done. I recently had one of those experiences and wanted to share what I found was causing it and how I resolve the issue.",
  "isPublished": true,
  "publishedAt": "2026-08-24",
  "openGraphImage": "posts/how-i-reclaimed-my-disk-space/og-image.png",
}

This past weekend, my laptop started driving me crazy. Every few minutes, disk usage spiked to 100% and stayed there. Apps took forever to launch, keystrokes lagged, and I spent more time waiting on the system than getting work done. I initially let the machine sit idle for a few hours, assuming Windows Update or a periodic background task just needed to catch up. When that changed nothing, it was time to dig in and troubleshoot.

Good Old Task Manager

I started by checking my local storage and found roughly 60 GB free. While that was not an immediate out-of-space crisis, it was far less room than I expected. Opening Task Manager to see what was thrashing the system revealed iCloud reporting 473% CPU usage.

I set up iCloud on this machine ages ago to pull reference photos directly from my phone without extra friction, and it had never caused issues before. As it turned out, I should have been watching it much more closely.

iCloud Was Doing a Lot

When I scanned my user directory to track down heavy folders, one entry jumped out immediately: iCloudPhotos was reporting 938 GB on a 475 GB SSD.

After a bit of spelunking, I discovered this is a known quirk with iCloud on Windows. The client reports a size larger than the physical drive because it tallies cloud-referenced placeholders alongside local files. Still, the background sync daemon constantly churning through over 30,000 photos was hammering the disk.

I opted for the cleanest solution and uninstalled iCloud completely, deleting the residual caches lingering inside AppData and ProgramData. The relief was immediate. Low drive space had likely thrown the sync engine into an endless, resource-heavy loop.

Rust Bit Me

With iCloud removed and disk pressure subsiding, I wanted to understand why my storage had dwindled so much in the first place. Resolving the root cause meant tracking down what else was eating space.

Scanning my Repositories directory revealed it was sitting at 52 GB. Almost all of that came from a single Rust application I was building with Tauri. That repository alone held 51 GB across two separate target/ directories.

For anyone new to Rust, the target/ folder is where Cargo stores compiled artifacts and intermediate build caches. It balloons rapidly and never prunes itself automatically. I simply hadn't thought to keep an eye on those build outputs. Deleting both directories instantly freed up 47 GB.

Docker Virtual Disks

Even with the repository trimmed, my manual directory scans only accounted for about 174 GB of the 413 GB in use. The missing space was hiding in system folders. When I inspected virtual disk files, the culprit surfaced:

docker_data.vhdx — 75 GB.

Docker Desktop on Windows manages containers, images, and volumes within a single dynamically expanding .vhdx file. The catch: deleting Docker assets does not automatically shrink the virtual disk. It holds onto whatever maximum allocation it reached.

Even after running a full prune on unused containers and images (Playwright, MongoDB, Seq, MailHog, and old dev builds), the physical VHDX file on disk remained 73 GB. Reclaiming that space required shutting down Docker, stopping all WSL instances, and marking the virtual disk as sparse:

wsl --manage docker-desktop --set-sparse true --allow-unsafe

That dropped the file size from 73 GB down to 11 GB, pushing my total free storage from 110 GB to 208 GB.

Additional Quick Wins

Tracking down lost disk space easily turns into an optimization rabbit hole. While in cleanup mode, I tackled a few extra areas:

• Cleared Temp Directories: Emptied both AppData\Local\Temp and C:\Windows\Temp, freeing 16.5 GB. Locked files from running apps safely skipped, while stale logs and installers were wiped.
• Disabled Hibernation: Ran powercfg /hibernate off. I do not use hibernation or Fast Startup, yet hiberfil.sys was consuming 6.25 GB to mirror RAM state.
• Configured Windows Defender Exclusions: Added folder exclusions for Repositories and process exclusions for developer tooling like git.exe, cargo.exe, and node.exe. This prevents real-time scanning from checking every intermediate build file and node_modules write.

Automating the Routine

Most of this bloat stemmed from passive neglect. Build artifacts lingered because I did not wipe them, the Docker virtual disk expanded unchecked, and system temp folders simply accumulated data over months.

To keep storage clean moving forward, I configured recurring scheduled tasks to run on the first of every month:

• Pruning Rust build artifacts via cargo-sweep
• Pruning Docker images, containers, and build cache
• Clearing local NuGet and npm package caches
• Wiping Windows and user temporary folders

I also added dua for rapid terminal-based disk analysis:

winget install Byron.dua-cli
dua i <path-to-analyze>

The Final Count

I started the evening at 60 GB free and finished at 242 GB, with disk usage spikes gone entirely. Developer workstations accumulate invisible weight quickly through build caches, virtual drives, and background sync clients. Left unchecked, they quietly consume disk space until performance grinds to a halt.