unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>,
	"Maxime Devos" <maximedevos@telenet.be>
Cc: 51427@debbugs.gnu.org, Tobias Geerinckx-Rice <me@tobias.gr>,
	maxim.cournoyer@gmail.com, zimon.toutoune@gmail.com
Subject: [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items.
Date: Sat, 23 Jul 2022 08:52:40 +0200	[thread overview]
Message-ID: <dc0a9584b5248816ccd7d146b9d6b12417a1b688.camel@gmail.com> (raw)
In-Reply-To: <874jz8eogx.fsf@gnu.org>

Am Samstag, dem 23.07.2022 um 01:07 +0200 schrieb Ludovic Courtès:
> Hi,
> 
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > On 22-07-2022 14:14, Ludovic Courtès wrote:
> > > Hi,
> > > 
> > > Liliana Marie Prikler<liliana.prikler@gmail.com>  skribis:
> > > 
> > > > I don't think deleting links will ever be fast on that disk. 
> > > > But what I've been saying the whole time is that I don't always
> > > > need the links deleted.  I think adding "expert" switches to
> > > > skip these phases might actually be enough – after all, if I
> > > > ever do want to run a full GC, the information ought to be the
> > > > same, no?
> > > The expert will have to know that skipping that phase will have
> > > the effect of *not* freeing space on the device, so…
> > 
> > I believe the word "expert" implies that the expert knows that,
> 
> Apologies for being elliptic.  My point here, as has been discussed
> earlier in this thread, is that we can’t just skip that phase or we’d
> simply leave files around without actually deleting them.
> 
> Thus, a command-line switch to skip the phase doesn’t seem valuable
> to me because it’d let users run the GC in a way that doesn’t
> actually collect garbage.
> 
> I hope this is clearer!
As noted before, I don't always run GC to free up X amount of space. 
Even if I did, link deletion is greedy and frees up whatever it can. 
So the initial suggestion to only look at what might have been freed in
this gc already makes sense.  However, it was ruled complicated because
the GC is implemented in C++.  

My personal motivation to just skip the phase entirely comes from the
hypothesis that the store is in a sane state even if the links are not
deleted.  Particularly, if I `guix gc broken-item' and `guix build
broken-item', even without deleting links, the broken-item should now
be fixed.  This has practical advantages over `guix build --repair': if
the last `guix package' or `guix system' failed mid-way, any user, not
just root, can simply `guix gc' the broken items.

Now, I understand that as a default, you never want to skip this phase,
because it doesn't actually free up disk space.  But if you have a slow
disk with large space, do you really need to free all that much space,
or would it be fine to delay freeing it until a later date?

Cheers




  reply	other threads:[~2022-07-23  6:53 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
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 [this message]
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

  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=dc0a9584b5248816ccd7d146b9d6b12417a1b688.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=51427@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    --cc=maximedevos@telenet.be \
    --cc=me@tobias.gr \
    --cc=zimon.toutoune@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 public inbox

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

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).