guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#51427] [PATCH] nix: libstore: Do not remove unused links when delet


From: Liliana Marie Prikler
Subject: [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items.
Date: Sun, 31 Oct 2021 15:39:04 +0100
User-agent: Evolution 3.34.2

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 via email to

[Prev in Thread] Current Thread [Next in Thread]