| 20 Jun 2026 |
 pveierland | * | 08:54:33 |
| pveierland | * | 08:55:32 |
| pveierland | I'd guess it could relate to determinism and avoiding additional parameters. | 09:01:02 |
| pveierland | * | 09:03:08 |
 flokli | FileHash is not verified at all, and some people looked into using multi-block for various usecases. | 09:06:47 |
| flokli | In the end the conclusion was that xz isn't really worth it, which is why we're now with zstd. | 09:07:11 |
| pveierland | Is zstd in use on cache.nixos.org now? Does it support ranged reads? | 09:08:12 |
| flokli | zstd is in use. Don't know if it allows ranged reads. | 09:08:53 |
| pveierland | Do you know why it was chosen over brotli? | 09:09:40 |
| flokli | No | 09:09:57 |
| flokli | Ideally all the compression parts would be a content-encoding concern, so range requests wouldn't need to be complicated at all. That's what snix-nar-bridge does, it sends Compression: none and relies on libcurl to request zstd-compressed. That of course not realistic for the c.n.o situation, where we currently serve from the bucket "directly", as it would be even more costly than it already is. | 09:11:57 |
| flokli | If you're ok with the current caveats, you're welcome to use nixos.snix.store for the mynixos usecase as a fetch-through version. Gives you c.n.o with Compression: none and zstd content encoding. | 09:14:56 |
| pveierland | Interesting, thank you 👍 I'll have a look. Do you know ~coverage/content available compared to c.n.o? | 09:17:03 |
| pveierland | Found the stats 👍 | 09:18:21 |
| flokli | We have "everything" in c.n.o. the first request from anyone to the Narinfo url is "slow" though, as it needs to ingest the NAR | 09:18:47 |
| pveierland | Ah, so it's just a lazy cache with better interface? | 09:19:24 |
| flokli | In reply to @pveierland:matrix.org
Ah, so it's just a lazy cache with better interface? Check the landing page, and give it a few requests. | 09:19:58 |
| pveierland | Wait, how many stores does it pull from? | 09:19:59 |
| flokli | Only c.n.o | 09:20:20 |
| flokli | In reply to @flokli:matrix.org
We have "everything" in c.n.o. the first request from anyone to the Narinfo url is "slow" though, as it needs to ingest the NAR In your case, you probably don't do lots of stats for .narinfo, but want to often seek around in the same store path. That's quite cheap after the first request. | 09:20:51 |
| flokli | We could add support for others too, using the same castore storage. It's mostly a question of restructuring the same components with a different config, and I didn't have a need for it. | 09:21:52 |
| flokli | I'm using this in layered approaches, so I avoid having to download NARs when I do channel bumps while travelling in places with shitty connectivity. Cause my local nar-bridge can make use of the castore dedup it can accumulate locally. | 09:22:51 |
| pveierland | Do you know the ratio of castore storage encoding at scale? I.e. how effective is it in storage efficiency | 09:23:25 |
| flokli | There's some synthetic benchmarks, but not for real-world access patterns. | 09:24:06 |
| flokli | It arguably could use expose a bit more metrics. And then we could compare total accumulated nar sizes with on-disk storage. | 09:24:50 |
| flokli | All I know is that this machine (or it's predecessors with the same data) has been up for a year or two, never deleted anything it ever fetched, and now accumulated a TB or two of deduped on disk. | 09:28:51 |
| flokli | Either not enough people are using it, or it dedupes well :-D | 09:29:21 |
| pveierland | Do you know c.n.o total storage size? | 09:29:30 |
| flokli | 500T? 600T? | 09:30:21 |
 hexa |
600T
| 09:30:30 |
