Configure a mdadm RAID5 array across two separate SATA controllers by assembling the device nodes directly, bypassing BIOS-level hardware RAID. This approach treats all drives as independent block devices managed entirely by the Linux kernel software RAID layer.
Understanding the Hardware Topology
When working with motherboards like those featuring the Intel Z270 chipset combined with an ASMedia controller, you are dealing with distinct physical buses. The Intel controller typically handles high-speed NVMe or primary SATA ports, while the ASMedia chip often manages secondary or expansion ports. In a standard UEFI/BIOS environment, these controllers operate independently unless explicitly linked via a proprietary hardware RAID feature. However, for this guide, we assume you want to usemdadm, which is a software solution that ignores the physical separation of the controllers.
The key challenge here is not the logical configuration of the RAID itself, but ensuring that the operating system sees all the target drives as accessible block devices before attempting to assemble the array. Because the controllers are separate, the kernel may assign different naming conventions or initialization times to the disks attached to each chip. It is crucial to verify that all drives intended for the RAID are present and correctly identified in the system before proceeding. You can check this using the lsblk command, which lists all block devices along with their sizes and types. Ensure that the drives connected to the Intel Z270 port and those connected to the ASMedia port are both listed under /dev/sdX or /dev/nvmeXnY depending on the drive type.
Preparing the Drives
Before creating the array, you must ensure that no existing filesystems, partitions, or RAID signatures remain on the target drives. If these drives were previously used in another RAID configuration or formatted with a filesystem, they must be wiped. Use thewipefs command to remove all file system signatures from the drives. For example, if your drives are sdb, sdc, and sdd, you would run:
wipefs -a /dev/sdb
wipefs -a /dev/sdc
wipefs -a /dev/sddmdadm will refuse to create a new array if it detects leftover metadata, which could lead to data corruption or assembly errors. Additionally, ensure that the drives are healthy by checking their SMART status using tools like smartctl. A drive failing at the start of a RAID5 rebuild can compromise the entire array's stability.
Creating the mdadm Array
With the drives prepared, you can now create the RAID5 array. Themdadm utility allows you to specify the level, chunk size, and number of active devices. For a RAID5 array spanning three drives, the command structure is straightforward. Run the following command, replacing the device names with your actual drive identifiers:
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd--level=5 flag specifies RAID5, which provides block-level striping with distributed parity. This configuration allows the array to survive the failure of one drive without data loss. The --raid-devices=3 parameter tells mdadm that three drives will participate in the stripe set. Note that the order of the devices in the command does not strictly matter for the initial creation, but it is good practice to keep them consistent for future reference.
Once the command executes, mdadm will begin synchronizing the parity data across the drives. This process can take several hours depending on the drive capacities and speeds. You can monitor the progress by reading the /proc/mdstat file:
cat /proc/mdstatmd0 which will show the synchronization percentage and estimated time remaining. During this phase, avoid heavy I/O operations on the array to ensure optimal rebuild speed.
Formatting and Mounting
After the array has fully synchronized, you need to format it with a filesystem. Ext4 is a reliable choice for general-purpose storage. Use themkfs.ext4 command to format the new array:
mkfs.ext4 /dev/md0mkdir -p /mnt/raid5
mount /dev/md0 /mnt/raid5/etc/fstab file. Use the UUID of the array rather than the device name to avoid issues if device ordering changes. You can find the UUID using:
blkid /dev/md0/etc/fstab:
UUID=your-uuid-here /mnt/raid5 ext4 defaults,nofail 0 2Configuring mdadm for Persistence
Finally, you must save the array configuration so thatmdadm can automatically assemble it on boot. Run the following command to update the configuration file:
mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.confsudo update-initramfs -umdadm will still recognize and assemble the correct array based on the metadata stored within the drives themselves. For more complex scenarios involving large arrays, refer to our guide on growing a RAID6 array with large drives to understand scalability limits.
Frequently Asked Questions
Can I mix drives of different sizes in a RAID5 array?
Yes, but the usable capacity is limited by the smallest drive in the set. Any excess space on larger drives remains unallocated. It is highly recommended to use identical drives to maximize efficiency and simplify replacement strategies.What happens if one drive fails during the rebuild?
RAID5 can tolerate a single drive failure. However, during the rebuild process after a failure, the array is vulnerable. If another drive fails before the rebuild completes, all data is lost. Always have backups before performing any RAID maintenance.Does the position of the drives matter between Intel and ASMedia controllers?
No, the logical position in themdadm array does not depend on which physical controller the drive is plugged into. mdadm uses unique identifiers (UUIDs) stored on the drives to assemble the array, making the physical connection irrelevant to the software logic.
How do I check the health of the array after setup?
Use themdadm --detail /dev/md0 command to view detailed status information. Look for the "State" field, which should read "clean" or "active." Also, check for any degraded states or failed devices in the output.