Hi all - I’m relatively new to NixOS and taken the plunge. After some tweaks I’m finding my nix store is growing pretty large.
I deleted all my older generations with sudo nix-collect-garbage -d && nix-collect-garbage -d and then followed up with a nixos-rebuild switch to clear out the boot entries.
However if I run ncdu I see that my nix store still has several duplicates (see screenshot below).
Thank you - the optimise helped a bit. I think it cleared about 8Gb.
However looking at ncdu following I still see several duplicates e.g. qemu.
I ran the nix-store --query option on three of them and got the following below.
So if I read it right - there are several processes (top lines for each output) that seem to be referencing different versions of qemu in the store? I wonder why
current-system is different to booted-system, so that’s two system closures across an upgrade.
There’s also a home-manager closure; if that’s using a different nixpkgs revision than the system closure and you have qemu coming from both, that’s another possible source of additional versions.
The rest is a lot of running processes, probably started at boot before your last upgrade.
Thanks all - some helpful suggestions. I must admit I’m new so not 100% of what the output is telling me. But wind back a bit. The more I looked at ncdu output after a nix store optimise I realise it has done a lot of linking which, while there remain several copies of the same file (e.g. qemu-9.2.2 they all seem linked so each only only uses a few KB.
So if I ready right thats a win. The total size of my nix store seems to be about 40Gb, which may be normal?
However - I am still curious on some of the results. For reference, I cleaned up using garbage collection command, nix store optimise and then did a rebuild to clean up boot menu options. Then rebooted to ensure clean.
I ran some of the suggested commands:
❯ nix-store --gc --print-roots | grep result
/tmp/nh-osPkgJUR/result -> /nix/store/kjf349yggn1475w2v0v50rf0k6kn1s5f-nixos-system-john-laptop-25.05.20250412.2631b0b
Interestingly, there seems to be a reference to a version from 2025-04-12 hanging around. I’m guessing this should have been cleaned up by garbage collection, but for some reason isn’t.
I don’t know the impact of that hanging around but as I’m learning I’m curious why it remains and what I can do to further clean up.
For a desktop system with a bunch of larger gui things installed, perhaps a few generations kept around? Yeah, not unreasonable:
❯ zfs list -o space rpool/fmrl/nix
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
rpool/fmrl/nix 345G 47.1G 0B 47.1G 0B 0B
Note that in my case, there is underlying compression and deduplication that isn’t represented in this figure. The actual size of my store doesn’t vary that much with extra generations, even if the logical size does, because a lot of stuff is common even when a package gets a rev or dep bump and thus a new store path. The optimize you ran achieves the same basic result via hardlinking files.
So the first thing to get accustomed to is that keeping a few generations around is a good thing. The overhead is not (necessarily) large, and can be minimised, but it can be worthwhile regardless.
The other part of your question is why, even when you tried, you still had extra generations lying around:
The answer lies in the sequence of operations: garbage collection removes everything that’s not referenced from any of the current roots. You ran garbage collection, then rebooted. I suspect that you had booted from that 04-12 generation, and even after switching to the new generation, it was still referenced by the root at /run/booted-system. If you had rebooted first, or run gc again after, that generation will likely get cleaned up (with -d).
Note that this is desirable… although you have switched to the new generation and probably restarted most services, you haven’t yet booted it. Perhaps the kernel or some of the early startup configuration is bad? It would be unfortunate to gc your only known-bootable generation, in case you need to roll back to it, so it’s kept as a root (as well as there probably still being some elements in use or needed while running).
