Skip to content

MeshStor CSI

Distributed block storage for bare-metal Kubernetes — replicated NVMe volumes with no external dependencies, kernel-grade performance and reliability without operating a separate storage cluster.

Origin. MeshStor was designed by engineers who have spent a decade running databases on Kubernetes in production. Reliability targets, latency targets, and recovery behavior were chosen with those workloads in mind from the first commit rather than retrofitted later. Any vector database, AI workload, or stateful application benefits from that rigor; latency-sensitive workloads benefit most.

How It Works

flowchart LR
    A["1. Partition\nlocal NVMe drives\nvia GPT"] --> B["2. Export partitions\nto remote nodes\nvia NVMe-oF"]
    B --> C["3. Assemble\nMD RAID array\non workload side"]
    C --> D["4. Mount XFS\nfilesystem\nto pod"]

The controller selects which nodes should host partitions based on RDMA support, network latency, and available capacity. Each node manages its own partitions, exports, and imports through a reconciliation loop that runs every 10 seconds.

Native NVMe Performance

Volumes are backed by GPT partitions on local NVMe drives, exported to remote nodes using NVMe-oF — over TCP on any IP network, or over RDMA (RoCEv2 on Ethernet, or InfiniBand) when supported. The entire data path stays in the kernel — no userspace proxies, no protocol translation, no copy-out-and-back-in for replication and near-zero CPU tax.

For a layer-by-layer walkthrough of the data path, see Architecture. For an analysis of where the overhead lives, see Performance.

Kernel-Level Replication

Replication uses Linux MD RAID1 and RAID10 — the same subsystem that has protected data in production Linux systems for decades. There is no custom replication protocol to debug or distrust. When a network partition heals or a node returns, MD's resync logic brings the array back to clean state automatically.

For the failure semantics and resync behavior, see Replication and Self-Healing.

Zero External Dependencies

No etcd cluster, no separate storage control plane, no additional agents. MeshStor runs as a single binary deployed as a StatefulSet (controller) and a DaemonSet (node plugin) in your existing Kubernetes cluster. The control plane lives in the same Kubernetes API server you already operate.

For the component breakdown, see Internals.

What's Next

  • Comparison — head-to-head with Longhorn, Mayastor, Rook-Ceph, LINSTOR, and local storage CSIs
  • Architecture — how data flows from pod to disk through the kernel
  • Project Status — Technical Preview maturity statement
  • Installation — deploy MeshStor and create your first volume