all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 51427@debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items.
Date: Sun, 31 Oct 2021 15:39:04 +0100	[thread overview]
Message-ID: <9f9a708f8ecbb49464e3d939be89638a53dc0d30.camel@gmail.com> (raw)
In-Reply-To: <87h7cxp9tl.fsf@gnu.org>

Hi,

Am Sonntag, den 31.10.2021, 15:07 +0100 schrieb Ludovic Courtès:
> What do you mean?  When doing VM testing, I regularly do ‘guix gc -D
> /gnu/store/…-disk-image’ precisely to save space.  Fortunately it
> does have the intended effect of freeing a bunch of GiBs.
Fair enough, different strokes and all.

> > Plus, you could invoke it like
> > 
> >   guix gc -D dead-item dead-item live-item dead-item
> > 
> > It would fail at live-item and then not continue to free the links
> > of the two dead items prior.
> 
> Yes, and that’s annoying, but it’s unrelated.  :-)
> 
> > So there's a few things we could do here:
> > 
> > 1. simply fail and have the user deal with it (including the option
> > of doing a normal `guix gc' or `guix gc -C 1')
> > 2. remember which paths were live and dead and always clean up the
> > links, only reporting errors afterwards
> > 3. add an option to explicitly check the .links directory (which
> > defaults to true for the current things, but could also be used to
> > clean links after a liveness check or after a do-nothing `guix gc
> > -F').
> > 4. ...
> 
> You seem to be proposing to remove ‘-D’ altogether.  
I wrote no such thing.  Obviously there needs to be a way of removing
single items from the store, but what else to do is not so clear.  It
is only obvious that traversing all of .links is too expensive.

> I agree it has the shortcomings you write, but I think it’s
> occasionally useful nonetheless.
> 
> My proposal would be either the status quo, or removing just the one
> link that matters from /gnu/store/.links upon ‘-D’.
> 
> Thoughts?
There isn't "just the one link that matters" when it comes to removing
multiple items -- heck, even if tasked to free up just 5MB rather than
all of the garbage, traversing all .links is probably too expensive.

Accepting that we might want to always delete links at the end, I think
`guix gc' needs a way to record which links had their count go to 1
during garbage deletion, so that when it comes to deleting links only
those are tried (and of course checked again to make sure their count
is indeed still 1).  This should be the preferred mode if less than
some arbitrary large number of store items are affected (let's say 1024
or some multiple of it) or a total cleaning of .links has been forced.

Though perhaps there's a way to do this without manual recording. 
Let's say we notice a link count going to one as we clear the trash. 
We could just add the link behind it to the trash right away to ensure
that it is not reused by something else and then clean the trash a
second time (we would have to check for potential race conditions in
this case).

WDYT?

Liliana





  reply	other threads:[~2021-10-31 14:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27  3:49 [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items Maxim Cournoyer
2021-10-28 14:16 ` Ludovic Courtès
2021-10-31  8:50   ` Liliana Marie Prikler
2021-10-31 14:07     ` Ludovic Courtès
2021-10-31 14:39       ` Liliana Marie Prikler [this message]
2021-10-31 20:51       ` Maxim Cournoyer
2021-11-03 10:45         ` zimoun
2021-11-06 16:57         ` Ludovic Courtès
2021-11-09  4:11           ` Maxim Cournoyer
2021-11-09  4:57             ` Jack Hill
2021-11-09 12:56               ` Ludovic Courtès
2021-11-09 18:10           ` zimoun
2021-11-17 10:02             ` Ludovic Courtès
2021-11-17 11:49               ` zimoun
2022-07-18 13:57                 ` Ludovic Courtès
2022-07-18 17:03                   ` Liliana Marie Prikler
2022-07-19  8:34                     ` Ludovic Courtès
2022-07-19 18:42                       ` Liliana Marie Prikler
2022-07-19 19:25                         ` Tobias Geerinckx-Rice via Guix-patches via
2022-07-21  9:21                           ` Ludovic Courtès
2022-07-21 18:02                             ` Liliana Marie Prikler
2022-07-22 12:14                               ` Ludovic Courtès
2022-07-22 13:39                                 ` Maxime Devos
2022-07-22 23:07                                   ` Ludovic Courtès
2022-07-23  6:52                                     ` Liliana Marie Prikler
2022-07-23 10:24                                     ` Maxime Devos
2023-06-12 20:55 ` Felix Lechner via Guix-patches via
2023-06-13  4:26   ` Liliana Marie Prikler

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

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

  git send-email \
    --in-reply-to=9f9a708f8ecbb49464e3d939be89638a53dc0d30.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=51427@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.