@makalaaneesh.bsky.social
Hey folks, very nicely written architecture docs! :)
One question: where do you persist the state?
If i want higher durability than local disks, i can use object storage for the buffer, but what about the state?
One question: where do you persist the state?
If i want higher durability than local disks, i can use object storage for the buffer, but what about the state?
November 27, 2025 at 10:54 AM
Hey folks, very nicely written architecture docs! :)
One question: where do you persist the state?
If i want higher durability than local disks, i can use object storage for the buffer, but what about the state?
One question: where do you persist the state?
If i want higher durability than local disks, i can use object storage for the buffer, but what about the state?
Hey @chris.blue pretty cool! trying to understand this better.
So, any other s3 backed FS would just translate IO calls to S3 API calls.
But, ZeroFS uses slateDB, so you get the benefit of batched writes and caches for reads; leading to lesser no. of API calls, and lower cost.
Is that correct?
So, any other s3 backed FS would just translate IO calls to S3 API calls.
But, ZeroFS uses slateDB, so you get the benefit of batched writes and caches for reads; leading to lesser no. of API calls, and lower cost.
Is that correct?
July 15, 2025 at 2:49 AM
Hey @chris.blue pretty cool! trying to understand this better.
So, any other s3 backed FS would just translate IO calls to S3 API calls.
But, ZeroFS uses slateDB, so you get the benefit of batched writes and caches for reads; leading to lesser no. of API calls, and lower cost.
Is that correct?
So, any other s3 backed FS would just translate IO calls to S3 API calls.
But, ZeroFS uses slateDB, so you get the benefit of batched writes and caches for reads; leading to lesser no. of API calls, and lower cost.
Is that correct?