Partition Types

Latest revision as of 04:15, 22 February 2015

Arrays are built on top of block devices; typically disks.

This leads to 2 frequent questions:

• Should I use entire device or a partition?
• What partition type?

There is no right answer - you can choose.

[edit] Entire Devices or Partitions

Your editor prefers to use partitions that are slightly smaller than a device. This allows:

• the device has a partition table - no 'partition table not found'
• replacement disks even of the same model are often slightly smaller and making the partition 100Mb smaller than the device allows some tolerance.
• no performance impact

Neil, the md/mdadm author, uses whole disks.

[edit] What Partition Type

If you are using partitions then there 2 choices for MBR partition tables, and only one for GPT:

• 0xDA for non-fs data
• 0xFD for raid autodetect arrays
• 0xFD00 on GPT

(From the mdadm 2.6.8 man-page) When creating partition-based arrays using mdadm and version-1.x superblocks, the partition type should be set to 0xDA (non fs-data). This type selection allows for greater precision since using any other type [RAID auto-detect (0xFD) or a GNU/Linux partition (0x83)], might create problems in the event of array recovery through a live cdrom.

Autodetection was useful before booting an initrd to load kernel modules and set up the real root FS was standard practice. It allowed booting a kernel with root=/dev/md0 with no initrd (with md compiled into the kernel, not as a module). A RAID-root system these days will handle it by adding all needed things to the initrd (kernel modules, mdadm, and config file). All major distros have used initrd booting for years.

For GPT partition tables, the author of gdisk made up some 4-digit partition type codes so users wouldn't have to type the full GPT UUID partition type IDs. They are similar to the MBR-equivalent numbers, but that's only for ease-of-use. The on-disk format stores a 16-byte UUID. Use gdisk's 0xFD00 partition type for RAID partitions on GPT. gdisk doesn't have a 0xDA00 partition type, as the author wasn't aware of the reasons for 0xFD being deprecated on MBR. (The in-kernel auto-starting behaviour might only happen for MBR partitions anyway.)

This post from the gdisk author explains the situation, and warns against tools that set up RAID partitions with the same type UUID as Windows uses for NTFS. You're just asking to have your RAID partitions scribbled over with a fresh NTFS if you do that. (similarly, 0x8300, the code for a Linux filesystem partition, is not recommended.) If you want to set the type to something other than 0xFD00, make up an unused UUID. Do NOT use EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -- "Microsoft Basic Data".

See wikipedia's GPT article for a list of existing standard partition GUIDs.

Linux handles the GPT 0xFD00 type the same way as MBR 0xFD, auto-starting arrays. (checked using partx -u /dev/sdc to re-read the partition table, and also hotplugging a SATA drive.) However, the auto-starting is not done by the Linux kernel, but instead by udev scripts packaged with mdadm (in Ubuntu 14.10 at least). Moving aside /lib/udev/rules.d/64-md-raid-assembly.rules disables the auto-starting of detected md components as devices are discovered. It doesn't appear to check partition IDs at all. (MBR 0xFD partitions were not tested; possibly the kernel would still autostart them if the md module is loaded, without intervention by udev scripts.)

Since Ubuntu's standard desktop live image doesn't include mdadm, booting won't start md devices. Nor will installing mdadm. After that, though, re-discovering partition tables (or physically hotplugging devices with md partitions) WILL cause them to be auto-started (unless the udev script is disabled). Other live boot images presumably behave similarly, as long as they don't have mdadm installed. (your editor suggests copying the package file to your USB boot stick, along with your .bashrc and so on, so you can quickly and easily set up your live environment.)

A system-recovery boot image that wants to ship with mdadm installed should probably disable 64-md-raid-assembly.rules, to ensure nothing gets written to disk when booting from a dvd or USB stick.