SupremeRAID™ Linux Driver 2.0.0 Release Notes, Software, and Documentation
SupremeRAID™ Linux Driver 2.0.0 Release Notes, Software, and Documentation
SupremeRAID™ Linux Driver 2.0.0 Release Notes, Software, and Documentation
Date:12/3/25
Important Notes
The Linux driver 2.0.0 requires a V2 license key. Please contact your Graid sales representative to obtain one.
The array created with the 1.x driver can be upgraded to 2.0.0 without losing data or configuration, and it will benefit from the performance improvements introduced in the 2.0.0 driver. However, upgrading from a 1.x driver to 2.0.0 requires updating to the latest 1.7.2 release first, and then proceeding with the 2.0.0 upgrade. Please refer to the upgrade procedure below.
openSUSE Leap 15.2 and SLES 15 SP2 are not supported in this release.
Please make sure you have a V2 license available before proceeding.
If your current driver version is earlier than 1.7.2 Update 67 (for example, 1.7.2 Update 61), you must install the 1.7.2 Update 67 driver before upgrading to Driver 2.0. Please follow the steps below:
Step 1: Install the 1.7.2-67 driver package.
Step 2: At this stage, the virtual drives and drive groups may temporarily enter a TRANSFORMING state. Please make sure both the VDs and DGs return to an OPTIMAL state before proceeding.
Step 3:Replace V1 license key with V2 license key.
Step 4: Uninstall the 1.7.2-67 driver package.
Step 5: Run the 2.0.0 SupremeRAID Pre-installer to install the required dependencies.
Step 6: Install the 2.0.0 driver package.
If your current driver version is 1.7.2 Update 67 or later (for example, 1.7.2 Update 70 in the future), please follow the steps below:
Step 1: Confirm that the virtual drives and drive groups are in an OPTIMAL state.
Step 2:Replace V1 license key with V2 license key.
Step 3: Uninstall the existing 1.7.2-67 or later driver package.
Step 4: Run the 2.0.0 SupremeRAID Pre-installer to install the required dependencies.
Step 5: Install the 2.0.0 driver package.
For detailed instructions, please refer to the Upgrading the Software section (Page 68) of the User Guide.
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.