unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: "(" <paren@disroot.org>
To: "Gottfried" <gottfried@posteo.de>, <help-guix@gnu.org>
Subject: Re: Garbage Collector
Date: Mon, 25 Jul 2022 15:57:24 +0100	[thread overview]
Message-ID: <CLOTPS54S7KT.2QSLMDQA96U47@guix-aspire> (raw)
In-Reply-To: <bfba0be0-60e5-3304-6c3d-72b930f43823@posteo.de>

On Mon Jul 25, 2022 at 10:51 AM BST, Gottfried wrote:
> The manual says that it is dangerous to use: "guix gc"
> because it can delete too much.
I think you're misunderstanding what the manual means, and what garbage
collection entails.

(Disclaimer: I'm not a Guix expert, so it's possible this explanation is
partially incorrect.)

The store is a massive database, containing things like outputs,
derivations, and profiles. These are then symlinked into various
positions in the system, for example your user's profile:

ʃ readlink -f .guix-profile
/gnu/store/vpjlpmxnfsmbzzmv15das5gzcg308cdk-profile

which itself contains symlinks to subpaths of outputs:

ʃ readlink /gnu/store/vpjlpmxnfsmbzzmv15das5gzcg308cdk-profile/bin/vim
/gnu/store/kkc4ff1bxmb8qixiiy4rbc256m8l4rmz-vim-9.0.0000/bin/vim

In my profile, I have two packages installed:

ʃ guix package --list-generations
Generation 1 ...
  aerc ...
  vim ...

What happens if I remove `vim`? Well, we need to create an entirely new
profile (which does not contain Vim things). Our .guix-profile is now
linked to a completely different store path, this one without any
Vim-related symlinks:

ʃ readlink -f .guix-profile
/gnu/store/22ph0mlsd83k4p6wsc6276rhsk3qanxv-profile

ʃ ls /gnu/store/22ph0mlsd83k4p6wsc6276rhsk3qanxv-profile/bin
aerc

What happened to our Vim output path? Was it deleted?

ʃ test -e /gnu/store/kkc4ff1bxmb8qixiiy4rbc256m8l4rmz-vim-9.0.0000 && echo still exists
still exists

So, is it just hanging around in the store, taking up space? Not quite.
As you'll probably know, Guix supports rolling back to previous
generations:

ʃ guix package --list-generations
Generation 1 ...
  aerc ...
  vim ...

Generation 2 ...
  - vim ...

So Vim is actually still in use! But we've decided that we are
absolutely certain that we don't want Vim. Let's delete all records of
Vim's existence in our profile.

ʃ guix package --delete-generations
deleting /var/guix/profiles/per-user/paren/guix-profile-1-link

And now...

ʃ guix package --list-generations
Generation 929 ...
  aerc ...

No more Vim.

ʃ test -e /gnu/store/kkc4ff1bxmb8qixiiy4rbc256m8l4rmz-vim-9.0.0000 && echo still exists!
still exists!

What?! Vim really wants to stay alive. But it's not being used by
anything anymore, not even an old profile. So, how do we vanquish it?
With `guix gc` :)

ʃ guix gc
finding garbage collector roots...
deleting garbage...
[...]
[0 MiB] deleting '/gnu/store/kkc4ff1bxmb8qixiiy4rbc256m8l4rmz-vim-9.0.0000'
[...]
guix gc: freed 45.94845 MiBs

We did it! The Vim store path no longer exists (and neither does the Tcsh
store path, which is a dependency of Vim):

ʃ test -e /gnu/store/kkc4ff1bxmb8qixiiy4rbc256m8l4rmz-vim-9.0.0000 || echo gone!
gone!

So, `guix gc` makes sure never to touch anything that's still in use.
Quoting the manual,

> The garbage collector has a set of known roots: any file under
> /gnu/store reachable from a root is considered live and cannot be
> deleted; any other file is considered dead and may be deleted. The set
> of garbage collector roots (“GC roots” for short) includes default user
> profiles; by default, the symlinks under /var/guix/gcroots represent
> these GC roots. New GC roots can be added with guix build --root, for
> example (see Invoking guix build). The guix gc --list-roots command
> lists them.

This would make sense for a 'garbage collector'; after all, the term
usually refers to a system for automatically freeing unused memory, so
that it can be reused. If it were to accidentally free memory that's
still in use, someone's variable would suddenly point to invalid memory!
So the GC needs to be absolutely certain that nobody's using the memory.

The manual does say, though, that:

> Running guix gc with no arguments will collect as much garbage as it
> can, but that is often inconvenient: you may find yourself having to
> rebuild or re-download software that is “dead” from the GC viewpoint but
> that is necessary to build other pieces of software—e.g., the compiler
> tool chain.

And indeed, if we change our mind and decide we actually do want Vim, we
have to re-download it:

ʃ guix install vim
The following package will be installed:
   vim 9.0.0000

[...]

7.4 MB will be downloaded
[...]
 tcsh-6.22.03  323KiB ...
 vim-9.0.0000  7.1MiB ...
[...]

However, running `guix gc` is *never destructive or dangerous*, because
that would be counter to the entire purpose of a GC.

    -- (


  reply	other threads:[~2022-07-25 14:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-25  9:51 Garbage Collector Gottfried
2022-07-25 14:57 ` ( [this message]
2022-07-25 15:20 ` Felix Lechner via
2022-07-28 17:27   ` Gottfried
2022-07-28 17:36   ` Gottfried
2022-07-30  9:40   ` Gottfried
2022-08-09 20:18   ` Ludovic Courtès
2022-08-10 16:06     ` Garbage Collector - for your Information Gottfried

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CLOTPS54S7KT.2QSLMDQA96U47@guix-aspire \
    --to=paren@disroot.org \
    --cc=gottfried@posteo.de \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).