SupremeRAID™ Hybrid is a special SupremeRAID™ Linux 2.0.1 release for systems that require hard disk drive (HDD) capacity with NVMe acceleration. It is not a separate product line such as SupremeRAID™ SE or SupremeRAID™ AE. It uses the same SupremeRAID™ license key as standard SupremeRAID™ and supports only NVIDIA RTX A400, RTX A1000, RTX 2000 Ada, and RTX PRO 2000 GPU cards.
SupremeRAID™ Hybrid extends the SupremeRAID™ management model as follows:
- Linux Multiple Device (MD) RAID provides the HDD capacity and data-protection tier.
- A SupremeRAID™ virtual drive built from NVMe SSDs provides the high-speed cache tier.
- Linux bcache combines the two tiers and presents one accelerated block device, such as
/dev/bcache0, to the host.
This delta guide covers the MD HDD RAID and bcache workflows introduced by the SupremeRAID™ Hybrid special release. For hardware installation, SupremeRAID™ software installation, licensing, controller management, supported GPU cards, and standard NVMe RAID operations, see the SupremeRAID™ Linux User Guide 2.0.1.
bcache and cache terminology
This guide 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.
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.
Management Boundary
graidctl manages the MD RAID lifecycle, but Linux MD performs the HDD RAID I/O. The SupremeRAID™ NVMe virtual drive accelerates the MD virtual drive through bcache; HDDs do not become native SupremeRAID™ physical drives.
The resource model is:
Applications and file systems use /dev/bcacheN. Do not mount, format, or write directly to either component virtual drive after creating a bcache volume.
MD drive groups support the following RAID modes:
An MD drive group supports up to 24 member drives. This release supports up to 96 registered MD physical drives and up to 8 managed MD drive groups per host. RAID5 and RAID6 require the applicable licensed capabilities.
Install the SupremeRAID™ Hybrid 2.0.1 package as a new deployment using the Hybrid installation procedure and installer. Do not install the standard SupremeRAID™ package first. Use the standard SupremeRAID™ Linux User Guide 2.0.1 only for the applicable hardware preparation, licensing, and common SupremeRAID™ procedures.
The host also requires:
- A qualified x86_64 Linux installation listed in the SupremeRAID™ Hybrid 2.0.1 Release Notes.
- One supported SupremeRAID™ GPU card: NVIDIA RTX A400, RTX A1000, RTX 2000 Ada, or RTX PRO 2000.
- The
mdadm utility for Linux MD RAID management. - The Linux bcache kernel module and an accessible
/sys/fs/bcache interface. - The
make-bcache utility. On Ubuntu, install the bcache-tools package. On RHEL-based distributions, obtain the required bcache components through graid-sr-hybrid-preinstaller. - Whole, unpartitioned HDD devices for the MD backing tier. Registration fails if an HDD contains any partition; the user must manually remove all partitions before registering the drive.
- Separate NVMe SSDs for the SupremeRAID™ cache tier.
- Matching block sizes on the MD backing virtual drive and the SupremeRAID™ NVMe cache virtual drive.
Verify the additional dependencies:
$ command -v mdadm
$ sudo modprobe bcache
$ command -v make-bcache
$ test -d /sys/fs/bcache && echo "bcache is ready"
If a required utility or kernel interface is unavailable, install the dependency by following the applicable distribution procedure in Installing SupremeRAID™ Hybrid.
Data Destruction Risk
Creating an MD drive group writes MD metadata to its HDD members. Creating a bcache volume writes bcache metadata to both component virtual drives. Deleting an MD drive group stops the array and wipes its MD superblocks. Back up all required data and verify every device path and resource ID before continuing.
Before registering or using a drive:
- Confirm that the drive does not contain the root file system, a mounted file system, active swap, or required data.
- Confirm that no application, volume manager, file system, or other RAID stack is using it.
- Use
lsblk or an equivalent operating-system tool to confirm that the entire HDD has no partitions. If any partition exists, back up required data, verify the device identity, and manually remove every partition before registration. - Do not reuse an MD or SupremeRAID™ virtual drive that is already part of another bcache volume.
- Use redundant RAID for production data. RAID0 does not tolerate a drive failure.
- Size the MD backing tier for the required usable capacity and protection level. Size the NVMe cache tier for the active working set and write workload.
This section describes a new SupremeRAID™ Hybrid installation on the target Linux distribution families. It does not describe an upgrade, conversion, downgrade, or rollback procedure.
New Installation Requirement
Start with a newly installed, qualified operating system that does not contain another SupremeRAID™ software installation. Use only graid-sr-hybrid-preinstaller and graid-sr-hybrid-installer. Do not substitute packages from a regular SupremeRAID™ release.
For the detailed list of qualified Linux distribution releases and kernel versions, see the SupremeRAID™ Hybrid 2.0.1 Release Notes. Verify the target host against that list before installation.
Obtain the following information before beginning:
The dedicated graid-sr-hybrid-preinstaller requires Internet access to obtain dependencies from the configured operating-system repositories. It is a separate executable and does not require a product-line option such as -pl or --productline.
Install a supported NVIDIA RTX A400, RTX A1000, RTX 2000 Ada, or RTX PRO 2000 SupremeRAID™ GPU card and the NVMe SSDs by following the hardware procedure in the SupremeRAID™ Linux User Guide 2.0.1.
Install a clean, qualified x86_64 operating system. Do not install the standard SupremeRAID™ software package.
Confirm the operating system, architecture, and running kernel:
$ cat /etc/os-release
$ uname -m
$ uname -r
Confirm that the host has Internet access to its approved package repositories and to the SupremeRAID™ Hybrid download location.
Confirm that no HDD or NVMe SSD intended for the new deployment contains required data, mounted file systems, active swap, or active RAID metadata.
Use this procedure for a qualified RHEL-based distribution listed in the release notes.
Complete Common Host Preparation.
Confirm the distribution release and running kernel:
$ cat /etc/redhat-release
$ uname -r
Enable the CodeReady Linux Builder (CRB) repository using the approved procedure for the installed RHEL-based distribution.
Refresh repository metadata:
Install wget, mdadm, and libsmartcols-devel. The libsmartcols-devel package is required to build bcache-tools:
$ sudo dnf install -y wget mdadm libsmartcols-devel
bcache components come from the pre-installer
There is no supported method for downloading the required bcache packages directly on RHEL-based distributions. Do not run dnf install bcache-tools or obtain an unapproved package. The graid-sr-hybrid-preinstaller supplies the required bcache components.
Confirm mdadm. Verify make-bcache after running the Hybrid pre-installer.
Continue with Downloading the Hybrid Packages.
Use this procedure for a qualified Ubuntu release listed in the release notes.
Complete Common Host Preparation.
Confirm the distribution release and running kernel:
$ cat /etc/os-release
$ uname -r
Refresh repository metadata:
Install the regular download and MD utilities, and then install the Hybrid-specific bcache-tools package:
$ sudo apt-get install -y wget mdadm
$ sudo apt-get install -y bcache-tools
Confirm the utilities:
$ command -v mdadm
$ command -v make-bcache
Continue with Downloading the Hybrid Packages.
Download both release-specific executables from the SupremeRAID™ Hybrid 2.0.1 Release Notes:
- The dedicated SupremeRAID™ Hybrid pre-installer.
- The SupremeRAID™ Hybrid installer matching the GPU card.
Download links and MD5 checksums are published in the release notes. Do not substitute the standard SupremeRAID™ pre-installer or installer.
In the commands below, replace [HYBRID_INSTALLER_URL] and [HYBRID_INSTALLER_FILENAME] with the download link and exact filename for your GPU card from the release notes. Keep the downloaded package filenames unchanged.
$ wget https://download.graidtech.com/driver/pre-install/sr-hybrid/graid-sr-hybrid-preinstaller-2.0.1-bcache-nv580-10-x86_64.run
$ wget [HYBRID_INSTALLER_URL]
$ chmod +x graid-sr-hybrid-preinstaller-2.0.1-bcache-nv580-10-x86_64.run [HYBRID_INSTALLER_FILENAME]
Verify both downloaded files before executing them:
$ md5sum graid-sr-hybrid-preinstaller-2.0.1-bcache-nv580-10-x86_64.run
$ md5sum [HYBRID_INSTALLER_FILENAME]
Compare the results with the checksums published in the release notes. Do not proceed if a checksum does not match.
The following procedure applies to the qualified RHEL-based and Ubuntu distributions listed in the release notes. The host must have Internet access so that the pre-installer can download dependencies from the approved operating-system repositories.
Run the dedicated SupremeRAID™ Hybrid pre-installer. Do not add -pl, --productline, or another product-line option.
$ sudo ./graid-sr-hybrid-preinstaller-2.0.1-bcache-nv580-10-x86_64.run
Follow the prompts to install the SupremeRAID™ dependencies, environment settings, and NVIDIA driver.
When prompted to reboot, type Y and press Enter. If the host does not reboot automatically, reboot it manually:
After the host restarts, confirm that the NVIDIA driver loaded and the supported GPU card is available:
Confirm that the operating-system release and kernel did not change from the qualified installation target:
$ cat /etc/os-release
$ uname -r
The published Hybrid pre-installer includes NVIDIA driver 580.173.02.
Load the bcache module and verify the required kernel interface:
$ sudo modprobe bcache
$ test -d /sys/fs/bcache && echo "bcache is ready"
$ command -v make-bcache
$ command -v mdadm
graid-sr-hybrid-preinstaller configures the bcache module to load persistently. After rebooting, do not continue unless /sys/fs/bcache, make-bcache, and mdadm are available.
Run graid-sr-hybrid-installer. The prompts and user workflow are similar to the regular SupremeRAID™ installer, but the executable must be the package published for this Hybrid release.
Start the installer:
$ sudo ./[HYBRID_INSTALLER_FILENAME]
On the Welcome page, select Next and press Enter to display the end-user license agreement.
Use the spacebar to scroll through the agreement. After reviewing it, select Next and press Enter.
Type Accept, press Tab, select Next, and press Enter to accept the agreement.
Confirm that the installer identifies the expected NVIDIA RTX A400, RTX A1000, RTX 2000 Ada, or RTX PRO 2000 GPU card and the SupremeRAID™ Hybrid package. Select Next to continue.
Complete the installation. The installer reboots the system.
After the installation completes, continue with Applying the SupremeRAID™ License.
MD and bcache operations are not available in SupremeRAID™ Management Console. Use graidctl for every MD and bcache lifecycle operation.
Package Selection
Do not substitute the standard SupremeRAID™ 2.0.1 installer. Do not run the Hybrid installer on an existing SupremeRAID™ installation.
SupremeRAID™ Hybrid supports non-interactive pre-installation and license acceptance using the same options as the regular SupremeRAID™ installer:
$ sudo ./graid-sr-hybrid-preinstaller-2.0.1-bcache-nv580-10-x86_64.run --yes
$ sudo ./[HYBRID_INSTALLER_FILENAME] --accept-license
These dependencies supplement the regular SupremeRAID™ manual installation procedure. They do not replace its NVIDIA driver, kernel, DKMS, or other SupremeRAID™ prerequisites.
Install bcache-tools from the approved Ubuntu repositories:
$ sudo apt-get update
$ sudo apt-get install -y bcache-tools
Confirm that the package supplies make-bcache:
Enable the CRB repository using the approved procedure for the installed RHEL-based distribution.
Install libsmartcols-devel, which is required to build bcache-tools:
$ sudo dnf install -y libsmartcols-devel
Run graid-sr-hybrid-preinstaller to obtain the required bcache components. There is no supported method for downloading the bcache packages directly.
Apply the SupremeRAID™ license key associated with the installed GPU card:
$ sudo graidctl apply license [LICENSE_KEY]
SupremeRAID™ Hybrid does not require a separate Hybrid license key.
Complete all checks before creating MD or bcache resources:
$ sudo graidctl version
$ sudo graidctl describe license
$ sudo graidctl list controller
$ sudo graidctl list nvme_drive
$ sudo graidctl list scsi_drive
$ command -v mdadm
$ command -v make-bcache
$ test -d /sys/fs/bcache && echo "bcache is ready"
Verify the following results:
graidctl version reports SupremeRAID™ 2.0.1 version information.- The license state is
APPLIED and the expected RAID capabilities are enabled. - The expected SupremeRAID™ controller and NVMe SSDs are visible.
- The HDDs intended for MD RAID are visible in the SCSI drive list.
mdadm, make-bcache, and /sys/fs/bcache are available.
If any check fails, do not create storage resources. Collect the SupremeRAID™ logs and contact Graid Technical Support.
This example creates:
- An HDD-based MD RAID5 backing tier from
/dev/sdb, /dev/sdc, and /dev/sdd. - A SupremeRAID™ RAID1 NVMe cache tier from
/dev/nvme1n1 and /dev/nvme2n1. - A writeback bcache volume that combines SR DG0/VD0 and MD DG0/VD0.
The IDs assigned on your host can differ. Always obtain them from graidctl rather than assuming the example IDs.
List the host SCSI and NVMe devices:
$ sudo graidctl list scsi_drive
$ sudo graidctl list nvme_drive
Use device serial numbers and capacity to confirm the intended media. In this example, /dev/sdb through /dev/sdd are HDDs and /dev/nvme1n1 through /dev/nvme2n1 are NVMe SSDs.
Confirm that the HDDs do not contain partitions:
$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS /dev/sdb /dev/sdc /dev/sdd
create physical_drive ... -t MD rejects an HDD if any partition exists. If the output lists a partition such as /dev/sdb1, back up any required data, verify the whole-device path and manually remove all partitions before continuing. The registration command does not wipe partitions automatically.
$ sudo graidctl create physical_drive /dev/sdb /dev/sdc /dev/sdd -t MD
$ sudo graidctl list physical_drive -t MD
Record the assigned MD PD IDs. The remaining example commands assume MD PD0, PD1, and PD2.
Create MD DG0 as RAID5:
$ sudo graidctl create drive_group RAID5 0 1 2 -t MD
The operation creates the native Linux MD device and automatically exposes the complete array as MD VD0. Do not run create virtual_drive for an MD drive group.
Verify the drive group and VD0:
$ sudo graidctl list drive_group -t MD
$ sudo graidctl describe drive_group 0 -t MD
$ sudo graidctl list virtual_drive -t MD
$ sudo graidctl describe virtual_drive 0 0 -t MD
Wait for initialization or synchronization to finish before placing production data on the array. Continue only when the MD drive group reports a healthy state and VD0 has a device path such as /dev/md0.
The following example creates SR DG0/VD0 as a 400 GB RAID1 virtual drive:
$ sudo graidctl create physical_drive /dev/nvme1n1 /dev/nvme2n1 -t SR
$ sudo graidctl create drive_group RAID1 0 1 -t SR
$ sudo graidctl create virtual_drive 0 400GB -t SR
$ sudo graidctl list virtual_drive -t SR
If SR PD0 or PD1 is already assigned on the host, substitute the IDs returned during registration. For the complete SR workflow, see Managing Physical Drives, Managing Drive Groups, and Managing Virtual Drives.
The syntax is:
$ sudo graidctl create cache [SR_DG_ID] [SR_VD_ID] [MD_DG_ID] [MD_VD_ID] [flags]
Combine SR DG0/VD0 with MD DG0/VD0:
$ sudo graidctl create cache 0 0 0 0
$ sudo graidctl list cache
With no options, this command creates the volume in writeback mode with a 10% writeback percentage, a 4 KiB block size, and a 2 MiB bucket size. Use the literal list cache command after creation to obtain the assigned cache ID and /dev/bcacheN path and confirm these settings.
The following example uses ext4. Substitute the exact bcache device path returned by list cache:
$ sudo mkfs.ext4 /dev/bcache0
$ sudo mkdir -p /mnt/hybrid-data
$ sudo mount /dev/bcache0 /mnt/hybrid-data
Verify the Device Path
Creating a file system erases existing data on the target. Run sudo graidctl list cache immediately before mkfs and confirm that the selected path is the intended /dev/bcacheN device.
Register one or more supported whole drives:
$ sudo graidctl create physical_drive [DEVICE_PATH]... -t MD
For example:
$ sudo graidctl create physical_drive /dev/sdb /dev/sdc -t MD
Registration inventories the drives for MD management. It does not create an array. Registration is rejected when a device is unsupported, busy, contains any partition or MD metadata, belongs to another managed resource, or hosts the root file system. When partitions are detected, verify the device identity, back up any required data, and manually remove every partition before retrying. The registration command does not wipe partitions automatically.
$ sudo graidctl list physical_drive -t MD
$ sudo graidctl describe physical_drive [PD_ID] -t MD
Use the detailed view to match the PD ID to the expected device path, serial number, capacity, state, and owning drive group before a lifecycle operation.
An MD physical drive can be unregistered only when no managed MD drive group or pending operation references it:
$ sudo graidctl delete physical_drive [PD_ID]... -t MD
For example:
$ sudo graidctl delete physical_drive 0 1 -t MD
Unregistering removes the drive from Graid management. It does not perform secure erase or guarantee removal of data or third-party metadata. If a PD belongs to a managed MD drive group, delete or remove the drive group through the appropriate workflow first.
$ sudo graidctl create drive_group [RAID_MODE] [MD_PD_ID]... -t MD
Examples:
$ sudo graidctl create drive_group RAID1 0 1 -t MD
$ sudo graidctl create drive_group RAID10 2 3 4 5 -t MD
$ sudo graidctl create drive_group RAID6 6 7 8 9 -t MD
An MD drive group is different from a standard SupremeRAID™ drive group:
- It creates a general Linux MD array through
mdadm. - It automatically allocates one MD VD with VD ID 0.
- It uses the entire MD array capacity; additional VDs cannot be created.
- SR-specific controller, journal, initialization, and strip-size options do not apply.
$ sudo graidctl list drive_group -t MD
$ sudo graidctl describe drive_group [MD_DG_ID] -t MD
$ sudo graidctl list virtual_drive -t MD
$ sudo graidctl describe virtual_drive [MD_DG_ID] 0 -t MD
The list and describe output can report member states and synchronization or recovery progress. Do not reboot, remove a member, create a bcache volume, or perform a destructive lifecycle operation while the MD drive group is synchronizing or recovering.
Common drive group states include:
Every managed MD drive group owns exactly one automatically created MD VD0. The MD VD path, normally /dev/mdN, is the backing device selected by create cache.
The following operations are not supported for MD VDs:
- Creating additional MD virtual drives.
- Editing an MD virtual drive independently.
- Deleting an MD virtual drive independently.
Manage VD0 by managing its owning MD drive group.
delete drive_group and remove drive_group have intentionally different effects:
Do Not Substitute These Commands
A general MD drive group created by graidctl rejects inventory-only remove; use destructive delete when you intend to destroy it. Conversely, use remove rather than delete when dismissing an imported MD array that must remain intact.
Delete is destructive and accepts one MD DG ID per invocation.
- Stop application I/O and unmount any file system that uses the MD VD or its bcache device.
- If the MD VD belongs to a bcache volume, delete the bcache volume first.
- Confirm that the MD DG is not synchronizing or recovering.
- Delete the drive group:
$ sudo graidctl delete drive_group [MD_DG_ID] -t MD
For non-interactive execution after independently confirming the target:
$ sudo graidctl delete drive_group [MD_DG_ID] -t MD --confirm-to-delete
Before deletion, the service verifies the native array identity and members and rejects the operation when the array is mounted, active as swap, held by another device, busy, non-idle, non-clean, or different from the recorded configuration. A successful deletion stops the native MD array, wipes MD superblocks from the members, verifies their removal, and returns the registered MD PDs to an unconfigured state.
Permanent Data Loss
delete drive_group ... -t MD destroys the managed MD array and its data. --confirm-to-delete skips the interactive confirmation; it does not relax the server's safety checks.
After deletion, reuse the still-registered MD PDs in a new MD drive group or unregister them with delete physical_drive ... -t MD.
To stop managing an imported or boot MD array without modifying the native array:
$ sudo graidctl remove drive_group [MD_DG_ID] -t MD
This removes the MD DG, its VD, and associated PD records from Graid management. It does not stop the array, wipe member superblocks, or erase its data. Confirm the native MD device and operating-system configuration separately after removal.
This release reports MD member and drive-group health, but MD member replacement is not supported through graidctl. Do not attempt to simulate replacement by unregistering an in-use PD or by altering the native MD membership while it remains under Graid management. Preserve the array and logs, stop risky write activity if redundancy is exhausted, and contact Graid Technical Support for the approved recovery procedure.
Matching Virtual-Drive Block Sizes
The MD backing VD and the SupremeRAID™ NVMe cache VD must use the same block size. Confirm both component VDs before creating the bcache volume; a mismatched pair is not supported.
$ sudo graidctl create cache [SR_DG_ID] [SR_VD_ID] [MD_DG_ID] [MD_VD_ID] [flags]
The first DG/VD pair must identify the SupremeRAID™ NVMe cache VD. The second pair must identify the MD HDD backing VD. The MD VD ID is 0.
Cache modes:
When no options are specified, create cache uses writeback mode, a 10% writeback percentage, a 4 KiB block size, and a 2 MiB bucket size. The block size and bucket size are fixed at 4 KiB and 2 MiB in this release; cache mode and writeback percentage can be edited after creation.
If stale bcache signatures are found, first confirm that neither component belongs to a live or required bcache volume. Use --confirm-wipe only when those signatures can be safely destroyed:
$ sudo graidctl create cache 0 0 0 0 --cache-mode writethrough --confirm-wipe
$ sudo graidctl list cache
The short alias is also supported:
Example output:
CACHE ID SR-DG/VD ID MD-DG/VD ID SIZE DEVICE PATH MODE CACHE STATE DIRTY DATA WRITEBACK % STATE
0 0/0 0/0 5.2 TiB /dev/bcache0 writeback CLEAN 0 B 10% OPTIMAL
Do not power off the host, detach the cache device, or delete either component while DIRTY DATA is greater than 0 B.
Use the cache ID reported by graidctl list cache for each maintenance command.
The short cache alias cch can be used in place of cache where command aliases are accepted.
Use this procedure before deleting or detaching a cache device, and when delete cache is rejected because dirty data remains:
Stop application write I/O to /dev/bcacheN.
Flush file-system buffers:
Start the asynchronous maximum-rate drain:
$ sudo graidctl edit cache [CACHE_ID] max_drain
Monitor the drain. The command returns immediately; it does not wait for dirty data to reach zero:
$ sudo graidctl list cache
Continue only after DIRTY DATA reports 0 B and CACHE STATE reports CLEAN.
max_drain leaves WRITEBACK % set to 0%. If the volume will remain in service after the drain, set the required value from 0 through 40 explicitly, for example:
$ sudo graidctl edit cache [CACHE_ID] writebackpct 10
Before detaching the current cache device, stop application I/O and complete the dirty-data drain procedure. Then detach it and verify the result:
$ sudo graidctl edit cache [CACHE_ID] detach
$ sudo graidctl list cache
To attach an eligible SupremeRAID™ NVMe VD, identify its DG and VD IDs, confirm that its block size matches the MD backing VD, and run:
$ sudo graidctl edit cache [CACHE_ID] attach [SR_DG_ID] [SR_VD_ID]
$ sudo graidctl list cache
Do not format, delete, or reuse a detached cache VD until the detach operation has completed successfully and graidctl list cache confirms the expected component association.
Delete accepts one cache ID per command. It removes the bcache relationship and metadata; it does not delete the component SR or MD drive groups.
Stop all application I/O to /dev/bcacheN.
Flush file-system buffers and unmount the file system:
$ sudo sync
$ sudo umount /mnt/hybrid-data
Confirm the cache ID, component IDs, device path, and dirty-data size:
$ sudo graidctl list cache
If DIRTY DATA is greater than 0 B, drain it before deletion:
$ sudo graidctl edit cache [CACHE_ID] max_drain
$ sudo graidctl list cache
The drain runs asynchronously. Wait until DIRTY DATA reports 0 B and CACHE STATE reports CLEAN.
Delete the bcache volume:
$ sudo graidctl delete cache [CACHE_ID]
Verify that the managed bcache record and /dev/bcacheN path are gone:
$ sudo graidctl list cache
$ test ! -e /dev/bcache0 && echo "bcache device removed"
The deletion safety check rejects a cache volume while dirty data remains. After the cache is clean, deletion detaches and stops the bcache device, unregisters the cache set, and removes bcache signatures from the component VDs.
Preserve the Components on Failure
If deletion fails because dirty data remains, run sudo sync, start max_drain, and monitor DIRTY DATA until it reaches 0 B before retrying. If deletion still fails or the bcache path remains, do not delete, format, mount, or reuse the SR or MD component VDs. Keep I/O stopped, retain the components, collect the graid_server log, and contact Graid Technical Support.
To decommission the entire hybrid volume:
- Stop I/O, run
sync, and unmount /dev/bcacheN. - Delete the bcache volume and verify that
/dev/bcacheN is gone. - Delete the managed MD drive group and verify that its native
/dev/mdN path is gone. - Unregister the unused MD physical drives if they will no longer be managed.
- Delete the SR virtual drive, drive group, and physical drives by following the standard SupremeRAID™ lifecycle.
Never reverse this order. Removing a component before deleting the bcache volume can leave dirty data inaccessible and the bcache configuration incomplete.
- Use
graidctl list drive_group -t MD and graidctl list cache as the primary health checks. - Investigate
Degraded, Missing, Error, Dirty, RESYNC, and RECOVERY states before maintenance. - Do not modify a managed MD array directly with
mdadm. External changes to membership, UUID, state, or device identity can cause managed delete safety checks to reject the configuration. - Keep the host powered on during MD synchronization, recovery, or bcache destaging.
- Always stop I/O and unmount the bcache device before planned shutdown, maintenance, or deletion.
- Keep the SR cache VD and MD backing VD dedicated to one bcache volume.
- Back up application data according to its recovery objectives. Caching and RAID do not replace backups.
The following limitations apply to SupremeRAID™ Hybrid 2.0.1:
- Linux is the only supported operating system for this release.
- MD and bcache lifecycle operations are available only through the
graidctl command-line interface. They are not available in SupremeRAID™ Management Console. - MD member replacement is not available through
graidctl. - An MD drive group exposes one automatic VD0; independent MD VD create, edit, and delete operations are not supported.
- Only general Linux MD arrays created by this release can use destructive managed deletion. Imported arrays use inventory-only removal.
- The writeback percentage is configurable only from 0% through 40%.
max_drain is asynchronous and returns immediately; completion must be monitored through the DIRTY DATA field in graidctl list cache.- A bcache volume cannot be deleted 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.
delete cache accepts one cache ID at a time.
$ sudo graidctl list scsi_drive
$ sudo graidctl list nvme_drive
$ sudo graidctl create physical_drive /dev/sdb /dev/sdc -t MD
$ sudo graidctl list physical_drive -t MD
$ sudo graidctl describe physical_drive 0 -t MD
$ sudo graidctl create drive_group RAID1 0 1 -t MD
$ sudo graidctl list drive_group -t MD
$ sudo graidctl describe drive_group 0 -t MD
$ sudo graidctl list virtual_drive -t MD
$ sudo graidctl describe virtual_drive 0 0 -t MD
$ sudo graidctl create physical_drive /dev/nvme1n1 /dev/nvme2n1 -t SR
$ sudo graidctl create drive_group RAID1 0 1 -t SR
$ sudo graidctl create virtual_drive 0 400GB -t SR
$ sudo graidctl create cache 0 0 0 0
$ sudo graidctl list cache
$ sudo graidctl edit cache 0 cachemode writethrough
$ sudo graidctl edit cache 0 writebackpct 10
$ sudo sync
$ sudo graidctl edit cache 0 max_drain
$ sudo graidctl edit cache 0 detach
$ sudo graidctl edit cache 0 attach 0 0
$ sudo graidctl delete cache 0
$ sudo graidctl delete drive_group 0 -t MD
$ sudo graidctl delete physical_drive 0 1 -t MD
$ sudo graidctl remove drive_group 0 -t MD
SupremeRAID™ Hybrid Linux User Guide 2.0.1