all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>, guix-sysadmin <guix-sysadmin@gnu.org>
Subject: Re: Dropping gzip-compressed substitutes
Date: Mon, 14 Feb 2022 18:50:48 +0100	[thread overview]
Message-ID: <87h791s5fr.fsf@gnu.org> (raw)
In-Reply-To: <878rum1pph.fsf@gmail.com> (Maxim Cournoyer's message of "Mon, 07 Feb 2022 13:44:42 -0500")

Hi!

Thumbs up for the progress made!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> 3. Come up with a Guile script that is able to
>
>   a) Strip gzip-related metadata from the .narinfo guix-publish metadata
>   files
>   b) recompute and update their 'Signature' field.
>
> 4. Finally, 'rm -r /var/guix/publish/gzip' and free about 6.5 TiB of data.

As discussed on IRC, I’m skeptical about this because:

  1. It requires the development and testing of a custom tool that’s
     easy to get wrong—e.g., it removes a gzipped nar for something that
     had nothing but gzip available, etc.

  2. That code would have to run with privileges that give it access to
     the signing key on berlin.

  3. Those 6.5 TB are an initial constant factor; growth of the storage
     requirements going forward probably matters more and
     <https://issues.guix.gnu.org/53901> will give us more flexibility
     on that.

I like Chris Baines’ idea of decoupling nar distribution from nar
building.  If we want to keep nars long enough so that ‘time-machine’ is
usable, then storage requirements will keep growing.

Perhaps that means we can regularly copy nars “elsewhere” for long-term
storage, using nar-herder, rsync, or whatever.  The machine that stores
nars long-term has low requirements compared to the build farm because
we don’t need to trust it for anything other than storage.  If that
makes things easier (and financially viable), a VPS is good enough.

Thoughts?

Ludo’.


  parent reply	other threads:[~2022-02-14 17:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07 18:44 Dropping gzip-compressed substitutes Maxim Cournoyer
2022-02-07 20:02 ` Ricardo Wurmus
2022-02-08 13:34 ` Mathieu Othacehe
2022-02-08 14:13   ` Maxim Cournoyer
2022-02-08 16:53   ` Ricardo Wurmus
2022-02-09  2:35     ` Maxim Cournoyer
2022-02-09  5:06     ` Maxim Cournoyer
2022-02-09 10:29   ` Efraim Flashner
2022-02-14 17:50 ` Ludovic Courtès [this message]
2022-02-14 20:04   ` Attila Lendvai
2022-02-15 12:20   ` Mathieu Othacehe
2022-02-15 18:29     ` Christopher Baines
2022-02-21  5:13     ` Maxim Cournoyer
2022-02-21 11:26       ` Ricardo Wurmus
2022-02-21 20:04         ` Gábor Boskovits

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h791s5fr.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=guix-sysadmin@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.