Seems purely vibecoded
Show HN: ZeroFS – A log-structured filesystem for S3
11–20 of 60 posts
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#12See 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.
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#13See 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…
s3fs doesn't provide posix semantics. It's good enough™ for some uses, but not comparable to what this one is ostensibly providing.
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#14From the docs:
> ZeroFS fetches object data in 128 KiB parts
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.
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#15Entrusting data storage to a vibe coded filesystem seems imprudent.
Is it? :)
Ask me anything!
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#16How 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.
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#17From the docs: > ZeroFS fetches object data in 128 KiB parts 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.
[dead]
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#18From the docs: > ZeroFS fetches object data in 128 KiB parts 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.
Especially that the “one fetch” is who knows how many reads and retries under the hood.
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#19Re: Show HN: ZeroFS – A log-structured filesystem for S3
#20I’ve seen things like this before; your key differentiator needs to be efficiency and safety compared to other options.