guix-patches
[Top][All Lists]
Advanced

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

[bug#45327] [PATCH] git: Periodically delete least-recently-used cached


From: Ludovic Courtès
Subject: [bug#45327] [PATCH] git: Periodically delete least-recently-used cached checkouts.
Date: Tue, 22 Dec 2020 14:33:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi,

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

> On Sat, 19 Dec 2020 at 23:06, Ludovic Courtès <ludo@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’.





reply via email to

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