SupremeRAID™ Linux Driver 2.0 Beta Release Notes, Software, and Documentation
SupremeRAID™ Linux Driver 2.0 Beta Release Notes, Software, and Documentation
SupremeRAID™ Linux Driver 2.0 Beta Release Notes, Software, and Documentation
Date:10/31/25
Beta Program Disclaimer
The features described in this release are part of the SupremeRAID™ 2.0 Beta Program and are provided for evaluation purposes only. Performance figures, functionality, and compatibility may change before the official release. Participants are encouraged to provide feedback to help us refine and stabilize the final version. Graid Technology Inc. makes no guarantee of production readiness for beta features at this stage.
SupremeRAID™ 2.0 delivers major improvements in RAID5 and RAID6 performance, particularly in random write efficiency and degraded-state performance. Through a redesigned GPU-accelerated parity pipeline and optimized degraded-I/O scheduling, version 2.0 achieves significantly higher throughput and more consistent latency across parity RAID configurations.
RAID5/6 degraded 1M random read throughput (up to 17×)
RAID6 degraded 1M random write throughput (up to 9×)
Info
These enhancements deliver stable performance even during degraded or rebuild states, reducing the impact on live workloads such as AI training, virtualization, and large-scale analytics.
The performance data presented here were collected on SupremeRAID™ PRO (NVIDIA A1000) under controlled laboratory conditions. Actual results may vary depending on hardware configuration, SSD model, and system topology. Performance on other GPUs—such as the T400, 2000 Ada, or future architectures—may differ due to variations in GPU compute capability, memory bandwidth, and system integration factors.
The Linux 2.0 driver introduces an integrated SPDK NVMe-oF target within the Graid management daemon, enabling direct, zero-copy data export from SupremeRAID™ virtual drives to remote clients over NVMe-oF (TCP or RDMA). This feature eliminates the need for an external SPDK instance and significantly reduces I/O latency by bypassing the kernel block layer.
Each Drive Group can now operate in SPDK mode, where its virtual drives are exposed as SPDK bdevs instead of /dev/gdg* devices. These bdevs can be directly exported as NVMe-oF subsystems and optionally configured in 512-byte LBA emulation (512e) mode, ensuring compatibility with VMware ESXi and other environments that require 512-byte logical sectors.
The integrated SPDK target shares the same GPU-accelerated RAID engine as the kernel path but offloads the I/O stack entirely into user space. This enables low-latency data services, simplified deployment, and unified control via graidctl, making it ideal for hypervisor, disaggregated storage, or remote-NVMe use cases.
# At least totally 8 GiB hugepages is recommented for integrated SPDKecho8> /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages# Alternatively, you can allocate hugepages by numa nodes# echo 5 > /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages# echo 3 > /sys/devices/system/node/node1/hugepages/hugepages-1048576kB/nr_hugepages# Make sure the allocation is successfulsudogrep Hugetlb /proc/meminfo
Enable the integrated SPDK service
Edit /etc/graid/graid_spdk.conf:
[system]# Binds SPDK reactors to specific CPU cores to enable the integrated SPDK servicereactor_mask =[0-3]# Optional: reserve memory if external SPDK coexists# mem_size_gb = 6
Restart to apply:
systemctl restart graid
Create PDs, DGs, and VDs
Create or reuse devices normally.
If a DG was created with zero-init, wait until initialization completes before switching to SPDK mode.
Enable SPDK mode
Convert the Drive Group (DG) to SPDK mode; all VDs become SPDK bdevs (no /dev/gdg*).
graidctl edit dg 0 spdk_bdev enablegraidctl list vd
Note: kernel and SPDK access cannot coexist within the same DG.