Garbage collection approaches

[deemp]

Here's a discussion of garbage collection approaches.

Problem statement

When restoring a Nix store from a cache, the store may contain old unnecessary paths.
These paths should be removed sometimes to limit cache size and ensure the fastest restore/save steps.

Approach 1

Produce a cache once, use it multiple times. Don't collect garbage.

Advantages:

• Unnecessary paths are saved to a cache only during a new save.

Disadvantages:

• Unnecessary paths can accumulate between new saves.
  • A job at the firs run produces a path A and saves a cache.
  • The job at the second run restores the cache, produces a path B, and saves a cache. The cache has both A and B.
  • etc.

Approach 2

Collect garbage before saving a cache.

Advantages:

• Automatically keep cache at a minimal/limited size

Disadvantages:

• No standard way to gc only old paths.

Hopefully working solutions

• Use nix profile install to save any nix store path or installable from garbage collection.
  • Get store paths of inputs via nix flake archive as in Offline flake development NixOS/nix#4250 (comment)
  • Get outputs via nix flake show --json | jq '.packages."x86_64-linux"|keys[]'| xargs -I {} on x86_64-linux (nix build --all: build all packages in a flake NixOS/nix#7165)
• Use nix-heuristic-gc for cache eviction via atime
• Keep inputs (Offline flake development NixOS/nix#4250, Flakes in the nix store do not retain references to their inputs NixOS/nix#6895).
• Start direnv in background.
• nix store gc when a cache size reaches a certain limit.
• gc via gc roots nix-cache-cut
• gc based on time cache-gc

[deemp]

Moved to README in 3c9ac93