Hi! Simon Tournier <zimon.touto...@gmail.com> writes: > Well, maybe it could be helpful to backfill for some specific commits as > v1.4.0, and maybe the older ones too.
I'd have to think about how to best do that (some combination of the mechanism of `guix weather` + our importer?). The nar-herder endpoint we're using to find new store paths does not return things that old. Maybe this just solves itself lazily, as people are likely to pull stuff from those commits I guess (at least for all the stuff used in base installations). > Do you have a cache policy for pruning the substitutes on your mirror? > Or is it a full-mirror exactly mirroring bordeaux.guix.gnu.org? The lazily fetched store paths are LRU-evicted if we end up with more than 100TiB of them on a single serving machine. For context, there's a round-robin of serving machines in a few DCs and they do the lazy fetching locally. This is probably unlikely in the short/medium term. For stuff mirrored actively through nar-herder there is no eviction policy (it goes into distributed object storage and is served from there). Our storage admins were surprised to hear that Guix generates MUCH more data than e.g. a full mirror of Debian, but we're not exactly constrained in terms of storage so I don't think they'll mind much. I've noticed that our mirror behaves slightly differently from others in the CLI. In particular when checking for the presence of substitutes on e.g. bordeaux the only progress indications I see are 0% and then immediately 100%. For ours it progresses incrementally. Maybe there's some sort of bulk-checking endpoint we should support, or maybe I'm still mostly hitting as-of-yet uncached older lazy paths. Need to investigate that ... > PS: BTW, thank you for your post « Trying Guix: A Nixer's Impressions ». > Very nice read. :-) Hah, thanks! I'll probably write a follow-up soon-ish.
