How to tell mdadm to use a partition as/instead of a block-device

block-devicemdadmpartitionsoftware-raid

I have four 500GB disks which were set up as a Linux Software-RAID 5 volume during the Debian install (next to the system drive which is a SSD). One of the drives (sda) went bad and now I am trying to replace it and I'm experiencing some trouble.

After removing the bad drive from the array in mdadm, I replaced the drive with another 500GB spare drive which came with a new bought PC. The drive had a NTFS partition with Windows on it (had been immediately replaced with a SSD).

First try went (more or less) wrong – NTFS3G saw the partition and I was abled to add the NTFS volume to the array and it started to rebuild. Using NTFS underneath my RAID was definitely not my intention so I stopped the rebuild and started repartitioning the drive.

At first I tried partitioning manually with fdisk (max. size, default values, partition type "fd") – didn't work, mdadm rejected sda1. Quick check with fdisk – Start, Blocknumber and End didn't match – ok, I see the problem.

Second try was to copy the partitioning data from one of the other disks with "sfdisk -d /dev/sdd | sfdisk /dev/sda". I even zeroed the first 512Byte as sfdisk recommended at the end of his comments. Compared the partitioning data – Start, End and number of blocks matched – looks good.

But now mdadm tells me, that /dev/sda1 is no block device and won't let me add it. But it is possible to destroy the partitioning data on /dev/sda and to give mdadm the whole drive and it will rebuild, but this looks somehow wrong now:

 Number   Major   Minor   RaidDevice State
   4       8        0        0      active sync   /dev/sda
   1       8       17        1      active sync   /dev/sdb1
   2       8       33        2      active sync   /dev/sdc1
   3       8       49        3      active sync   /dev/sdd1

And I definitely don't feel completely well about it, when fdisk now finds no partitions on /dev/sda – In the case of a system crash it seems to be a little more tricky to reassemble the array on a different system when the whole drives are used instead of partitions (see also: here).

What did I miss? How can I tell mdadm to use the partition for its RAID? Or would anyone still recommend using the whole drives (and even converting the other ones)? Or does it really make more sense what the debian installer did there (set up partitions over the complete drives to create the RAID out of partitions)?

I hope I didn't give too much text and too many details, but I'm a little cofused now that I did everything like several tutorials recommended and now I'm stumbling upon these basic questions…

Thank you for your help!

Best Answer

First of all, I don't think there's anything wrong with using a complete drive for mdadm. In other words, your setup works now, you won't have any advantage from fiddling with it any further. From the answer you're referring to:

RAID-on-partition has its uses, but when you're using the drives in a pseudo-storage-pool setup, you're sometimes better off using 'whole drive' instead of 'partition' RAID members.

Now if you want to use partitions anyway: What you did the first time was correct, but it looks like the kernel didn't register /dev/sda1. Either the kernel didn't register (just reboot and it'll solve itself) or you used GPT-partitioning for the other drives (which sfdisk doesn't support AFAIK - you just copied the protective MBR). Try again with a tool like gdisk or gparted.

You could remove /dev/sda from the raid (marking as failed, removing it from the array), make a sensible partition layout (if you're using GPT, make sure you use gdisk or the likes), reboot if necessary and add /dev/sda1 to your RAID array.

Related Topic