| 20 Jun 2026 |
 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 |
| hexa | Redacted or Malformed Event | 09:30:32 |
| pveierland | Oh. Chunky 👍 | 09:30:35 |
| flokli | It's not a fair comparison, we didn't pipe all store paths to it, we only lazily ingest what's requested. | 09:31:01 |
| flokli | And there's still a bit of fine tuning on the parameters and on-disk format to do. | 09:31:21 |
| flokli | But what's in right now is a good dataset for real-world usage. | 09:31:44 |
| pveierland | Will experiment a bit 👍 Provenance is important since the store for each artifact is tracked during indexing. The ranged read research is for client side file system | 09:44:17 |
| pveierland | * | 09:44:44 |
|  Nikita Mikhailov joined the room. | 12:15:06 |
| 21 Jun 2026 |
 llakala | https://github.com/NixOS/nix/blob/f8bb823a23bf6d62f4c8feb792a77702d7a49fe1/src/libexpr/primops.cc#L3276 | 12:59:08 |
| llakala | might it be more performant to loop twice through the attrs - once calculating the number of attrs that actually exist, and the second time actually copying their values? | 12:59:45 |
| llakala | i say this because this removeAttrs has consistently shown up in my nixpkgs profiling | 13:02:25 |
| llakala | there's a lot of names to remove
removedOrReplacedAttrNames = [
"checkInputs"
"installCheckInputs"
"nativeCheckInputs"
"nativeInstallCheckInputs"
"__contentAddressed"
"__darwinAllowLocalNetworking"
"__impureHostDeps"
"__propagatedImpureHostDeps"
"sandboxProfile"
"propagatedSandboxProfile"
"disallowedReferences"
"disallowedRequisites"
"allowedReferences"
"allowedRequisites"
"allowedImpureDLLs"
];
| 13:02:50 |
