HN

Comments (51)

• Menu

  rockwotj
  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
• Menu

  dangoodmanUT
  If you actually bench it locally (local S3, actually writes to disk for "staged" operations), ZeroFS performs horrifically. Ceph blows it out of the water. I don't have the exact numbers, but when I was building a toy CoW distributed block device and filesystem I did a perf matrix, and ZeroFS (even with an hour of codex tuning it) was never within the same 1 or 2 orders of magnitude perf-wise.Sure, Ceph isn't "S3-backed", but when you're talking about an actual filesystem or block device (the thing that does lots of small-IO), you care more about io-perf than sequential.Large sequential jobs that everyone is targeting now (ie AI workloads) can use s3 directly just fine, because they don't have decades of code built on top of the filesystem.
• Menu

  coxley
  From the docs:> ZeroFS fetches object data in 128 KiB partsRead/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.
• Menu

  tribal808
  I’ve seen things like this before; your key differentiator needs to be efficiency and safety compared to other options.
• Menu

  dan_sbl
  > The test suites run in public CI.> Each card links to the CI pipeline.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.
• Menu

  abtinf
  Entrusting data storage to a vibe coded filesystem seems imprudent.
• rapatel0
  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
• dijksterhuis
  previous Show HNs- https://news.ycombinator.com/item?id=48496242 -- 11 points | 20 days ago | 7 comments- https://news.ycombinator.com/item?id=45174724 -- 64 points | 9 months ago | 40 commentsblog post 3 days ago: https://news.ycombinator.com/item?id=48712122
• gdevenyi
  There is some kind of advertising push for this going on. I got Twitter ads for this repo.
• Menu

  preetham_rangu
  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.
• jbverschoor
  I’m more interested in a generic (offline) caching layer for example SMB or NFS. Preferably with doing conflict resolution like Dropbox
• nyc_pizzadev
  Worth mentioning FiberFS: https://fiberfs.io/I believe it just recently launched.
• Menu

  ChocolateGod
  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?
• Menu

  tmach32
  See also: JuiceFS, S3FS, and quite a few others.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.
• anon
  undefined
• Menu

  iamalizaidi
  Seems purely vibecoded
• Menu

  chillfox
  I don’t get why they went for NFSv3, v4 is quite old and I can’t think of any reason why you would choose v3 over v4.
• Menu

  abtinf
  Why does this landing page load js from merklemap.com?
• amelius
  That name makes it sound like your files end up in /dev/null.
• Menu

  sqquima
  So, can I run this on top of RustFS? And RustFS on top of this?
• breckognize
  Under the hood, S3's storage nodes are also built on a log-structured file system: https://cdn.amazon.science/77/5e/4a7c238f4ce890efdc325df8326...(Not posix compliant because it doesn't need to be.)
• aniketsaini777
  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.