Re: guix gc takes long in "deleting unused links ..."

["Ludovic Courtès" <ludo@gnu.org>]

Hi!

Caleb Ristvedt <caleb.ristvedt@cune.org> skribis:

[...]

> Ideally, the reference-counting approach to removing files would work
> the same as in programming languages: as soon as a reference is removed,
> check whether the reference count is now 0 (in our case 1, since an
> entry would still exist in .links). In our case, we'd actually have to
> check prior to losing the reference whether the count *would become* 1,
> that is, whether it is currently 2. But unlike in programming languages,
> we can't just "free a file" (more specifically, an inode). We have to
> delete the last existing reference, in .links. The only way to find that
> is by hashing the file prior to deleting it, which could be quite
> expensive, but for any garbage collection targeting a small subset of
> store items it would likely still be much faster. A potential fix there
> would be to augment the store database with a table mapping store paths
> to hashes (hashes already get computed when store items are
> registered). Or we could switch between the full-pass and incremental
> approaches based on characteristics of the request.

Note that the database would need to contain hashes of individual files,
not just store items (it already contains hashes of store item nars).

This issue was discussed a while back at
<https://issues.guix.info/issue/24937>.  Back then we couldn’t agree on
a solution, but it’d be good to have your opinion with your fresh mind!

>> Or better: Is it save here to just hit CTRL-C (and let the daemon work
>> in background, or whatever)?
>
> I expect that CTRL-C at that point would cause the guix process to
> terminate, closing its connection to the daemon. I don't believe the
> daemon uses asynchronous I/O, so it wouldn't be affected until it tried
> reading or writing from/to that socket.

The guix-daemon child that handles the session would immediately get
SIGHUP and terminate (I think), but that’s fine: it’s just that files
that could have been removed from .links will still be there.

Ludo’.