Coding, Scripting, Administration

Disk Hog

Be sceptical about the size baobab shows for /nix. Check for old nixos profile symlinks that hold back packages.

I’ve had frequent trouble with low disk space recently. When it came to the point that I couldn’t run system updates because the disk would fill up completely, I had no choice but to take a closer look. I checked the obvious things like film collections hiding somewhere in the depth of the home dir, but the home dir didn’t seem to be the problem. My development containers were a lot bigger, but that was to be expected. There were extensive test databases for several development installations, a couple of large code repositories also containing design files, and similar stuff - all needed for my daily work. I cleaned up the Downloads, moved my music to an external disk, scraped a gigabyte or two together here and there, but it didn’t help much. Then I realized that I was missing the bulk of the data. I have a 450 GB partition, but baobab, the tool I was using for visualisation of the disk usage, showed me less than 200 GB. How could the disk be full then? What was using up almost 300 GB without being visualized? Dark matter?

I found that the command line utility du, which I thought baobab was using internally, showed me a different picture. The directory /nix, which holds the store for the nix package manager, was shown in baobab to have a few hundred MB, but du reported pretty much exactly the missing 300 GB. So I had found what was consuming the disk space, but why was it doing that? I knew that NixOS by default keeps old configurations of the system and hence old packages that had been installed in these old so-called “generations”. But you’re in full control - there are tools that allow you to list generations and delete obsolete ones. I had already checked that. Only one generation was listed, the current one. Digging a little deeper into the garbage collection system of nix, I found a few hundred symlinks in /nix/var/nix/profiles that had names like system-294-link, which sounded very much like old system configurations. From a very helpful article about garbage collection I learned that I could delete these links by hand to free up associated packages. And indeed, deleting a couple of the oldest links made the garbage collector free a whole bunch of disk space.

By deleting all but three of these symlinks I freed more than enough disk space. But there are still two open questions that I’d like to investigate at some point:

I suspect that both have to do with the internals of nix in some way. Maybe something for another blog post…

30th October 2019Filed under: NixOS   disk   baobab