GNU bug report logs - #45327
[PATCH] git: Periodically delete least-recently-used cached checkouts.

Previous Next

Full log

Message #20 received at 45327 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 45327 <at> debbugs.gnu.org
Subject: Re: [bug#45327] [PATCH] git: Periodically delete
 least-recently-used cached checkouts.
Date: Tue, 22 Dec 2020 14:33:33 +0100

Hi,

zimoun <zimon.toutoune <at> gmail.com> skribis:

> On Sat, 19 Dec 2020 at 23:06, Ludovic Courtès <ludo <at> gnu.org> wrote:

[...]

>> I noticed that my ~/.cache/guix/checkouts directory had accumulated
>> a lot of cruft from channels, playing with ‘--with-branch’ and such,
>> and that it would be nice to clean it up once in a while.
>>
>> This is what this patch does.  It uses the (guix cache) default
>> strategy, which consists in deleting least-recently-used items by
>> looking at their atime.
>
> This is done at pull time, right?

This is happens when ‘update-cached-checkout’ is called: when updating a
channel, using ‘--with-git-url’, etc.

> Personally, I would prefer at gc time, and even maybe with an option
> to “guix gc”.

Hmm yes (currently the two things are unrelated.)  I have a slight
preference for something automated that you don’t have to worry about.

> Because, IIUC, every 5 days, the entries older than 1 month will be
> deleted.

Correct.

> As an extensive user of the time-machine, it means that I will do this
> extra work more than often, slowing down the already slow
> “time-machine”.

Let’s say there’s a couple of channels you regularly pull from, like a
few times per months.  Their checkout would never be deleted so you
wouldn’t notice any change in terms of performance.

The difference you’d see is if you pull from a few channels, but less
than once per month.  In that case, the ‘guix’ channel would remain in
cache (because cache cleanup happens after the cached checkout has been
updated), but the other channels would be deleted just to be cloned
again soon after that.

Does that make sense?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.