goesZen

Do you use Software Defined Storage (SDS)? Do you do RAID, on Linux? Well, then you might have heard about xinnor's xiRAID. But what exactly is it and where does it differ from open-source stuff that's already out there? We'll have a look.
RAID (Redundant Array of Independent Disks) was traditionally a hardware thing. Specialized controller cards from vendors like Adaptec, Areca et al. were all the craze during the 1990s, when external data silos, like the Micropolis RADION towers, were marketed to prosumer users seeking scalable storage and data protection/redundancy. Here, offload co-processing units took on the task of calculating checksums and coordinating data paths. But the RAID approach has come a long wa since these early days. Main CPUs got much faster, and went multi-core. And while the acceleration co-processor card is an evergreen (see DPUs, for network offloading, in AI workloads), much of the storage RAID workload has shifted to main CPU, for ease of use, finer control and deeper observability.

What's there, open source software defined RAID?

First, there's old and trusty MD Raid (mdraid). It is kernel-based software RAID supporting RAID0/1/5/6/10/etc. is managed via mdadm and has seen recent optimizations (kernels 6.18+) which broght us a lockless bitmap for write-intent tracking, reducing lock contention. It is a general-purpose software RAID that works with NVMe. It is not specifically optimized for NVMe parallelism or vectorized parity though and uses traditional per-stripe locking and scalar parity calculations.

Second, there is SPDK. The work horse under the hood of many current SDS commercial offerings. This open source framework also brings RAID. It has RAID virtual bdev module that combines SPDK block devices (NVMe, AIO, Ceph RBD, etc.) into RAID bdevs. Supports RAID0, Concat, RAID1, and RAID5F (RAID5-like with forward recovery). RAID5F is not as optimized or feature-rich as commercial offerings. SPDK is more DIY.

Enter xiRAID

xiRAID is a high-performance software RAID engine from Xinnor, designed specifically to exploit NVMe/NVMe-oF parallelism and modern CPU vector units. It runs on Linux hosts and presents standard block devices, but its internals are quite different from traditional Linux MD RAID or hardware RAID.

As pure software RAID, it requires no hardware card (so much we already know). When SysOps look for a solution that saves precious hardware lanes, they grab software-only solutions like this one.Especially in NVMe-heavy workloads (HPC, AI training, video production, packet capture, etc.) that's a winner and xinnor claims near-raw performance (~97% of device throughput) even in parity RAID (RAID5/6/7.3) with low CPU load and small memory footprint.

Architecture variants

From an architectural viewpoint, there are two main flavors:

xiRAID Classic (kernel-space)

• Runs as a kernel driver on the host OS.
• Exposes a standard Linux block device (/dev/xi_raid*).
• Managed via a CLI tool xicli (create/delete RAID, add/remove disks, status, etc.).
• Intended for local NVMe or direct-attached storage.
• Interfaces with NVMe devices via the standard Linux NVMe driver stack.

and xiRAID Opus (user-space, more like SPDK offerings)

• Runs in userspace, typically on DPUs or specialized cores.
• Uses SPDK (Storage Performance Development Kit) for NVMe access and I/O polling instead of interrupts.
• Presents storage via virtIO, NVMe-oF (NVMe-oRDMA, NVMe-TCP), etc.
• Designed for disaggregated storage and virtualized environments.
• Data path and NVMe connectivity are handled by SPDK, not the kernel NVMe driver.

Main technical selling points

Lockless data path

Xinnor’s core IP is its “lockless data path”. Traditional software RAID (including Linux MD RAID) often uses per-stripe locks or similar synchronization to prevent concurrent writes to the same stripe from corrupting parity. xiRAID avoids spinlocks and scheduling delays by binding each stripe to a single worker thread: All I/Os touching a given stripe are processed by the same thread. This eliminates the need for explicit locks on stripe metadata. Reduces cacheline bouncing and context switching overhead.

Vectorized parity calculation (AVX/vector registers)

The important parity/checksum calculations (RAID5/6/7.3) are done using SIMD instructions: On x86: AVX2 (256-bit vectors) or similar. On ARM: vector registers (NEON/SVE-style). A single vector operation processes multiple data blocks in parallel for parity generation. Xinnor calls this a “patented RAID calculation engine” that minimizes data movement and maximizes arithmetic intensity.

Finally: I/O parallelization and NUMA awareness

Benchmarks seem to show that xiRAID can saturate PCIe Gen4/5 links and InfiniBand bandwidth when used with Lustre/BeeGFS/IBM Storage Scale. It is designed to exploit massive NVMe parallelism: Many queues per NVMe device. Multiple worker threads, often one per NUMA node or per CPU core.

In sum, xiRAID seems to be a well thought-out, battle-tested and well-supported commercial software RAID solution based on and made for the open source Linux stack.

Based on Linux SDS infrastructure

Despite the custom data path, xiRAID is still a Linux-based SDS component and depends on several standard Linux mechanisms: xiRAID Classic exports a standard Linux block device (/dev/xi_raid*). It plugs into the Linux block layer. It can be layered with device-mapper (LVM, dm-crypt, etc.), though Xinnor docs don’t explicitly mention dm. It’s compatible with POSIX file systems and any application using standard read()/write() or io_uring. The block device abstraction is standard Linux.

xiRAID Classic uses the Linux kernel NVMe driver and appears as a /dev/nvme* device. Management is via xicli CLI and configuration files and very nice proprietary tooling (e.g. xiNAS), but it sits alongside standard Linux tools (lsblk, fdisk, systemd, etc.)
In short, xiRAID is a promising and well-regarded software-defined RAID engine that sits on top of standard Linux NVMe and block infrastructure but replaces the RAID logic with a custom, vectorized, lockless implementation optimized for NVMe parallelism and modern CPUs. It’s not just a front-end to Linux MD RAID and not just SPDK. it’s a separate implementation with its own data path and parity engine. Worth to be checked out on xinnor.io