Eikon

Kind-of should work :)

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.

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.

Thank you, appreciated!

> 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:

https://www.zerofs.net/docs/high-availability

That's fair advice, thanks.

Is it? :)

Ask me anything!

Thank you for the feedback, the idea behind this was to say "We make claims that are backed by workflows you can verify". I'll improve the phrasing.

Just a self hosted plausible instance :)

It's there! https://www.zerofs.net/docs/kubernetes-csi

Most of the pain here is the typical set of issues people run into trying to make S3 a filesystem as-is, common with S3FS-family approaches.

ZeroFS (https://github.com/Barre/zerofs) is 9P/NFS/NBD over S3 on an LSM. Point stock go-git, or just /usr/bin/git, at a mount and skip the gymnastics. Rename is a metadata op in the keyspace, so you get it atomic on any S3, no Tigris-specific X-Tigris-Rename needed.

Different point on the spectrum, but less square-peg, also most probably much, much faster (it works great on linux-sized repos) :)

> Is this only was S3 or any S3 compliant service?

Any S3 compliant service.

> Does it support any sort of storage tiering ?

Yes, it has a local cache that's populated on reads, but no writeback cache yet.

> Millions of files, Interrupted transfers, Backup Server Reboots, Long-term operation?

Yes, that should work fine!

> I assessed the tool on a CentOS 7 system today. It can't run on older CentOS 6. It will generate core dump.

Perhaps your cpu is too old? The prebuilt binaries require newer CPUs but you can build your own.

> Will ZeroFS support large Filesystem size about 800GB?

Absolutely, and much, much more than that.

Even with journaling, you might need one. ZeroFS [0] almost had a lost+found directory (even with the WAL enabled), because you might have consistency issues between your in-memory state and what was flushed, and especially in what order.

ZeroFS ended up not needing recovery at all through atomic, strictly ordered commits [1], but it was far from trivial (and not just a matter of requiring a WAL).

[0] https://github.com/Barre/ZeroFS

[1] https://github.com/Barre/ZeroFS/blob/main/zerofs/src/fs/writ...

https://github.com/Barre/ZeroFS Should do a great job at this.

It's definitely shared, and can be redundant.

Or ZeroFS which doesn’t require a 3rd party database, just a s3 bucket!

https://github.com/Barre/ZeroFS

SQLite works great with ZeroFS: https://github.com/Barre/ZeroFS

See also: https://github.com/Barre/ZeroFS

Doesn’t require an external database (just a s3 bucket) and is a single binary. A webui is shipping in the next few days.

As of recently (workflows worked for months) I even have part of my CI on actions that fails with [0]

2026-02-27T10:11:51.1425380Z ##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled. 2026-02-27T10:11:56.2331271Z ##[error]The operation was canceled.

I had to disable the workflows.

GitHub support response has been

“ We recommend reviewing the specific job step this occurs at to identify any areas where you can lessen parallel operations and CPU/memory consumption at one time.”

That plus other various issues makes me start to think about alternatives, and it would have never occurred to me one year back.

[0] https://github.com/Barre/ZeroFS/actions/runs/22480743922/job...

I am not sure to understand what this is this achieving compared to just assigning a ip + port per vm?

> Vertically scaling primaries is also a fine choice, just keep that vertical limit in mind.

In practice, outside of extremely marginal use cases, you’ll have a hard time exceeding such a limit. Merklemap [0] hosts a 100B-row, 40TB Postgres database on low-tier commodity hardware and things are more than fine; there are very few use cases where it would be an actual practical limit.

[0] https://www.merklemap.com/

English: https://docs.hetzner.com/general/infrastructure-and-availabi...