| 12 Feb 2024 |
 Jonas Chevalier | the TL;DR is that if you do chunk deduplication, then recent objects might have chunks stored in Glacier. And Glacier retrieval is super expensive. | 16:09:58 |
 hexa | are the goals listed in the attic readme all realized? | 22:33:33 |
| hexa | or are they still goals? | 22:33:42 |
 Zhaofeng Li | Yes, they are realized. One thing is that scaling can be bottlenecked by the underlying database | 22:35:53 |
| 13 Feb 2024 |
 artemist | On the topic of attic, are there places people suggest hosting the backing objects? I've been using b2 but find it very unreliable and slow | 00:11:32 |
| Zhaofeng Li | I'm using backblaze r2 which is more expensive storage-wise but charges nothing for outbound | 00:12:46 |
| Zhaofeng Li | * I'm using cloudflare r2 which is more expensive storage-wise but charges nothing for outbound | 00:13:11 |
| Zhaofeng Li | (s/backblaze/cloudflare duh) | 00:13:26 |
| artemist | In reply to @zhaofeng:zhaofeng.li
I'm using cloudflare r2 which is more expensive storage-wise but charges nothing for outbound Thanks, I'll look at that soon. For now I'm just moving stuff back to the local disk on my VPS | 00:17:01 |
|  edef joined the room. | 15:04:29 |
| edef | In reply to @zimbatm:numtide.com
the TL;DR is that if you do chunk deduplication, then recent objects might have chunks stored in Glacier. And Glacier retrieval is super expensive. yes, the answer is to just dupe the chunks in that case | 15:04:56 |
| edef | the goal isn't "store every chunk exactly once", that's not an inherent requirement | 15:09:57 |
 flokli | Well, and it only matters if you need to navigate the AWS pricing landscape | 15:10:40 |
| flokli | If we self-host the binary cache, we probably won't add our own billing department | 15:11:04 |
| edef | In reply to @artemist:mildlyfunctional.gay
On the topic of attic, are there places people suggest hosting the backing objects? I've been using b2 but find it very unreliable and slow yeah backblaze is absolute clown shoes, it just be like that | 15:11:20 |
| edef | In reply to @flokli:matrix.org
If we self-host the binary cache, we probably won't add our own billing department i'm afraid disk iops are still finite resources no matter how you slice it | 15:11:44 |
 Julien | In reply to @flokli:matrix.org
If we self-host the binary cache, we probably won't add our own billing department Is this on the table you think ? | 15:12:36 |
| flokli | Ack, but I don't think the disk iops will be the problem, the actual traffic we egress from the bucket is fairly slim | 15:12:44 |
| edef | like, deeply depends what our SLOs are here ofc | 15:12:47 |
 raitobezarius | In reply to @flokli:matrix.org
Ack, but I don't think the disk iops will be the problem, the actual traffic we egress from the bucket is fairly slim 80TB/mo if my memory serve me well | 15:13:13 |
| edef | how much we want to rely on Fastly as frontend cache etc | 15:13:17 |
| raitobezarius | In reply to @flokli:matrix.org
Ack, but I don't think the disk iops will be the problem, the actual traffic we egress from the bucket is fairly slim * 60(80TB/mo if my memory serve me well | 15:13:20 |
| raitobezarius | * 60-80TB/mo if my memory serve me well | 15:13:22 |
| flokli | For now I don't think we can solve both problems, let's solve the bucket problem first | 15:14:01 |
| flokli | Propagating some metadata, and being a bit smarter with the traffic at the CDN level is also something we can tackle, but that requires smarter clients | 15:14:38 |
| 14 Feb 2024 |
| edef | so: flipside to Backblaze | 10:27:55 |
| edef | they'll cover our egress costs if we commit to them, and they are vastly cheaper https://twitter.com/JakeDChampion/status/1757508820689973627 | 10:28:08 |
| edef | and we get free bandwidth to Fastly | 10:28:26 |
| edef | $36k/yr = $3k/mo, and no more bandwidth charges | 10:28:46 |
| 15 Feb 2024 |
| hexa | I have four remote builders. Is there a simple way to have them share their store between each other for substitutiion? | 03:48:49 |
