21–30 of 60 posts
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?
Entrusting data storage to a vibe coded filesystem seems imprudent.
Is it? :) Ask me anything!
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.
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.
From 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.
Earlier quoted context omitted.
Is it? :) Ask me anything!
Here is my unsolicited advice: 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.
Seems purely vibecoded
there was slop with ai jesus but now gpt image is just a photo with hidden watermark
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