[bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items.

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3957 bytes --]

On 23-07-2022 01:07, Ludovic Courtès wrote:

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

It's definitively possible to skip the phase, AFAICT -- there was some 
code doing exactly that, and for some use cases the limitations (i.e., 
very limited amount of space actually being freed) were found to be 
acceptable, for the user isn't trying to free space in the first place 
(doing that would be a nice side-effect, but not what the user was 
trying to accomplish), and other people aren't impacted by the 
limitations as it's an off-by-default switch.

As noted before, sometimes the point isn't to free space, but only to 
collect _some_ (not all, just some, i.e., the store item, but the 
individual files in the store item don't matter) garbage. For some users 
and use cases, not freeing space is not a problem, as mentioned in the 
previous mail:

> This is important for, say, testing substitution code efficiently (or 
> SWH code as mentioned previously, etc).
>
> There, the lack of freeing space is not a concern.  This appears, 
> after reading debbugs, to be already mentioned at 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51427#20.
For these users, skipping that phase (or another solution, whatever 
works), is quite valuable and not a problem.

(Remember, people modifying the substitution code or such are users too.)

That said, there were some approaches mentioned that do skip the phase, 
but in a manner such that space is still freed (but only the relevant 
space, not things from the whole store, so performance wouldn't be 
horrible).

> 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.
If the user runs "guix gc" with an off-by-default switch that isn't 
recommended for general usage, whose description makes it look like some 
arcane thing (if you didn't know the phase already, how would you know 
what ‘don't delete unused links’ means?), while they actually just 
wanted to free space, then that's their problem; not Guix, I think.  
Furthermore, if they somehow do that by mistake, then can just do a 
regular "guix gc" afterwards -- it's a quite recoverable mistake. As 
such, I don't see a problem.

Also, it _does_ collect garbage -- it collects the /gnu/store/... item, 
it just doesn't collect _all_ the garbage (it doesn't collect the 
individual files in the store item or the things in /gnu/store/.links).

If you mean it doesn't fit under "guix gc" because it doesn't free much 
space and hence doesn't fit in the concept of "gc'ing", I suppose we 
could make a new command "guix $bikeshed" that's like "guix gc" except 
sometimes it doesn't free much space, though I don't see the point when 
we already have "guix gc" where it's easy to just add a flag. 
Alternatively, we could just inflate the concept of "GC" a little such 
that it becomes more useful for some people without making it worse for 
others instead of defining a new command.

Summarised: gc'ing is not limited to freeing $N MiB, there are other 
valid reasons to gc too as mentioned previously (make some slots empty 
in the weak hash table that is /gnu/store), why are attempts to 
implement some huge optimisations for the latter rejected when they 
don't impact the former at all?

Or summarised another way: we aren't trying to remove the GC, rather 
previously the GC mostly only supported running a full cycle, with this 
patch the GC also has a more incremental mode of operation.

Greetings,
Maxime.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]