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
[deleted]
Show HN: ZeroFS – A log-structured filesystem for S3
31–40 of 60 posts
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#32The 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 hate it when databases celebrate their performance without synchronous flushing. You should be clear about data loss window (which should be zero for committed transactions by default!) and the flushing interval to persistent storage.
I'm okay if you batch writes, I'm okay if you offer a low-latency mode with less durability, but by being unclear about this it just feels like a scam.
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#33I 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?
> I believe the first version of this required the metadata to be stored on the ZeroFS server, making HA kinda hard.
Metadata has always been in the bucket itself.
For HA, there's now a "replicated mode" if you want automatic failover:
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#34I’ve seen things like this before; your key differentiator needs to be efficiency and safety compared to other options.
OP this is the best advice here.
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.
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#35I’ve seen things like this before; your key differentiator needs to be efficiency and safety compared to other options.
OP this is the best advice here. 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 re…
Thank you, appreciated!
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#36The 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 hate it when databases celebrate their performance without synchronous flushing. You should be clear about data loss window (which should be zero for committed transactions by default!) and the flushing interval to persistent storage. I'm okay if you batch writes, I'm okay if you offer a low-latency mode with less durability, but by being unclear about this it just feels like a scam.
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
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#37The 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 hate it when databases celebrate their performance without synchronous flushing. You should be clear about data loss window (which should be zero for committed transactions by default!) and the flushing interval to persistent storage. I'm okay if you batch writes, I'm okay if you offer a low-latency mode with less durability, but by being unclear about this it just feels like a scam.
ZeroFS aims to be a POSIX filesystem, the semantics here are the standard ones (ext4, xfs behave the same): write() is buffered (that's the batching) and "committed" maps to fsync(), which returns only once data is durable.
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#38I 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.
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#39Earlier quoted context omitted.
I hate it when databases celebrate their performance without synchronous flushing. You should be clear about data loss window (which should be zero for committed transactions by default!) and the flushing interval to persistent storage. I'm okay if you batch writes, I'm okay if you offer a low-latency mode with less durability, but by being unclear about this it just feels like a scam.
ZeroFS aims to be a POSIX filesystem, the semantics here are the standard ones (ext4, xfs behave the same): write() is buffered (that's the batching) and "committed" maps to fsync(), which returns only once data is durable.
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
Re: Show HN: ZeroFS – A log-structured filesystem for S3
#40I 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.
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.