Hello,
Ricardo Wurmus ezt írta (időpont: 2022. febr. 21., H
12:34):
>
> Maxim Cournoyer writes:
>
> > This week, I'd like to try the following to see if we could get past
> > this:
> >
> > 1. Do the experiment again, now a 'rootdelay=20' kernel parameter was
> > added to Berlin's config. This
Maxim Cournoyer writes:
> This week, I'd like to try the following to see if we could get past
> this:
>
> 1. Do the experiment again, now a 'rootdelay=20' kernel parameter was
> added to Berlin's config. This may well be enough.
>
> 2. In case mounting the RAID 10 Btrfs root partition still
Hi everyone,
Mathieu Othacehe writes:
> Hey Ludo,
>
>> 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
Mathieu Othacehe writes:
>> 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
Hey Ludo,
> 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
> 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
>
Hi!
Thumbs up for the progress made!
Maxim Cournoyer 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
Hi!
Ricardo Wurmus skribis:
> Ludovic Courtès writes:
[...]
>> It was too early back then but I think we could consider dropping it
>> after 1.4.0 is out, announcing it in advance.
>
> Sounds good to me.
The maintainers went ahead and announced it, thumbs up! It might also
be worth
On Tue, Feb 08, 2022 at 02:34:49PM +0100, Mathieu Othacehe wrote:
>
> Hey Maxim,
>
> Sound like a fine plan.
>
> > 1. Promptly set up both a blog post and a NEWS entry announcing the
> > support for gzip substitutes is about to be phased out from the build
> > farm (1 month notice), urging
Hi again,
Syncing /var/cache has finally finished, after copying 16 TiB from the
old array in about 16 days:
rsync warning: some files vanished before they could be transferred (code 24)
at main.c(1330) [sender=3.2.3]
real17019m52.264s
user147m58.061s
sys 686m3.528s
I've now
Hi Ricardo and Mathieu,
Ricardo Wurmus writes:
> Hi Mathieu,
>
> thanks for the patch!
>
>> From bd306a8b20f2033d67755dd332a5d33b2f6b822d Mon Sep 17 00:00:00 2001
>> From: Mathieu Othacehe
>> Date: Tue, 8 Feb 2022 14:28:56 +0100
>> Subject: [PATCH 1/1] store: Warn about daemon deprecation.
>>
Hi Mathieu,
thanks for the patch!
> From bd306a8b20f2033d67755dd332a5d33b2f6b822d Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe
> Date: Tue, 8 Feb 2022 14:28:56 +0100
> Subject: [PATCH 1/1] store: Warn about daemon deprecation.
>
> * guix/deprecation.scm (warn-about-old-daemon): New
Hey Maxim,
Sound like a fine plan.
> 1. Promptly set up both a blog post and a NEWS entry announcing the
> support for gzip substitutes is about to be phased out from the build
> farm (1 month notice), urging users to upgrade their daemon to a version
>>= 1.1.0.
I addition, we could warn
Hi Mathieu!
Mathieu Othacehe writes:
> Hey Maxim,
>
> Sound like a fine plan.
>
>> 1. Promptly set up both a blog post and a NEWS entry announcing the
>> support for gzip substitutes is about to be phased out from the build
>> farm (1 month notice), urging users to upgrade their daemon to a
Maxim Cournoyer writes:
> 1. Promptly set up both a blog post and a NEWS entry announcing the
> support for gzip substitutes is about to be phased out from the build
> farm (1 month notice), urging users to upgrade their daemon to a version
>>= 1.1.0.
Can we make the “guix” command print a
Hello Guix!
While migrating our file system to the newly installed SSD-backed
storage on Berlin, I noticed that the guix-publish cached nars use a lot
of space: 6.5 TiB for the gzip compressed nars alone, or about 30% of
the new storage capacity.
The new array capacity was recently added so that
Ludovic Courtès writes:
> Hello!
>
> I saw in the maintainer meeting minutes the point about substitute
> compression.
>
> Back when zstd substitutes were introduced, the idea was to “eventually”
> drop gzip substitutes (lzip substitutes remain relevant⁰):
>
>
Hello!
I saw in the maintainer meeting minutes the point about substitute
compression.
Back when zstd substitutes were introduced, the idea was to “eventually”
drop gzip substitutes (lzip substitutes remain relevant⁰):
https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00333.html
It
18 matches
Mail list logo
