Important Notes
- SupremeRAID™ Hybrid is a special release of SupremeRAID™ Linux 2.0.1. It is not a separate product line such as SupremeRAID™ SE or SupremeRAID™ AE.
- SupremeRAID™ Hybrid uses the same SupremeRAID™ license key as standard SupremeRAID™. This release supports only NVIDIA RTX A400, RTX A1000, RTX 2000 Ada, and RTX PRO 2000 GPU cards.
- SupremeRAID™ Hybrid is supported for new installations only. In-place upgrade, conversion from an existing SupremeRAID™ installation, and downgrade are not supported.
- This release is distributed with the dedicated
graid-sr-hybrid-preinstaller and graid-sr-hybrid-installer executables. The installation workflow is similar to a regular SupremeRAID™ release, but the standard SupremeRAID™ pre-installer and installer must not be substituted. The Hybrid pre-installer does not use a product-line option such as -pl or --productline. Download links and MD5 checksums are provided below.
SupremeRAID™ is designed to deliver high-performance RAID for NVMe SSDs. SupremeRAID™ Hybrid extends the SupremeRAID™ Linux 2.0.1 management model to systems that also require high-capacity hard disk drive (HDD) storage.
In this special release, Linux Multiple Device (MD) RAID provides the HDD capacity and data-protection tier. A SupremeRAID™ virtual drive built from NVMe SSDs provides the cache tier. Linux bcache combines both tiers and exposes an accelerated block device, such as /dev/bcache0, to the operating system and applications.
bcache and cache terminology
This document uses bcache for the Linux technology and the managed accelerated volume. It uses cache for the SupremeRAID™ NVMe cache tier or device, cache attributes such as mode and state, and the literal graidctl ... cache command syntax.
Linux MD performs the HDD RAID I/O. The HDDs do not become native SupremeRAID™ physical drives. graidctl provides the supported management workflow for the MD and bcache resources added by this release.
SupremeRAID™ Hybrid adds graidctl lifecycle management for HDD-backed Linux MD resources:
- Register supported whole, unpartitioned HDD devices as MD physical drives. Registration rejects an HDD if any partition exists and instructs the user to remove the partitions manually.
- List and describe MD physical drives.
- Create MD RAID0, RAID1, RAID5, RAID6, and RAID10 drive groups.
- Automatically expose each MD drive group as one MD virtual drive, VD0.
- Report MD drive-group health, member states, and synchronization or recovery progress.
- Delete a general MD drive group created through
graidctl, including stopping the native array and wiping its MD member superblocks. - Remove an imported MD array from Graid management without stopping or modifying the native Linux MD array.
- Unregister an MD physical drive after it is no longer referenced by a managed MD drive group.
Supported MD RAID member requirements:
The release supports up to 24 members per MD drive group, 96 registered MD physical drives, and 8 managed MD drive groups per host.
SupremeRAID™ Hybrid adds graidctl management for Linux bcache volumes:
- Use a SupremeRAID™ NVMe virtual drive as the cache device for the bcache volume.
- Use MD VD0 as the HDD backing device.
- Create a bcache volume in
writeback, writethrough, writearound, or none mode. - Use the default cache configuration of
writeback mode, 10% writeback percentage, 4 KiB block size, and 2 MiB bucket size when no options are specified. - List the component DG/VD IDs, capacity,
/dev/bcacheN path, cache mode, cache state, dirty-data size, writeback percentage, and overall state. - Change the cache mode or set the writeback percentage from 0% through 40% after creation.
- Start an asynchronous maximum-rate drain, which sets the writeback percentage to 0% and returns immediately while dirty data drains in the background.
- Detach the current SupremeRAID™ NVMe cache VD and attach an eligible SupremeRAID™ NVMe VD to the bcache volume.
- Delete a clean managed bcache volume and remove its bcache relationship and signatures. Deletion is rejected while dirty data remains.
- Remove stale bcache signatures during creation with the explicit
--confirm-wipe option.
The MD backing VD and SupremeRAID™ NVMe cache VD must use matching block sizes. The bcache block size is fixed at 4 KiB, and the bucket size is fixed at 2 MiB.
For a new installation, download graid-sr-hybrid-installer. Its interactive installation workflow is similar to a regular SupremeRAID™ release, but the installer itself is specific to SupremeRAID™ Hybrid. The special release uses the standard SupremeRAID™ license key.
New Installations Only
SupremeRAID™ Hybrid 2.0.1 must be deployed as a new installation. In-place upgrade, conversion from an existing SupremeRAID™ installation, and downgrade are not supported.
Prepare the host as a new SupremeRAID™ deployment and follow the SupremeRAID™ Hybrid installation procedure. Existing SupremeRAID™ systems must not be converted to this special release in place.
Destructive Operations
Creating an MD drive group writes MD metadata to its HDDs. Creating a bcache volume writes metadata to both component VDs. Deleting a managed MD drive group stops the array, wipes member superblocks, and destroys the array's data. Verify every device path and resource ID and maintain a tested backup.
- MD physical-drive registration rejects any HDD that contains one or more partitions. Back up required data and manually remove all partitions from the intended HDD before registering it.
- Applications and file systems must use
/dev/bcacheN, not either component virtual drive. - Stop application I/O and unmount
/dev/bcacheN before deleting a bcache volume or its component resources. - Before deleting or detaching a cache device, run
sudo sync, use graidctl edit cache [CACHE_ID] max_drain, and monitor DIRTY DATA with graidctl list cache until it reaches 0 B. - Delete resources in this order: bcache volume, MD drive group, unused MD physical drives, and then unused SR VD, DG, and PD resources.
remove drive_group ... -t MD is inventory-only and is reserved for imported MD arrays that must remain intact.delete drive_group ... -t MD is destructive and is reserved for general MD arrays created through graidctl.- Do not modify the membership, UUID, metadata, or state of a managed MD array directly with
mdadm. - Do not power off the host while an MD array is synchronizing or recovering or while a bcache volume reports dirty data.
- Linux is the only supported operating system for this release.
- MD and bcache operations are available only through
graidctl; they are not available in SupremeRAID™ Management Console. - MD physical-drive replacement is not available through
graidctl. - Each MD drive group exposes exactly one automatic VD0. Independent create, edit, or delete operations for MD VDs are not supported.
- Destructive managed MD deletion applies to general MD arrays created through this release. Imported MD arrays use inventory-only removal.
- SR-specific drive-group options such as controller selection, journal selection, foreground or background initialization, and strip-size selection do not apply to MD drive groups.
graidctl edit cache ... writebackpct accepts values from 0 through 40.graidctl edit cache ... max_drain starts an asynchronous drain and returns immediately; use graidctl list cache to monitor DIRTY DATA until it reaches 0 B.- Deleting a bcache volume is rejected while dirty data remains.
- The MD backing VD block size must match the SupremeRAID™ NVMe cache VD block size.
- The bcache block size and bucket size are fixed at 4 KiB and 2 MiB.
- A single SR VD or MD VD must not be reused in multiple bcache volumes.
delete cache accepts one cache ID at a time.- If deleting a bcache volume fails or
/dev/bcacheN remains, keep both component VDs intact and stop I/O. Do not format, delete, or reuse either component before the failure is resolved.