No, there is no supported in-place conversion from a linear mdadm array to RAID1 — even if the data currently occupies less space than a single member disk. The only safe path is to copy the data out, rebuild the array as RAID1, and copy it back.
Why the Conversion Is Impossible
The two layouts are fundamentally different at the block level. A linear array simply concatenates its members: the first disk's address range is followed by the second disk's, and so on. RAID1, by contrast, writes every logical block to all members simultaneously, so each mirror holds a complete copy of the entire array.
Reshaping between these layouts would require mdadm to relocate filesystem blocks — moving data that currently lives on the second member onto the free regions of the first member before mirroring can begin. mdadm does not work at the filesystem level. It understands block mappings and metadata, not which filesystem blocks are allocated. This is why the --grow implementation explicitly rejects linear arrays with a message stating that only --add is supported for LINEAR and other grow options are not meaningful.
This is also why the "my array is less than half full" intuition doesn't help. A filesystem that is 40% full can still have allocated blocks scattered across both members of the concatenation. Shrinking the filesystem first doesn't change anything either — it's a filesystem-level operation and does not grant mdadm any new reshape capability.
A Note on Kernel Support
The premise that linear mode vanished from the kernel deserves a correction. The md-linear module was indeed removed at one point, but it was later reintroduced upstream. Whether your kernel supports it depends on the version and distribution configuration. If your kernel does include it, the good news is that you can still mount and read the original array — which is exactly what you need for the migration. Reintroduction, however, does not mean an in-place conversion is now possible; the mdadm limitation stands regardless.
The Recommended Migration Path
Because there is no shortcut, plan for a full backup-and-restore. The exact procedure depends on what hardware you have available:
If you have spare disks
- Create a new RAID1 array from the spare disks with
mdadm --create --level=1. - Make a filesystem on it, mount both arrays, and copy the data across.
- Verify the copy (checksums or a file-count comparison are prudent).
- Stop and dismantle the old linear array, then repurpose those disks — for example, add them as additional mirrors to the new array or use them elsewhere.
This is the safest approach because the original data remains untouched until you have confirmed the new copy is good.
If you only have the original disks
- Back up the entire array to external storage — a second machine, an external drive large enough, or a series of tar/rsync archives.
- Verify the backup by test-restoring a sample.
- Stop the array with
mdadm --stopand wipe the old metadata from each member withmdadm --zero-superblock. - Create the new RAID1 array from the disks, create a filesystem, and restore the data.
What Not to Do
A tempting shortcut circulates online: create RAID1 metadata directly on the existing members using mdadm --create --assume-clean. Do not do this. The --assume-clean flag tells mdadm to skip the initial synchronization, but creating RAID1 metadata does not rearrange the existing filesystem into the mirror layout. The data from the second member of the linear concatenation sits at block offsets that RAID1 interprets completely differently, so the result is typically an unusable or corrupted filesystem. Worse, if a mirror resynchronization ever runs afterward, it will overwrite one member with the other — destroying whatever data remained from the old layout. There is no flag or trick that makes this safe.
Prevention and Planning
If you are currently running a linear array because you needed to combine disks of different sizes, consider whether RAID1 (for redundancy) or a filesystem with built-in volume management — such as Btrfs or ZFS — better fits your needs going forward. Filesystems like Btrfs can add and remove devices and rebalance data online, avoiding exactly this kind of frozen-layout migration in the future. Whatever you choose, keep verified backups: RAID1 protects against a single disk failure, not against accidental deletion, corruption, or controller faults.
Frequently Asked Questions
Can I shrink the filesystem first and then convert to RAID1?
No. Shrinking the filesystem frees space but does not consolidate all data onto one member, and mdadm's grow code does not support linear-to-RAID1 reshaping at all. The data must be copied out and restored.
Does the newer kernel's restored linear support change anything?
Only in one helpful way: a kernel that includes the reintroduced linear module can still mount your existing array so you can copy data off it. It does not enable any in-place conversion.
Is --assume-clean a valid workaround?
No. It only skips the initial mirror sync; it does not transform the block layout. Data from the second member of the linear array will be inaccessible, and a later resync can destroy the remaining data permanently.
How long will the migration take?
Budget for two full data copies: one backup (or copy to spare disks) and one restore. On spinning disks, expect roughly the time to read and write the full dataset twice, plus array build time.
Can I add more disks to a RAID1 array later?
Yes. mdadm --add works on RAID1 arrays, and mdadm will sync the new mirror member. This is one reason rebuilding as RAID1 is a good long-term choice over staying linear.