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
> 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
But this is model behavior and just a public issue tracker which claude code has just without code? I don’t see how it’s any different than https://github.com/anthropics/claude-code for these issues.
I do appreciate that codex is open source generally, but I don’t think it matters for this class of issue as the model is closed still
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
I actually just started doing this by having Fable roleplay as Jeff Dean and to use Codex as Sanjay driving the implementation and have them go back and forth. Works really well and it’s cool to see AI pair program
This seems really great! I am a long time Bazel fan, but it’s not perfect, and I have always thought there was something simpler than bazel that would give a lot of these kinds of benefits. Having something that works for a hybrid rust/typescript codebase would be great.
I encourage you for you dev command to work with frontend setups like vite so it’s unified with backends and still supports HMR
IIRC (it’s been awhile) this was an optimization that was inspired by someone noticing all of Google spent a lot of time in vDSO using https://research.google/pubs/google-wide-profiling-a-continu...
Google generally doesn’t have any (well that I have ever heard of) hard realtime requirements like the high frequency trading or HPC systems do.
I mean I also think this move doesn’t make sense, but I always find these type of comments interesting. Do people think they could do better in Mark’s shoes?
Husband and Father. More @ https://rockwotj.com