Arch Linux and Intel RST (“Fake RAID”)
RAID is a common choke point for users installing Linux. This is somewhat due to the fact that the amount of information on the topic is absolutely overwhelming. Information is often conflicting or even entirely out-of-date. Additionally, it can be extremely unnerving to configure storage when one isn’t entirely sure if what they’re doing is correct.
This post aims to serve as a guide for users installing Arch Linux with RAID-1 using Intel Rapid Storage Technology (RST). While basic RAID concepts are beyond the scope of this guide, I will describe appropriate use cases of Intel RST versus other solutions and describe the process of configuring a RAID-1 array.
It is useful to have an understanding of several concepts before proceeding:
Intel Rapid Storage Technology
Intel Rapid Storage Technology, previously known as Intel Matrix RAID, is a feature included on several modern Intel chipsets. This firmware-based RAID (also known as “fake RAID”) is an attractive option because it permits functionality such as disk mirroring without further monetary investment.
Firmware and software RAID differ from hardware RAID in that the array is ultimately managed by the operating system instead of a dedicated controller. The burden of processing is delegated to the host CPU. Additionally, firmware and software RAID do not benefit from features such as battery-backed write caching that are often included on dedicated controllers. As such, Intel RST is not an ideal option for users with critical reliability requirements — but it is a very reasonable choice for home users looking to achieve additional redundancy or performance.
In Linux, the
mdadm (multiple device administrator) utility is considered the industry standard for managing firmware and software RAID. The md driver provides virtual devices that represent disks and partitions on the array. These virtual devices are stored at /dev/md* (or /dev/md/* in the case of named arrays).
Within a RAID, devices may have metadata (also known as a superblock). Metadata is information that describes the structure and state of an array. For purely software-based RAID solutions, md can directly manage the metadata. For firmware-based RAID solutions such as Intel RST, md is also capable of supporting external metadata — metadata managed outside the context of the driver. For arrays with external metadata, md uses the concept of a container to manage a set of devices, and arrays are created within containers.
For more information, refer to the md and
mdadm man pages.
Note: A significant amount of older documentation references
dmraid. This refers to the utility formerly used for managing firmware and software RAID. It is now deprecated;
mdadmshould be used instead.
The Boot Process
As mentioned earlier, firmware-based RAID solutions are ultimately managed by the operating system. Therefore, an existing array must be assembled — that is, identified and mounted — at boot time for md to manage it.
Assembly happens within the initial ramdisk, which is the initial Linux environment mounted by the booting kernel. The initramfs contains any drivers and scripts necessary to make the real root filesystem accessible. The initramfs is compiled via the
mkinitcpio uses the concepts of binaries and hooks when preparing the initramfs. Binaries are simply binaries (with all of their dependencies) to be included in the environment, and hooks are scripts that are executed in a provided order.
udev is the device manager for the Linux kernel. udev handles hardware events (such as addition/removal) with actions defined in rules. Hooks can be utilized to include udev rules in the initramfs that handle the automatic assembly of RAID arrays at boot time.
WARNING: These commands can destroy data if used incorrectly. If you have anything important on any disk connected to the system, ensure you have a backup!
Our primary goals are to create the RAID array, install the operating system, and configure the operating system to assemble the array during boot.
The following example utilizes
mdadm to create a 2-device RAID-1 array named /dev/md/data comprised of /dev/sda and /dev/sdb. You may need to adjust the parameters accordingly to suit the configuration of your system.
Creating the RAID
Note: The RAID can alternatively be created via the Intel RST option ROM— the results are identical.
- Boot into the Arch Linux installer.
lsblkto display your disk tree.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 100G 0 disk
sdb 8:16 0 100G 0 disk
3. Because Intel RST utilizes external metadata, we must first create a container for our array. Create a container named /dev/md/imsm on the target devices using the imsm (Intel Matrix Storage Manager) metadata format.
# mdadm -C /dev/md/imsm --raid-devices=2 --metadata=imsm /dev/sd[ab]
Continue creating array? y
mdadm: container /dev/md/imsm prepared.
4. Create the array named /dev/md/data in the /dev/md/imsm container.
# mdadm -C /dev/md/data --raid-devices=2 --level=1 /dev/md/imsm
mdadm: array /dev/md/data started.
Although most of the installation process is beyond the scope of this guide, there are several key concepts to note.
As described earlier, the md driver provides virtual devices that represent disks and partitions on the array. For example, if you create 2 partitions on /dev/md/data, the partitions may be accessible at /dev/md/data1 and /dev/md/data2. Inspect the output of
ls -lR /dev/md* for the specific virtual devices on your system.
When writing to an assembled array, always reference the virtual device. For example, you must partition /dev/md/data, not /dev/sda or /dev/sdb — and you must format /dev/md/data1, not /dev/sda1 or /dev/sdb1.
Follow the Arch Linux installation guide, omitting the “Initramfs” and “Bootloader” steps. Prior to rebooting, proceed with the following steps.
- Generate /etc/mdadm.conf in preparation of generating the initial ramdisk. This will facilitate automatic RAID assembly during boot.
# mdadm --examine --scan > /etc/mdadm.conf
2. Open /etc/mkinitcpio.conf in your preferred text editor.
/sbin/mdmon to the BINARIES section.
mdmon monitors external metadata and will be automatically executed by udev rules.
mdadm_udev to the HOOKS section between
mdadm_udev is an installation hook that includes
mdadm and the udev rules responsible for RAID assembly in the initramfs.
HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard fsck"
5. Save and exit.
6. Generate the initramfs.
# mkinitcpio -p linux
7. Install the bootloader of your choice.
8. Reboot. The RAID should automatically assemble.
You can view the status of the RAID with
cat /proc/mdstat. For more information, the Linux RAID Wiki is a valuable resource, as are the md and
mdadm man pages.
Please feel free to share your thoughts on this guide, and how it could be improved. My goal here was to concisely present the information I wish I’d known when I began tinkering with RAID on Linux, and I’m hoping it significantly simplifies the installation process for others.
Best of luck!