Getting Started with mdadm: Installation and Basic Concepts
When Linux first embraced the software RAID driver, the community relied on a tool called raidtools. That package, while pioneering, grew cumbersome as systems expanded. Its dependency on an often hard‑to‑maintain /etc/raidtab and a limited set of features made day‑to‑day administration noisy and error‑prone. By 2001, a new player entered the scene: mdadm, short for “multiple devices admin.” Developed by Neil Brown of the University of New South Wales, mdadm offered a clean, command‑line interface that let administrators create, assemble, and maintain RAID arrays without writing any configuration files upfront. The first stable release, version 1.0.1, quickly found favor on the Linux‑raid mailing list and has since become the de‑facto tool for software RAID.
Installing mdadm is straightforward. On Debian or Ubuntu you can pull it straight from the package manager: apt-get install mdadm. Red Hat‑based distributions use yum install mdadm or dnf install mdadm. If you prefer compiling from source, download the latest tarball from the official repository at https://mdadm.sourceforge.net/. Once extracted, a simple make and make install sequence will drop the mdadm binary into /usr/sbin and install the man pages in the usual location. The command line is intentionally lean; every option you use is visible in man mdadm, and the tool provides helpful aliases that shorten the syntax without sacrificing clarity.
Before diving into array creation, it’s useful to understand the four primary modes that mdadm operates in. Create builds a new array from scratch, Assemble brings an existing array online, Manage lets you add or remove devices while an array is running, and Monitor watches arrays for failures and can trigger notifications or automated recovery actions. A fifth “Misc” category contains housekeeping options that affect mdadm globally but do not belong to a specific operational mode.
One of the key advantages of mdadm is its independence from a mandatory configuration file. While you can use /etc/mdadm.conf to persist array definitions across reboots, the tool does not require it to operate. This design choice simplifies the initial setup and keeps the command line the central point of control. When you create an array with mdadm --create, the kernel writes a superblock on each participating disk that records the array’s UUID, chunk size, level, and other metadata. The kernel later consults this information to reconstruct arrays automatically, so even if /etc/mdadm.conf is missing, the array can still be assembled by providing the device list on the command line.
Although mdadm is powerful on its own, integrating it into a system’s boot sequence or a monitoring framework often calls for a configuration file. The file’s syntax is terse compared to raidtools’ /etc/raidtab. Each line starts with either DEVICE or ARRAY and is followed by a list of arguments. The DEVICE directive tells mdadm which block devices are candidates for array membership. The ARRAY directive lists an array’s path, level, member devices, and optional metadata such as UUID and spare groups. For many administrators, a minimal file containing only the ARRAY lines generated by mdadm --detail --scan is sufficient.
In summary, mdadm’s installation is trivial, its command set is coherent, and it offers a flexible approach to configuration. By keeping array metadata on the disks themselves, mdadm avoids the pitfalls that plagued earlier tools, while still giving administrators the choice to persist definitions in /etc/mdadm.conf if they wish. The next section walks through the practical steps of building and maintaining RAID arrays with this modern tool.
Building and Maintaining RAID Arrays with mdadm
Creating a RAID array with mdadm is a matter of specifying the target device, the desired RAID level, the number of disks, and the list of member devices. The --create subcommand accepts a concise syntax that is easy to read and type. For instance, the following command creates a RAID‑0 array named /dev/md0 that uses the first partitions of two disks:
The --level flag accepts numeric values 0, 1, 4, 5, and the keyword linear for a linear configuration. The --raid-devices option simply indicates how many disks will participate. The short form, -l and -n, is equally valid, so experienced users often type mdadm -Cv /dev/md0 -l0 -n2 /dev/sdb1 /dev/sdc1. Each command prints progress, the chosen chunk size (default 64 KiB), and a final confirmation that the array is online.
Chunk size is an important parameter for RAID‑5 and RAID‑6 arrays, where it affects performance and rebuild speed. The --chunk (or -c) option lets you override the default. If you anticipate heavy write workloads, a larger chunk may reduce metadata overhead. Conversely, small chunks improve random I/O but can slow linear scans. In the example above, a chunk size of 128 KiB is chosen with -c128. This value will be stored in each device’s superblock, ensuring that any future assembly uses the same configuration.
Large arrays benefit from shell expansions that avoid repetitive typing. For a five‑disk RAID‑5, you can write:
The braces expand to /dev/sda1 through /dev/sde1, and the -l5 and -n5 flags declare a RAID‑5 level with five disks. The array’s layout defaults to left‑symmetric parity, which balances the parity across all disks. If you need a different layout, specify --layout=left-join or right-join accordingly.
When a running array needs a change - say a failed disk or an added spare - mdadm’s Manage mode comes into play. The --add option appends a device to a live array:
Removing a disk is slightly more involved because the kernel must first mark it as failed before the device is detached. Two options accomplish this: --fail and --remove. The sequence below mirrors the traditional raidtools approach of raidsetfaulty followed by raidhotremove:
Both actions can be combined into a single command line, making it convenient to recover from a disk replacement in one go. Always check the array’s status after any modification with mdadm --detail /dev/md0. The output lists each member’s state, its role in the array, and any pending events. Keeping an eye on the status helps catch silent failures before they cascade into data loss.
For administrators who prefer a declarative approach, /etc/mdadm.conf can be generated automatically. Run mdadm --detail --scan after creating or updating arrays; the command outputs lines like:
Copy the resulting lines into the configuration file and add a DEVICE line that covers all potential array members. When the system boots, mdadm will parse the file, locate the superblocks, and bring the arrays online automatically. Even if the configuration file is missing, the kernel still reads the superblocks, so you can assemble an array simply by listing its disks on the command line.
MDadm’s flexibility extends to legacy support through its Build mode, which re‑configures older arrays that use a different superblock format. While this mode is rarely needed in new installations, it can be invaluable when upgrading a system that still runs an older kernel or driver.
Beyond basic array management, mdadm supports advanced features like chunk resizing, parity layout changes, and even hardware-assisted array verification. These options can be explored in man mdadm or by consulting the online documentation at https://mdadm.sourceforge.net/mdadm.html. By mastering the core commands and understanding how mdadm stores metadata on disks, administrators gain fine‑grained control over their RAID configurations and can respond swiftly to hardware failures or performance bottlenecks.
Keeping an Eye on Your Arrays: Monitoring and Alerts
Software RAID arrays are dynamic; disks can fail, write errors can creep in, and environmental changes can affect performance. To mitigate these risks, mdadm offers a dedicated Monitor mode that runs as a background daemon and watches arrays for critical events. The core of this functionality is the --monitor flag, which can be invoked with a polling interval and a notification address:
The --delay option sets the polling period in seconds - 300 s in the example. During each interval, mdadm inspects the superblocks of the listed arrays and logs any state changes. If a disk failure or a major error is detected, the tool automatically sends an e‑mail to the specified address. The e‑mail contains a concise summary of the event, the affected array, and any affected devices.
Because the monitor runs continuously, it’s customary to launch it with nohup or to configure it as a systemd service. Running it under nohup looks like this:
The ampersand puts the process in the background, and nohup detaches it from the terminal so that it keeps running after you log out. On systems that use systemd, create a unit file /etc/systemd/system/mdadm-monitor.service with the following contents:
Enable and start the service with systemctl enable --now mdadm-monitor. This guarantees that the monitor is always running, even after reboots, and that any failure of the daemon itself is automatically recovered.
Beyond email alerts, mdadm’s monitor mode can execute arbitrary commands when a fault is detected. The --exec option passes a script or program that receives the array name, device name, and event type as arguments. This feature is powerful for automating maintenance tasks such as swapping a hot spare, triggering a RAID rebuild, or even re‑booting a node when a critical failure occurs. For example, to attempt a hot replacement when a disk fails, create a script /usr/local/bin/mdadm-failover.sh containing:
Make it executable with chmod +x /usr/local/bin/mdadm-failover.sh and then launch the monitor with:
Because the monitor keeps an eye on all arrays listed in /etc/mdadm.conf when --scan is specified, you can set up a single monitor daemon to watch dozens of arrays without specifying each one explicitly. The command would then be:
Monitoring also plays a key role in shared spare management. With the spare-group keyword in /etc/mdadm.conf, arrays belonging to the same group automatically share a spare pool. When an array in the group experiences a disk failure, the monitor can pull a spare from another array in the same group and hand it over. The configuration might look like:
In this example, /dev/md0 and /dev/md1 share a pool of spare disks defined by the DEVICE line. When the monitor detects a failure on either array, it will automatically remove a spare from one array and assign it to the other, minimizing downtime and reducing the need for manual intervention.
MDadm’s monitoring capabilities, combined with its straightforward configuration and powerful management commands, give administrators a robust toolset for keeping RAID arrays healthy. By setting up a monitoring daemon, automating failover actions, and leveraging spare groups, you can reduce the operational burden and focus on higher‑level tasks. For further details on advanced monitoring options, consult the mdadm man page or the online documentation at https://mdadm.sourceforge.net/mdadm.html.
No comments yet. Be the first to comment!