NoKVA Rust filesystem for AI training and agent workspaces.

Holt-backed metadata, S3-compatible immutable object bodies, FUSE and SDK paths — a self-contained filesystem with no separate database to run.

Architecture

Quick Start

Benchmarks

Self-contained metadata

A path-native metadata engine (Holt) built in. No Redis, TiKV, or external database to operate — you run a filesystem, not a filesystem plus a database.

Atomic checkpoints

Object bytes land first, then metadata publishes atomically as a new generation. Readers see a complete checkpoint or the previous one — never a half-written one.

Built for AI training

~127K metadata ops/s, single-scan directory listing, immutable cacheable blocks, dataset snapshots, and typed watch events — shaped around datasets, checkpoints, and agent workspaces.

Object-backed bodies

File bytes are immutable blocks in S3, RustFS, MinIO, or Ceph RGW. Elastic, cheap, zero-ops byte durability — NoKV owns the namespace.

How it works

A filesystem — not a filesystem plus a database

NoKV owns namespace truth, metadata transactions, snapshots, watches, and object-reference GC. The object store owns byte durability. The metadata engine is built in — no separate Redis, MySQL, or TiKV cluster to run.

Application surface

FUSE · SDK · CLI

Mount it, call the Rust SDK, or drive it from nokv-fs. One namespace, three front doors.

Metadata layer

Holt engine

Path-native inode & dentry metadata in a built-in ART engine — MetadataCommand transactions, snapshots, and typed watches.

Body storage

S3-compatible objects

File bytes are immutable blocks in RustFS, MinIO, Ceph RGW, or AWS S3 — elastic, cheap, zero-ops durability.

Atomic checkpoint publish. Object bytes upload first, then one metadata commit publishes the dentry, inode, and body manifest as a new generation. A crash in between leaves orphan objects for GC — never a corrupt namespace.

Benchmarks

Single-node, measured end to end

Release build, full server + RPC + Holt path, local RustFS backend. Distributed numbers need separate runs.

~127Kmetadata ops/s — create, batched

~1.1 GB/scheckpoint publish — 1 MiB blocks, conc 16

~3,000dataset samples/s — 16 KiB, conc 16

~1.5 KBresident metadata per file

A single directory of 65k entries holds the same throughput — the path-native ART doesn't degrade on big directories.

Comparison

Same skeleton as JuiceFS — different metadata

Object-backed, metadata/data split, FUSE and SDK paths. The difference is the metadata layer and the semantics.

	JuiceFS	NoKV
Metadata engine	rents a general DB (Redis / MySQL / TiKV)	built-in, path-native (Holt)
Checkpoint publish	general POSIX	first-class atomic primitive
Block model	slice + compaction	immutable + new-generation
AI-native primitives	bolted on	snapshots, typed watch, GC floor
POSIX completeness	full	partial (single-node)
Maturity	production, billions of files	young — single-node, no HA yet

Quick start

Running in a handful of commands

# Build the CLI
cargo build --release -p nokvfs-cli --bin nokv-fs
# A local S3 endpoint (RustFS) — bucket `nokv`, dev creds rustfsadmin
rustfs server --address 127.0.0.1:9000 \
  --access-key rustfsadmin --secret-key rustfsadmin ./rustfs-data &
# Initialize, publish an artifact, read it back
nokv-fs --object-backend rustfs init
nokv-fs --object-backend rustfs put-artifact /runs/1/ckpt.bin ./ckpt.bin
nokv-fs --object-backend rustfs cat /runs/1/ckpt.bin > restored.bin
# Mount with FUSE (macOS needs macFUSE)
nokv-fs --object-backend rustfs mount /tmp/nokv-mount

Recognized in the AI-native storage ecosystem

Build on a self-contained filesystem

Apache-2.0. A usable single-node object-backed filesystem today — a distributed metadata layer with Holt as the shard-local state machine next.

Read the architecture →View on GitHub