Re: GC strategy on clusters

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Thu, 1 Apr 2021 at 14:36, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:
> Efraim Flashner <efraim@flashner.co.il> skribis:
>
> > On Thu, Apr 01, 2021 at 12:17:22PM +0200, Ludovic Courtès wrote:
>
> [...]
>
> >>   guix package --delete-generations=4m
> >>
> >> or similar, which was enough to free more space.

For now, I am waiting to reach the full capacity at hand to ask how to
deal with it. ;-)

> > I feel like 4-6 months should be plenty for anything active. Even if it
> > were run automatically for them it wouldn't remove the last generation.
>
> It depends.  A practical use case I have in mind: you run experiments,
> you submit a paper including its results, you get initial reviews months
> later, and even later it’s published and you get to present it.  At that
> point, you want to answer questions and to reproduce it.  4–6 months is
> not a lot in that context.

To add another data point.  Even it is hard to have a good overview, I
would say the average is 2-4 years for a typical project.  It is hard
because currently all is not done with the same tools for the same
task.  For instance, some data is cleaned with some tools, then an
partial analysis is done, months later another data is added so
another partial analysis with probably different tools, then months
later a full toolsuite as Bioconductor (or whatever) is updated and
some analysis are re-done.  The final publication is a mix of all over
the 2-4 years project with details at various level.

Other said, it depends on the level we are looking.

> (Though of course, ideally you’d save channels.scm + manifest.scm and
> share it with reviewers and readers in the first place…)

It is what I am tirelessly explaining in my lab. ;-)

> >> Longer term, I think Guix should automatically delete old generations
> >> and instead store the channels + manifest to reproduce them, when
> >> possible.
> >>
> >
> > This seems to help a bit less when we run into issues about dates being
> > wrong on SSL tests, or when sources go missing.
>
> Good points.  Hopefully “sources go missing” can soon be considered
> addressed.  Really, failing TLS tests is the most worrisome issue to me
> because we don’t have any idea on how to address it systematically.

By "soon", you mean the bricks are there and it is missing to glue
them together.  From my opinion, some details need to be addressed to
have a full end-to-end sources fallback, since evil is hidden inside
the details. ;-)

About the TLS, you proposed to setup a machine ahead of clock.  Maybe
it is worth to try.

> > I guess I'm not really sure if its a technology problem or a people
> > problem. Figuring out if someone is the only one pulling in a copy of
> > glibc-2.25 is doable but how many copies of diffoscope is too many?
> >
> > On a practical note, 'guix package --list-profiles' as root currently
> > lists everyone's profiles so it can be easier to see who has older
> > profiles hanging around.
>
> Actually, as non-root, I walked /var/guix/profiles/per-user on the
> cluster to see the number of generations per user, which allowed us to
> target those with a lot of generations.  :-)

Well, when we discussed the '--list-profiles', it was initially for my
personal purposes.  Then, I have tried to use it to monitor the few
users that I have.  Well, in Biology they have the concept of "-80
fridge".  It is a big and very cold fridge where you keep samples,
potentially for a long time.  Everybody put in until it is full and
once it is full, there is endless discussion on what to throw... until
the fridge is broken because shutdown or unexpected failures and then
it is obvious to everybody what needs to be taken or thrown.  I am
using such analogy to explain the hygiene to have on shared machines
Hum, once written I do not know if it relevant. ;-)

From my point of view, having a channel+manifest "backup" for old
profiles seems something to try.  It cost nothing with
''--export-manifest" and "--export-channels".

Cheers,
simon