I noticed a strange issue when creating RAID array with mdadm. As far as I see, it creates additional devices of md type. According to the kernel.org documentation, the md device type is Metadisk (RAID) devices.

The metadisk driver is used to span a filesystem across multiple physical disks.

However, this started to happens today on the same host. (I am using a configuration management tool to create a RAID array, but the same happens when I issue the mdadm commands manually.

lsblk output looks like below:

user@host:~$ lsblk
nvme0n1   259:0    0  1.7T  0 disk
└─md0       9:0    0  3.5T  0 raid0
  └─md0p2 259:2    0  1.8T  0 md
xvda      202:0    0   20G  0 disk
└─xvda1   202:1    0   20G  0 part  /
xvdf      202:80   0   20G  0 disk
nvme1n1   259:1    0  1.7T  0 disk
└─md0       9:0    0  3.5T  0 raid0
  └─md0p2 259:2    0  1.8T  0 md

Can someone shed some light? Is this expected? I am seeing this for the first time.

Host is Ubuntu 16.04.6 LTS


Why are these created:

 └─md0p2 259:2    0  1.8T  0 md
  • What exactly is the problem you're seeing in lsblk output? – muru Aug 13 '19 at 11:56
  • 1
    Do you mean the md0p2? That's just a partition that somebody created on the md0 device, just like you would on any other disk device. – TooTea Aug 13 '19 at 12:37
  • @muru the md0p2 devices that are created along. – Alan Kis Aug 13 '19 at 12:41
  • @TooTea md0p2 is not a type PARTITION. It is MD type. No one except me and the NSA doesn't have access to the host. – Alan Kis Aug 13 '19 at 12:42
  • It's still a partition. If you didn't create it yourself, there might have been a partition table lying around on one of the component devices and that partition table is now seen through the raid device. That sounds likely given that the size of the partition looks very close to the size of the component device. – TooTea Aug 13 '19 at 12:57

When a block device is added to the system, the kernel attempts to parse any partition table that may exist on the device, and if successful, will add block devices for the partitions it thinks exists because of what it read in the partition table. Note that support for many partition table types can be configured into the kernel, so partition tables from e.g. Solaris and BSD will also be recognized.

It's possible for random data to somehow match what the kernel expects a partition table to look like, causing false partition devices to be created.

lsblk output has a "TYPE" column, but that may or may not be correct; this too may be a best-effort guess. The major device number is a better indication of what type of device it is; refer to /proc/devices to see what numbers correspond to what kernel driver. Here at least the md0p2 major device number is not the same as the md0 major device number, so it's not the md driver that created that device.

Zeroing out the first block helps prevent such misinterpretation of data as a partition table:

# dd if=/dev/zero of=/dev/md0 count=1

Double-check the device you are writing to!

  • 1
    You also need to run partprobe to make the kernel re-detect partitions after you remove the partition table manually using dd (fdisk does that for you automatically). – TooTea Aug 15 '19 at 10:07
  • Also, comparing device major numbers isn't exactly a reliable approach in many situations (such as this one). Major 259 is used to dynamically allocate minors on demand by all kinds of drivers (note how both nvme and the partition have the same major). – TooTea Aug 15 '19 at 10:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.