| 29 Jul 2021 |
 tomberek | the limitation i'm running into right now is that xz doesn't have a "rsyncable" mode the way gzip and zstd does | 07:02:08 |
 niksnut | It depended on the client having a full list of all the NARs / patches available on the server (which used to be how substitution worked, before the binary cache). There's a paper about it: https://edolstra.github.io/pubs/eupfcdm-cbse2005-final.pdf | 07:09:49 |
| tomberek | I was looking at either a zsync or casync mechanic (zsync is less intrusive to the existing cache structure and requires Range requests; casync requires more requests, but also allows for space savings on the server with cross-package dedup). I have a PoC to measure how much this saves and get some metrics. Thanks for the paper, reading.... | 07:15:47 |
 Vladimír Čunát | I'm not sure if the server-side savings will be feasible in practice for cache.nixos.org. I suspect we'll want to keep the full downloads there anyway. | 07:51:30 |
| tomberek | Vladimír Čunát: that's why i'm leaning toward the zsync-style approach where the full-downloads are kept. Though i'm open to thoughts/ideas. | 08:06:51 |
| Vladimír Čunát | Probably. I'd try the schemes on gzip --rsyncable from NAR instead of plain NARs. (Yes, current cache.nixos.org uses .xz which surely won't work well, but perhaps that won't be such a problem to switch.)
It's an earlier idea but I never got to check the effect experimentally. The point is that on typical rebuilds the majority changes in NAR contents is replacement of pairs of nix-store hashes. One might hope that compression schemes like gzip will squash such differences to fewer positions.
| 08:12:12 |
| Vladimír Čunát | * Probably. I'd try the schemes on gzip --rsyncable from NAR instead of plain NARs. (Yes, current cache.nixos.org uses .xz which surely won't work well, but perhaps that won't be such a problem to switch.)
It's an earlier idea but I never got to check the effect experimentally. The point is that on typical rebuilds the majority of changes in NAR contents is replacement of pairs of nix-store hashes. One might hope that compression schemes like gzip will squash such differences to fewer positions.
| 08:12:24 |
| Vladimír Čunát | I also played with ideas around (forward) error correction, but zsync and similar sounded more realistic. | 08:13:56 |
| tomberek | another annoyance: i don't think libarchive has options to enable rsyncable, but gzip and zstd support it. | 08:17:16 |
| Vladimír Čunát | 🤔 I guess the first step should be to test how much it helps. Perhaps even "manually" on some well-chosen NAR pairs. Perhaps using libzstd directly, there it seems to be in the API at a quick glance, though just as na experimental feature so far. | 08:25:31 |
| Vladimír Čunát | I haven't thought yet if the zstd compression scheme is suitable for this idea (contrary to gzip). | 08:26:22 |
| Vladimír Čunát | * I haven't thought yet if the zstd compression scheme is suitable for this idea (contrary to gzip), but hopefully so. | 08:26:37 |
| tomberek | i did a bit manually.... packages that are close enough to each other can be 50-90% same | 08:26:38 |
| tomberek | large packages are best, as they only change in small areas at a time (blender,firefox,systemd,linux,vim,emacs) | 08:27:52 |
| Vladimír Čunát | And you did these tests on uncompressed NARs, right? | 08:28:57 |
| tomberek | small version bumps are best. If the change is only in self-references it should be picked up as a dup by the new CAS system | 08:29:46 |
| tomberek | i did both uncompressed NARs and "zstd --rsyncable" NARs. | 08:30:13 |
| Vladimír Čunát | I suspect that typically the package version is even the same but some dependencies have changed. | 08:30:37 |
| tomberek | I've convinced myself it would work and be very beneficial in certain cases, but I'm not sure about the cost-benefit in terms of maintaining a new store backend, adopting another format/library, alternatives. | 08:37:01 |
|  stick changed their display name from stick to stick2. | 16:25:14 |
| stick changed their display name from stick2 to stick. | 16:25:54 |
| 30 Jul 2021 |
| Vladimír Čunát | Hmm, my running nixStable daemon with nixUnstable utilities encounters quite some issues. Again: are they considered bugs, i.e. is such a combination meant to be supported? | 08:15:14 |
 Regnat | I’d say these are definitely bugs | 08:22:48 |
|  dramforever joined the room. | 08:32:52 |
| stick changed their display name from stick to stick3. | 10:32:57 |
| stick changed their display name from stick3 to stick. | 10:33:04 |
| stick changed their display name from stick to stick[m]. | 10:35:19 |
| stick changed their display name from stick[m] to stick. | 10:35:45 |
| 1 Aug 2021 |
|  Jamie joined the room. | 08:04:45 |
| Vladimír Čunát | Example:
nix build -f. nixosTests.gnome-xorg --dry-run
error: store path 'xdkj2bfhfdpx8r0k1dny29km3b6yyp9r-vm-test-run-gnome-xorg.drv!out' contains illegal character '!'
| 15:00:40 |
