[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: |
Maxime Devos |
Subject: |
[bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items. |
Date: |
Sat, 23 Jul 2022 12:24:03 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 |
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.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., (continued)
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Liliana Marie Prikler, 2022/07/18
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Ludovic Courtès, 2022/07/19
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Liliana Marie Prikler, 2022/07/19
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Tobias Geerinckx-Rice, 2022/07/19
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Ludovic Courtès, 2022/07/21
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Liliana Marie Prikler, 2022/07/21
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Ludovic Courtès, 2022/07/22
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Maxime Devos, 2022/07/22
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Ludovic Courtès, 2022/07/22
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items., Liliana Marie Prikler, 2022/07/23
- [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items.,
Maxime Devos <=