Red Hat Bugzilla – Bug 252123
mdadm should only accepts hard disk partitions of type 0xFD, "Linux raid"
Last modified: 2007-11-30 17:12:13 EST
Description of problem: mdadm accepts hard disk partitions other than of type 0xFD, "Linux raid". Version-Release number of selected component (if applicable): mdadm - v2.6.2 - 21st May 2007 How reproducible: Always. Steps to Reproduce: 1. Create a raid-1 like, "ARRAY /dev/md0 level=raid1 num-devices=3 devices=/dev/sda7,/dev/sdd5,/dev/sdb2" 2. While it is running, remove a member like, "mdadm /dev/md0 -f /dev/sda7 -r /dev/sda7" 3. Suppose /dev/sda8 was of partition type 0x8E which is "Linux LVM" and it was a part of a logical volume. An operator mistakenly executes, "mdadm /dev/md0 -a /dev/sda8" Actual results: The operation cause immedate sync of the /dev/md0 contents to the partition, breaking the logical volume. Expected results: mdadm rejects to add the partition to the /dev/md0 because the /dev/sda8 is not a "Linux raid" partition, so the contents of the logical volume remains safe. Additional info:
That fdisk only prints "Linux Raid" as the partition type for 0xfd is misleading in that the full name is "Linux Raid Autodetect". Linux md raid devices were never intended to be constrained to only partition type 0xfd. With the advent of improved stacked raid array support in the kernel and mdadm, it's in fact impossible to constrain mdadm to a single partition type and support the many ways in which it is used. Instead, mdadm examines the beginning of any partition to see if it already has A) an mdadm device on it or B) one of the common linux filesystems on it. If it does, it asks the operator if they really want to use the device in the array before continuing. It is probably arguable that it should check for lvm superblocks as well, but that's an upstream feature enhancement issue and is likely beyond the scope of what I would want to carry as an additional patch to mdadm. Please send an email about your concerns to the linux-raid@vger.kernel.org mailing list. The author of mdadm reads that list regularly and would likely implement the needed fix, at which point we'll pick it up in an update.