Compare commits

..
3 Commits
Author SHA1 Message Date
Stevan 6f9e1bb731 Merge pull request 'posts: reclaiming my disk space post' (#1) from stevanfreeborn/posts/reclaiming-my-fucking-disk-space into main
Deploy / Build and push Docker image (push) Failing after 3m28s
Deploy / Deploy to server (push) Skipped
2026-08-24 16:15:35 +00:00
Stevan Freeborn 92b13c0217 fix: upgrade deps
Pull Request / Run tests (pull_request) Successful in 5m53s
2026-08-24 11:03:08 -05:00
Stevan Freeborn d5b31510eb chore: finish draft
Pull Request / Run tests (pull_request) Successful in 4m39s
2026-08-24 10:51:46 -05:00
4 changed files with 97 additions and 12 deletions
+3 -3
View File
@@ -8,9 +8,9 @@
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Markdig" Version="0.43.0" />
<PackageReference Include="System.ServiceModel.Syndication" Version="10.0.0" />
<PackageReference Include="TestableIO.System.IO.Abstractions.Wrappers" Version="22.0.16" />
<PackageReference Include="Markdig" Version="1.3.2" />
<PackageReference Include="System.ServiceModel.Syndication" Version="10.0.11" />
<PackageReference Include="TestableIO.System.IO.Abstractions.Wrappers" Version="22.2.0" />
</ItemGroup>
<ItemGroup>
@@ -0,0 +1,79 @@
```json meta
{
"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:
```powershell
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`](https://github.com/Byron/dua-cli) for rapid terminal-based disk analysis:
```powershell
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.
Binary file not shown.

After

Width:  |  Height:  |  Size: 618 KiB

+15 -9
View File
@@ -10,20 +10,26 @@
</PropertyGroup>
<ItemGroup>
<PackageReference Include="bunit" Version="2.1.1" />
<PackageReference Include="coverlet.msbuild" Version="6.0.4">
<PackageReference Include="bunit" Version="2.9.0" />
<PackageReference Include="coverlet.msbuild" Version="10.0.1">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
<PackageReference Include="FluentAssertions" Version="7.2.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="10.0.0" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="18.0.1" />
<PackageReference Include="Microsoft.Playwright.NUnit" Version="1.56.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="10.0.11" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="18.9.0" />
<PackageReference Include="Microsoft.Playwright.NUnit" Version="1.62.0" />
<PackageReference Include="moq" Version="4.20.72" />
<PackageReference Include="NUnit" Version="4.4.0" />
<PackageReference Include="NUnit3TestAdapter" Version="5.2.0" />
<PackageReference Include="NUnit.Analyzers" Version="4.11.2" />
<PackageReference Include="coverlet.collector" Version="6.0.4" />
<PackageReference Include="NUnit" Version="4.6.1" />
<PackageReference Include="NUnit3TestAdapter" Version="6.2.0" />
<PackageReference Include="NUnit.Analyzers" Version="4.14.0">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
<PackageReference Include="coverlet.collector" Version="10.0.1">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
<PropertyGroup>