Project Status¶

MeshStor CSI is in Technical Preview. The data path works end-to-end and has been exercised against the failure modes documented in Self-Healing and Volume Relocation. The CRD schema and StorageClass parameters may change in backwards-incompatible ways before 1.0.

We have not yet published benchmark numbers of our own. Any performance expectations cited elsewhere in these docs come from internal testing during early development and may shift as the project matures. For the architectural overhead analysis, see Performance.

Stable and unstable surfaces¶

What's coming¶

On the roadmap¶

• Snapshots and clones — planned. Expect a performance penalty at snapshot creation time, but zero per-write overhead afterward. The current MD RAID + GPT data path does not natively support copy-on-write. For volumes with replicaCount ≥ 2, the planned implementation takes a sub-second xfs_freeze for a consistent point, detaches one current RAID member as the snapshot, and adds a fresh member in its place to restore redundancy. For replicaCount = 1 volumes (local-storage mode), the same procedure runs in the opposite order: a fresh member is added and synced first to preserve availability, then a sub-second xfs_freeze captures the consistent point and the newly-added member is detached as the snapshot. In both cases, once the resync completes, subsequent writes carry no per-snapshot overhead — the inverse of most CSIs on the market, which pay the snapshot tax on every write.
• Snapshot export to S3 — planned. Snapshots will be exportable to S3-compatible object storage for off-cluster backup and long-term retention, without depending on a separate backup tool.
• Raw block volumes — planned. The current driver only supports XFS-formatted volumes; raw block mode requires a small change to the CSI volume capability handling.
• Ext4 filesystem — planned. Currently XFS only.
• NVMe-oF cross-transport failover — planned. Automatic failover between transports (RDMA ↔ TCP) when both NVMe-oF paths exist between two nodes, so loss of one transport — a NIC, cable, or switch on a single network — is recovered with a minimal failover window.
• NVMe kernel multipathing — planned. Redundant NVMe-oF paths of the same transport (two RDMA paths or two TCP paths) between two nodes kept active simultaneously, so a single NIC, cable, or switch failure does not take a volume offline.
• Strict allowedTopologies enforcement — planned. The Kubernetes StorageClass allowedTopologies field is not strictly enforced today. MeshStor's scoring algorithm already does a smarter job for most setups — it accounts for RDMA support, free space, network latency, and the subnet pairing rules from the node annotations — but a hard allowedTopologies filter on top of scoring is on the roadmap for operators who need to constrain placement to specific zones or racks.
• Additional Linux distribution support — Ubuntu 26.04 LTS is planned. Ubuntu 24.04 LTS is already supported with the HWE kernel (linux-generic-hwe-24.04, 6.14+); the stock 6.8 GA kernel is not supported. See Compatibility for the currently tested matrix.

Available to paid customers¶

These features are reserved for paid customers.

• Encryption at rest
• Quality of Service — per-volume IOPS and bandwidth limits to isolate noisy neighbors on shared NVMe drives and NVMe-oF links.
• Volume expansion above the size of a single NVMe drive (RAID1→RAID10 reshape). Online expansion currently works only within stripeWidth=1 size.
• Volume expansion when stripeWidth ≥ 2 (RAID10 expansion). Online expansion is supported today only when stripeWidth=1.
• KubeVirt live migration support — implemented as a deliberately fake ReadWriteMany: a controlled multi-attach shim that lets two pods on different nodes hold the same volume during the live-migration window only.
• Enterprise Linux distribution support — OpenShift (RHCOS), SUSE Linux Enterprise Server, SLE Micro, and Talos Linux. See Compatibility.

Not planned¶

• True ReadWriteMany. MeshStor is a block storage driver. RWX is not on the roadmap and not under consideration. If your workload needs real multi-writer access, use a file storage system instead.

How to engage¶

• Source code: github.com/meshstor/meshstor-csi
• Issues and discussion: file an issue against the repository.
• Support expectations: Technical Preview is best-effort. There is no SLA.

What's Next¶

• Comparison — head-to-head against alternatives
• Use Cases — when MeshStor is and isn't the right tool
• Compatibility — Kubernetes, kernel, and distro compatibility