【S3が爆速ストレージに化ける？】ログ構造ファイルシステム「ZeroFS」が凄すぎる

S3をバックエンドとして利用する、ログ構造ファイルシステム「ZeroFS」のご紹介です。S3の特性を活かした設計で、効率的なファイル管理を実現します。

「バイブス（直感）」でコーディングされたファイルシステムにデータストレージを預けるなんて、無謀にしか思えないな。

テストスイートは公開CIで実行されます。

各カードからCIパイプラインへリンクしています。

AIが書いたマーケティングサイトさん、わざわざ詳しく教えてくれてありがとう。おかげで助かったよ！現在メンテナンスされていて、それなりに人気があるオープンソースプロジェクトなら、どこでもCIを公開しているか、テストを簡単に実行できるようにしているものだけどね。

ドキュメントによると：

ZeroFSはオブジェクトデータを128 KiB単位でフェッチします

オブジェクトストレージにおける読み書き操作は、保存されているバイト数よりも「はるかに」コストが高いんだよね。だからS3やGCSへのアクセスを抽象化するようなものは、いつも使うのが怖いんだ。

メタデータのレイテンシに関して、JuiceFSやSeaweedFSと比べてどうなんだろう？LSMツリーのアプローチは興味深いけど、リモートバックエンドのストレージでコンパクション（圧縮）待ちが発生すると、かなり厳しそうな気がするんだけど。

この手のものは以前にも見たことがあるな。他の選択肢と比べて、何が決定的に優れているのか（効率性や安全性など）を明確にする必要があると思う。

最初のバージョンでは、メタデータをZeroFSサーバー上に保存する必要があったから、HA（高可用性）の構築が結構大変だったはず。今はサーバーを停止して同じ設定ファイルで新しいインスタンスを作れば、バケットから既存のメタデータを読み込んでくれるようになったの？

S3にデータを書き込んでサブミリ秒というのは嘘だし、物理的に不可能だよ。ベンチマークを見るとfsyncの時間が計測されていないから、結局はネットワークのレイテンシか、マウント設定次第でのカーネル内ファイル操作のレイテンシを測っているだけだね。

なんでNFSv3にしたのか分からないな。v4だってかなり古いし、今さらv4じゃなくてv3を選ぶ理由なんて思いつかないよ。

その名前だと、ファイルが全部 /dev/null に消えてしまいそうな響きがあるね。