rockwotj

I have ran a bunch of evals on production use cases where we are using Jev and OpenAI's model isn't close, but I'm hopeful about some of the OSS ones. IDK it's very cheap so I don't really feel like I need to look for an alternative. Why root for OpenAI over Typesafe? Isn't more diversity in the market good?

as someone who has driven by Google data centers in Iowa and Facebook in Oregon, I can report you that I can’t hear anything from them from the roadside.

Sorry for spreading misinformation!

hopefully it was produced by their own inference engine!

but according to Little’s law, if you improve latency, you also improve throughput, right?

If I have the same number of CPU cores and they all can do their work in half the time they can double the number of requests now

9fs is better than NFSv3 but NFSv4 is a different beast and more powerful

Honestly the biggest limitation is its quite a big protocol and can be complicated, but I don’t see any major advantages you could do yourself protocolwise over a custom FUSE thing except for just simplification. In my case I am hoping the kernel client can save me a lot of work of building a good client

> Wouldn't 9fs/plan9fs be more suitable for this use case from my limited understanding though?

Can you elaborate on why? NFS is really a great protocol with a lot of tricks to reduce round trips

author here! Glad you liked the post :)

> Motivation for combining Chorus and SlateDB for NFS

I work on an AI agent (tasklet) and we give every agent a linux machine. Having durable storage that is cheap, fast and multi-tenant is really important for our product. NFS is a great protocol (if complicated), and object storage is just the cheapest. But making it fast and reliable is key.

> other use cases

Any use case for SlateDB that you are willing to pay more for less latency but keep disaggregated storage without another system.

> GCP specific

Actually AWS and Azure zonal storage also support append operations, so I think the approach could be extended to all three major clouds. I don’t have a need for that ATM

> pricing

Probably worth a whole separate blog TBH. It would be cheaper than Kafka but more expensive than just using the built in WAL for SlateDB or OSWALD

Because it’s harder. It’s a stateful protocol and has a lot more features

Nothing wrong with that, but you should remove the “at rest in S3” footnote from the write latency on the frontpage of the website, because that is not what is measured

Yeah in this case the footnote to the write latency specifically says “at rest in S3”, which is what caused me to go look at the source. To be clear I have no problem with the ZeroFS of only flushing on fsync.

I am very excited for object storage first systems like this to leverage low latency zonal storage for write ahead logs to keep the disaggregated storage but greatly reduce write latency. That ends up being more expensive, but is likely a good tradeoff in lots of cases I have seen

The sub-millisecond writes with data in S3 is false and impossible. If you look at the benchmark the fsync is not timed, so this is just the latency of either the network or in kernel file operations depending on the mount settings

Oh of course all deepseek and glm are. Multiple people have seen GLM self report that it is claude, which makes it super obvious.

I think the surprising thing is I expect flash to be a pure distillation and strictly worse quality but clearly it’s more nuanced than that.