Storage optimization: Difference between revisions

imported>Mth
No edit summary
imported>Mth
No edit summary
Line 59: Line 59:
As you see, the reference in <code>/run/booted-system</code> is a GC root, so it won't be cleared until reboot. If you don't want to reboot, just <code>rm /run/booted-system</code> that link and rerun <code>sudo nix-collect-garbage</code>.
As you see, the reference in <code>/run/booted-system</code> is a GC root, so it won't be cleared until reboot. If you don't want to reboot, just <code>rm /run/booted-system</code> that link and rerun <code>sudo nix-collect-garbage</code>.


=== Proper <code>nix-shell</code> GC pinning ===
=== Pinning ===


When you invoke <code>nix-shell</code> with
When you invoke <code>nix-shell</code> with
Line 70: Line 70:
Obviously, you should remove the GC roots directory for projects you don't plan to work on.
Obviously, you should remove the GC roots directory for projects you don't plan to work on.


=== Automatic garbage collection ===
=== Automation ===


Next you may enable periodic auto GC, for example like this:
It is possible to enable periodic automatic GC,<ref group="cf.">{{nixos:option|nix.gc}}</ref> for example like this:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="nix">
nix.gc.automatic = true;
nix.gc = {
nix.gc.dates = "weekly";
  automatic = true;
nix.gc.options = "--delete-older-than 30d";</syntaxhighlight>
  dates = "weekly";
This can result into some redownloads (if you ever use <code>import (builtins.fetchFromTarball ...)</code> all these fetched tarballs are not referenced anywhere and removed on GC), but overall it frees you from runnning GC manually often.
  options = "--delete-older-than 30d";
};
</syntaxhighlight>
 
This can result in redownloads (tarballs fetched with <code>import (builtins.fetchFromTarball ...)</code> for example are not referenced anywhere and removed on GC), but it frees you from runnning GC manually.


== Moving the store ==
== Moving the store ==