How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
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
Read/write operations in object storage are _far more_ expensive than stored bytes. I'm always afraid of anything that abstracts over S3/GCS access specifically for that reason.
I prototyped something like this for fun a long time ago. Treating s3 like a bucket of blocks seemed intuitive way build a scalable filesystem. Arguably ceph and luster are doing something similar except with a seperate metadata servers to serve the hotter content.
I think the critical thing you will need to explain is durability and loss window. Making some guarentees on failure modes would go a long way towards making me believe i can run operations on something like this.
With AI you should be able to do some exhaustive testing both for load, power loss, server loss, etc. Anxious to see the potential results
Been running ZeroFS on a homelab NAS for a couple months, mostly backups. Cold reads hit ~800ms until the block cache warms up, then it's sub-5ms. NBD export mode ended up beating NFS for me, surprisingly.
If one of your goals is to get others to adopt the software, I recommend you redo the marketing page and readme from scratch. Delete them without looking at them again, then hand write the content for them. Once you have the content, you call tell an LLM to format it into a nice landing page, but strictly keep your wording without changes.
Worth noting most production filesystems accumulate correctness via years of adversarial testing and papers like Pillai et al.'s crash-consistency work, not a priori trust. The real test isn't how it was written but whether it survives fsync/power-loss fault injection at scale.
Since you are harnessing the sorcery of AI, have it write really good benchmarks, run tests and comparisons on competitive products, (and publish them), look up common pitfalls, often requested features, run security analysis.
Also with marketing texts, write your self first and then you can ask AI to hone it or give you feedback. AI slopped marketing text is visible from miles and really, really puts people off. Even if the product itself would be fine, there is some much slop slushing around in the pipes at the moment.
I really like this project and want to see it succeed! Don't let naysayers wear you down.
Thanks for being explicit, AI written marketing site. Wouldn't have been able to figure that out! Every currently maintained and reasonably popular open source project either runs CI in public or makes the tests extremely easy to run.
> These are asciinema recordings of real terminal sessions, rendered as text rather than video. Playback caps idle pauses at two seconds and changes nothing else.
Thanks? This sounds like it's the LLM's response to the prompter, not something you should display on the page itself...
I see this all the time in code reviews at work. Extremely verbose comments that teach the clueless author how things work but have no place in the final code: aside from codebase not being a coding tutorial, they are also incredibly specific and would become stale and incorrect in matter of weeks.
I feel bad for actually liking that part now. Capping pauses at 2 seconds would show you where it hung 2+ seconds without wasting your time. Smart I thought.
How does this compare to JuiceFS or SeaweedFS in terms of metadata latency? The LSM tree approach is interesting but compaction pauses on a remote-backed store seem like they could be painful.
I believe the first version of this required the metadata to be stored on the ZeroFS server, making HA kinda hard.
This has changed now that if I stop the server and create a new instance with the same configuration file it'll pickup the existing metadata from the bucket?
Automatic failover sounds nice but what happens to in-flight writes when the primary dies mid-fsync? Does the new leader replay from the same S3 metadata state, or can you lose acknowledged writes in that window?
We have done loads of research into using object storage wherever we can (given how cheap it is compared to SSDs), and so far it seems like making your application object store-aware is a far surer bet than abstracting S3 behind the file system. The behavior is just too different.
I'm more interested in applications that cleverly use object storage, e.g. AutoMQ, which is quite compatible with Kafka APIs but needs no HDDs.
NFSv4 is a hard beast to implement correctly, with a lot of protocol surface (state, compound ops, delegations) for benefits ZeroFS mostly gets through 9P with extensions, over a much simpler protocol: https://www.zerofs.net/docs/9p-extensions. NFSv3 stayed in ZeroFS mostly for client compatibility.
Ran into this with a homegrown S3-backed FUSE thing a while back. Doesn't mean it's bad, vibecoded stuff can still work, but check how they handle partial writes and crash recovery before trusting it with real data.
The page doesn’t load anything for me… I block JS by default, & something that should be informational is hiding it’s content behind scripts for some reason.
The 128 KiB chunk size is an interesting tradeoff point — small enough to avoid wasting bandwidth on partial reads, but you're still paying per-request overhead on S3 (both cost and latency) for anything that reads across many chunks. Curious how ZeroFS handles read-ahead/prefetching for sequential access patterns, since that's usually where these abstractions either save you or quietly rack up request costs. Tools like JuiceFS and SeaweedFS handle this differently (local metadata cache + larger block coalescing) — would be interesting to see a head-to-head on request volume for the same workload.
What actually worries me is recovery. We had an EBS-backed thing corrupt once and restoring from S3 took hours. If your metadata layer gets wedged, how fast are you really getting a volume back online?
