460 GB, Only 14 Free: The Archaeology of a Developer's Disk

Every developer knows the creeping dread: you install a few dependencies, clone a repository, build a Docker image, and suddenly your disk is full. A recent post on Habr titled “460 ГБ, свободно 14: археология диска разработчика” (translated: “460 GB, 14 Free: The Archaeology of a Developer’s Disk”) struck a nerve with the developer community. It chronicles one engineer’s forensic dig into their own SSD, uncovering the hidden waste that accumulates over years of coding.

In this article, we’ll examine the typical suspects behind disk bloat on a developer machine, the tools used to hunt them down, and the strategies that can free up significant space without losing valuable data. The Habr article serves as our case study, but the lessons apply to any developer wrestling with a nearly full drive.

Source

The Usual Suspects: Where Does All the Space Go?

When a developer’s disk shows only 14 GB free out of 460 GB, the immediate reaction is to check a few classic culprits. According to the Habr author’s investigation, these are the most common space eaters:

• node_modules directories – A single project can contain hundreds of megabytes of dependencies; multiply by dozens of projects and you’re looking at tens of gigabytes.
• Docker images and containers – Unused images, stopped containers, and dangling layers can easily consume 20–50 GB.
• Build artifacts – Compiled binaries, .o files, and IDE-generated caches (e.g., .gradle, .m2, .nuget).
• Logs and temporary files – System logs, application logs, browser caches, and crash dumps that are never cleaned.
• Virtual environments – Python venv, Anaconda environments, or virtual machines that are no longer needed.
• Old project copies – Developers often keep entire git repositories with history, including large binary assets that were added and later removed.

The Habr article describes running a disk usage scanner and being shocked to find that a single folder of archived projects occupied more than 100 GB. Many of those projects hadn’t been touched in over a year.

Tools of the Trade: Digging into the Disk

To perform a proper disk archaeology, you need the right instruments. The developer in the Habr post used a combination of command-line and GUI tools. Here are the most effective ones for different platforms:

The article highlights that running du -sh * in the home directory was the first step, but ncdu provided an interactive way to navigate deep folder structures. On Windows, WinDirStat’s color-coded blocks immediately revealed that a single folder node_modules in an old project was 3 GB.

Case Study: What the Habr Author Found

Let’s walk through the actual findings reported in the Habr post. The developer started by scanning the root of their drive (C: or /). Here’s a summary of the top space consumers they identified:

1. AppData/Local (Windows) or ~/Library (macOS): Over 60 GB. This included NuGet package cache (12 GB), npm cache (8 GB), and Docker overlay2 storage (25 GB).
2. Projects folder: 150 GB, with 40% of that being old repositories that could be archived to external storage.
3. Docker: 50 GB of unused images, most of which were tagged as <none> and could be pruned.
4. Virtual machines: 30 GB from a vanished Hyper-V image whose files were still on disk.
5. Downloads folder: 20 GB, including installer files and ZIPs that had been extracted long ago.

After clearing these, the developer recovered over 80 GB, bringing free space from 14 GB to 94 GB. The article notes that a significant portion of the waste came from tools that cache data aggressively but never clean up after themselves.

Automating the Cleanup: Scripts and Aliases

One key takeaway from the Habr article is that manual cleanups are unsustainable. The author recommends setting up periodic cleanup routines. For example:

• Docker: docker system prune -a --volumes – but be careful: this removes all unused containers, networks, images, and volumes.
• npm: npm cache clean --force and npx rimraf node_modules for old projects.
• System caches: On Windows, cleanmgr with the /sageset flag; on macOS, brew cleanup and rm -rf ~/Library/Caches/*.
• Git garbage collection: git gc --prune=now for large repositories.

The article also suggests using ncdu on a schedule (e.g., monthly cron job) to generate a report. This proactive approach prevents the disk from silently filling up.

Practical Tips for Preventing Disk Bloat

Based on the archaeology lesson from the Habr post, here are actionable steps every developer can implement:

• Use a monorepo with a single node_modules if possible, or share dependencies via workspaces.
• Limit Docker image hoarding: Set up a docker system prune job in your CI/CD pipeline.
• Store large caches on external drives: Move npm, pip, and NuGet cache locations to a separate partition or disk.
• Keep a “Project Graveyard” folder on an external hard drive: Move old repositories there after a year of inactivity.
• Utilize cloud storage for archives: Instead of keeping all source code locally, store old projects in an S3 bucket or similar.
• Monitor regularly: Use tools like ncdu or WinDirStat every quarter. The Habr author admits they hadn’t checked for three years.

Summary: The Cost of Neglect

The Habr article “460 ГБ, свободно 14” is a cautionary tale for developers who assume their disk will manage itself. By methodically analyzing every gigabyte, the author reclaimed enough space to postpone buying a new drive. More importantly, they documented a workflow that anyone can replicate.

The key metrics speak for themselves: after the archaeological dig, free space went from 3% to 20% of the total disk. That’s the difference between a system that constantly throttles and one that runs smoothly.

In conclusion, disk archaeology is not just about reclaiming space—it’s about understanding your development habits. The tools, patterns, and cleanup scripts described in the Habr post (and expanded here) can turn a storage crisis into a routine maintenance task. Next time you see a warning like “14 GB free”, grab a scanner and start digging. What you find may surprise you.

This article summarizes insights from the original Habr publication. For the full detective story, visit the source link above.