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 4K optimal 4k random write (up to 5×)
- RAID5/6 degraded 4K random read (up to 2.6×)
- RAID5/6 degraded 4K random write (up to 6×)
- 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.
Testing Environment
- Hardware
- CPU: AMD EPYC 9755 128-Core Processor × 2
- Memory: 32 GB DDR5-6400 RDIMM × 24
- RAID Controller: SR-PAM2-FD32 (A1000)
- NVMe Drives: KIOXIA CM7 3.2 TB × 24
- Software
- OS: Ubuntu 24.04.2 LTS
- Kernel: 6.8.0-62-generic
- SupremeRAID™ Driver Versions:
• 1.7.2 Update 61
• 2.0 Beta - Benchmark Tool: fio-3.40
- RAID Configuration
- One RAID5 group with 24 physical drives
Disclaimer
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.
This guide provides a simple end-to-end workflow to enable SPDK mode and export a VD over NVMe-oF for quick evaluation.
- Prepare the environment
- SupremeRAID™ 2.0 (Linux) with the integrated SPDK feature
- Root access
- Enough contiguous free memory (for configuring hugepages) - recommended additional 8 GiB
- NICs and routes ready for NVMe-oF (TCP or RDMA)
- Install or refresh dependencies: libibverbs1, librdmacm1, libnuma1
- Enable 1 GB hugepages
- Setting default hugepage size to 1G:
- Ubuntu/Debian
sudo sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="default_hugepagesz=1G /' /etc/default/grub
sudo grub-mkconfig -o /boot/efi/EFI/$OS_ID/grub.cfg'
sudo reboot
- RHEL/CentOS/Rocky
sudo grubby --update-kernel=ALL --args="default_hugepagesz=1G"
sudo reboot
- After reboot, make sure default hugepage size is set to 1048576 kB:
sudo grep Hugepagesize /proc/meminfo
- Make sure no 2MB hugepage is allocated on the environment.
echo 0 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
- Allocate hugepages:
echo 8 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
sudo grep Hugetlb /proc/meminfo
- Enable the integrated SPDK service
- Edit
/etc/graid/graid_spdk.conf:[system]
reactor_mask = [0-3]
- Restart to apply:
- 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 enable
graidctl list vd
Note: kernel and SPDK access cannot coexist within the same DG.
- Create an NVMe-oF target
- Example (TCP on port 4420):
graidctl create export_target tcp enp0s1 ipv4 4420 --spdk
- Kernel and SPDK targets cannot share the same IP + port.
- Export a VD (optional 512e for VMware)
- Use
--spdk-512e for 512-byte LBA emulation (required by VMware ESXi):graidctl export vd 0 0 -i 0 --spdk-512e
- Verify from a client
- Discover the target:
nvme discover -t tcp -a <target_ip> -s 4420
- Connect and confirm LBA size:
nvme id-ns -H /dev/nvme0n1 | grep 'Data Size.*(in use)'
- SPDK mode applies to the entire DG (no mixed modes).
- Allocate ≥8 GiB 1 GiB hugepages for stability.
- Reactor cores (
reactor_mask) require a restart to change. - Address conflicts between kernel and SPDK targets are not allowed.
- Coexistence with external SPDK is supported (
spdk_bdev=external). - SPDK path computes parity on GPU; kernel path on CPU.
- UNMAP from VMware ESXi is safely ignored if unsupported by underlying drives.
graidctl edit dg <DG_ID> spdk_bdev enable|disable
graidctl create export_target <tcp|rdma> <interface> <ipv4|ipv6> <svcid> --spdk
graidctl export vd <DG_ID> <VD_ID> -i <target_id> [--spdk-512e]
graidctl ls nt
graidctl list vd
nvme discover -t <tcp|rdma> -a <target_ip> -s <svcid>
nvme id-ns -H /dev/nvmeXnY | grep 'Data Size.*(in use)'
SupremeRAID™ Linux Driver 2.0 Beta Release Notes, Software, and Documentation