From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id qMbBH0yWBmYoNAAAe85BDQ:P1 (envelope-from ) for ; Fri, 29 Mar 2024 11:22:04 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id qMbBH0yWBmYoNAAAe85BDQ (envelope-from ) for ; Fri, 29 Mar 2024 11:22:04 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=cFovEnx2; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1711707724; a=rsa-sha256; cv=none; b=YnM5vk8UnBD5Isx8rH8V3PEvE0OPikRO1MiySc8S4ESj+wCG0jr9Rr6BIVlY1PGMVMFtGY txYoeRdEwEvp2MSfM8zxpSrGl0GVmd8UcwqBK/5S6J5ce1kCe4+ycT/gClWPgq8I0fYJy/ /FDT9yyBpvWpvPavX8x11X+/azyAlqP1314Pmvi63oGgwDFeKWXq/we3wLbhhFgcNs4CEn HkXPB/tibfz1N7AFoEYwvuJ8VZqDWRUleECuTuEGUEKMz1z+aQ0gxAaHzFdTgmw3qou1yQ R1JBoyCljiP33Fq/fiTAEe4PpVsA5eDb7eM6YRePhQP6gZtu6dc/ZvuisMxbTA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=cFovEnx2; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1711707724; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=jQkY4OZeanQSlTJEI7q4a4mV32mvoTp8rW4hbjz7qhU=; b=YZ8ekIKYIDBfNaU99kukbPH7Raurdi400flN9ynffTd24qV37HF2u2bFactUb8OjofWikO 90z7idcWF6oEnyLzkI1/gzw0i9fPjNFIvGvQUPY8eT0ObSTW/o2T0WTeYUbJdKu5sqdoVE Le1Jlm+gtM8WCZ+LCj47zQEjaoYXP6RjYdqq8ANGnav/nATRPZPqyGkRGBj8QIq8FCAnFO 3s0bynw1sMLZlUFkqFmnYPxU9n06URRS7wFFHt/BPAuCvAC7TB8x5+rT27MtiBH3k5ABVO APZuea65bpdZX8y0VxPwQF6/vJSOzan/TqNb7kb3HYbRAwHYRLGyx6HL495AOg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9EE0230E02 for ; Fri, 29 Mar 2024 11:22:03 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rq9Mo-0002eV-LH; Fri, 29 Mar 2024 06:21:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rq9Mi-0002cP-MX for guix-devel@gnu.org; Fri, 29 Mar 2024 06:21:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rq9Mi-0004vs-EH; Fri, 29 Mar 2024 06:21:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=jQkY4OZeanQSlTJEI7q4a4mV32mvoTp8rW4hbjz7qhU=; b=cFovEnx2qsXy+J1XM3/F tnNrRGbSLclM4EQ/jGi9se6DFQpgB8aox4WdHKWlx//GHUugB7cMoQEb+8yaIbGbnMgbEhwBqQ4wi FvZ4tbXaNML9rWmHxj4gnh0r5ZhzwCtEy+Azj/faWbnsJuHG/dPP7WbMhN/OiyR6GOmatU55f6fsE nIEmAKiZ7uxIKH/ghR7gMQiVDAeo2z/4aLb0mJZrJZ3+NEFCa3ZTjcYjCF7LyxuQLV45sxAWnAjHe sFSYBtGFUHNMyHLa13g/46lCBY8D7oVGp7WXsrOzkRELn+Dbf89UlXnGTJXfqgKgXaLvjXMf6kdMZ XYLAH2MAc27cNA==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Christopher Baines Cc: guix-devel@gnu.org Subject: Re: March update on bordeaux.guix.gnu.org In-Reply-To: <877chnfw81.fsf@cbaines.net> (Christopher Baines's message of "Wed, 27 Mar 2024 13:49:07 +0000") References: <877chnfw81.fsf@cbaines.net> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: =?utf-8?Q?D=C3=A9cadi?= 10 Germinal an 232 de la =?utf-8?Q?R=C3=A9volution=2C?= jour du Couvoir X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Fri, 29 Mar 2024 11:21:37 +0100 Message-ID: <87sf09gwy6.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Spam-Score: -9.61 X-Migadu-Queue-Id: 9EE0230E02 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.61 X-TUID: 0uG+cxqUhYKs Hi! Christopher Baines skribis: > I've finally got around to starting to address the problems with > disappearing nars discussed in [3]. The nar-herder now schedules nars > which it's generated for removal and the time for removal is based on > the TTL in use. > > 3: https://issues.guix.gnu.org/63634 Neat! Yeah it=E2=80=99s important to honor the TTL that=E2=80=99s advertis= ed in narinfos. > Related to this, I've added options to the nar-herder to help change the > TTL being used, and reduced the TTL for bordeaux.guix.gnu.org to 10 > minutes (from 180 days) [4]. This will at least mean that in the future, > the nar-herder on bordeaux will be able to delete zstd compressed nars > that it's generated more quickly. It=E2=80=99s not 10mn right now: --8<---------------cut here---------------start------------->8--- $ wget --debug -qO/dev/null https://bordeaux.guix.gnu.org/yr39rh6wihd1wv6gz= f7w4w687dwzf3vb.narinfo 2>&1 |grep Cache Cache-Control: max-age=3D15502374 --8<---------------cut here---------------end--------------->8--- Or maybe that=E2=80=99s just for newly created nars? But then again, that=E2=80=99s the advertised TTL; the real TTL is still infinite, right? > I'm really unsure about the need/usefulness of narinfo caching in > general, the cost of storing all these narinfos locally is quite high I > think and I don't really know why it's done. It=E2=80=99s a cache. It=E2=80=99s useful to have this cache because in = =E2=80=9Ctypical=E2=80=9D Guix usage you=E2=80=99re likely to ask repeatedly for the same substitutes. Regarding the cost, 3f5e14182931f123c10513a3e1e2abaebfb52279 made things more reasonable by putting a higher bound on narinfo retention. On my laptop, I have: --8<---------------cut here---------------start------------->8--- $ ls -lrt /var/guix/substitute/cache/4refhwxbjmeua2kwg2nmzhv4dg4d3dorpjefq7= kiciw2pfhaf26a/ |wc -l 11549 $ du -h /var/guix/substitute/cache/4refhwxbjmeua2kwg2nmzhv4dg4d3dorpjefq7ki= ciw2pfhaf26a/=20 50M /var/guix/substitute/cache/4refhwxbjmeua2kwg2nmzhv4dg4d3dorpjefq7ki= ciw2pfhaf26a/ --8<---------------cut here---------------end--------------->8--- Maybe that=E2=80=99s still excessive and we could further reduce the maximum caching time. > The mishandling of these zstd nars available from bordeaux was the last > thing on my mind blocking proposing to switch the default substitute > server ordering, so I've now gone ahead and done that in [5]. > > 5: https://issues.guix.gnu.org/70028 > > Obviously the differences to having ci.guix.gnu.org first in the list of > substitute URLs is subtle, but I'm hoping this will help with substitute > speed issues (as discussed in [6]) plus increase the impact of mirroring > work for the bordeaux substitutes in the future. Good! > 6: https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00290.html BTW, should we document this mirror somewhere (and also ensure that Guix Foundation pays the bills), or do you view it more as an experiment for now? > Apart from that, the main thing on my mind for the next year regarding > bordeaux substitutes specifically is storage space. We're at 90% > capacity on hatysa (one of the two machines storing all the nars) so > this will need looking at shortly. I'd also like to finally get removing > nars that don't relate to the guix master branch happening, as that > should free up a little bit of space at least. Nice (the difficulty, I guess, is that some substitutes that we not initially for =E2=80=98master=E2=80=99 eventually get used on =E2=80=98mast= er=E2=80=99). On this issue, I think we should learn from fellow NixOS hackers. They kept substitutes for ~20 years I think and are now in a difficult position because they cannot afford, financially, to keep that. So one of the solutions envisioned was to figure out which of these millions of substitutes were =E2=80=9Cimportant=E2=80=9D (for instance, source code), w= hich turns out to be very hard if you don=E2=80=99t have that info already at hand. https://discourse.nixos.org/t/nixos-s3-long-term-resolution-phase-1/36493 Do you think the Data Service or another source of info would let us make such decisions? If we take it to the extreme, we could have a sophisticated retention policy like: drop all fixed-output derivations known to be available from disarchive.guix + SWH, drop substitutes for packages that have less than 100 dependents, etc. Thanks for the update! Ludo=E2=80=99.