Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to create RAID1 mirrored disks on already deployed system (CentOS 6.4). I have two disks: source /dev/sda with the OS and /dev/sdb which will be the mirror. The disks are connected from VMware ESXi as virtual disks, they have the same size and thick/thin provisioning.

I'm following this tutorial: http://www.howtoforge.com/how-to-set-up-software-raid1-on-a-running-lvm-system-incl-grub-configuration-centos-5.3

SYSTEM INFO:

/dev/sda size and partitions:

Disk /dev/sda: 96.6 GB, 96636764160 bytes
255 heads, 63 sectors/track, 11748 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00029e34

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          26      204800   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              26       11749    94166016   8e  Linux LVM

/dev/sdb was completely empty, so after copying partition table by:

sfdisk -d /dev/sda | sfisk --force /dev/sdb

and changing the partitions /dev/sdb1 and /dev/sdb2 to Linux Raid Autodetect,

/dev/sdb size and partitions looked like this:

Disk /dev/sdb: 96.6 GB, 96636764160 bytes
255 heads, 63 sectors/track, 11748 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c1935

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          26      204800   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2              26       11749    94166016   fd  Linux raid autodetect

To ensure there are no remains of previous arrays or whatever I zeroed superblock:

mdadm --zero-superblock /dev/sdb1
mdadm --zero-superblock /dev/sdb2

Creating arrays: So when it comes to creating arrays I use the following commands:

[root@testmachine test]# mdadm --create /dev/md1 --level=1 --raid-disks=2 missing /dev/sdb1
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.

and

[root@testmachine test]# mdadm --create /dev/md2 --level=1 --raid-disks=2 missing /dev/sdb2
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

The arrays can be seen:

[root@testmachine test]# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sdb2[1]
      94100352 blocks super 1.2 [2/1] [_U]

md1 : active raid1 sdb1[1]
      204608 blocks super 1.2 [2/1] [_U]

unused devices: <none>

THE PROBLEM: The problem is that the /dev/md2 array has a size of 94100352 blocks, but /dev/sda has slighlty larger size (about 50MB?) - so when I create physical volume with "pvcreate /dev/md2" the sizes of the volumes are different and I can't use "pvmove" hence I can't complete mirroring the LVM volumes.

  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               vg_testmachine
  PV Size               89.80 GiB / not usable 3.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              22989
  Free PE               0
  Allocated PE          22989
  PV UUID               KSqdKU-9ckP-gZ1r-JwYo-QPSE-RFrZ-lAfRBi

  "/dev/md2" is a new physical volume of "89.74 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/md2
  VG Name
  PV Size               89.74 GiB
  Allocatable           NO
  PE Size               0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               LqNUb7-5zsr-kZ7T-L96R-xKjD-OReg-k6BqDV

(NOTE the difference in size)

I'm no expert as it comes to disk blocks etc. Does anyone know what could be the cause of this?

share|improve this question

1 Answer 1

The reason /dev/md2 is smaller than /dev/sda2 is because there is a RAID superblock at the beginning of the partition /dev/sdb2. The superblock contains a unique identifier and also information on the other disks/partitions that make up the array, so the Linux kernel can automatically assemble the array upon boot, even if you change the order of the disks or copy the contents to a comletely new disk. It's a small overhead you pay in exchange for a lot of flexibility.

Of course, it prevents you from just mirroring /dev/sda2 to /dev/sdb2 since the size is different. If you continue reading the article you linked to, you have to create a filesystem in your (degraded) RAID array, copy the files over, change the boot loader to boot from /dev/md1 and mount /dev/md2, and then you can finally attach /dev/sda* as the second disk in your RAID configuration. It is possible, but not for the faint of heart... It's probably quicker, safer and easier to make a backup and re-install with RAID from the start.

share|improve this answer
    
Hello, thanks for the reply, but I've just resolved the problem. Your are right about the superblock, but the mismatched partition was of the LVM type, not the boot partition - it came up all right. The problem with the size mismatch was corrected, when I added the option --metadata=0.90 when creating the arrays - I think with metadata=1.20, which is default, different information is stored which takes more space on the device. So the topic is closed for now I think. –  Ziwi Jul 17 '13 at 13:03
    
The 0.90 metadata will be placed at the end of partition, I think. I remember having trouble with that because I copied a partition with 'dd' to a different disk, and because the new partition was a different size, mdadm couldn't find the superblock because it was seeking from the end, not the beginning. They fixed that with 1.20. But you have been warned :) –  JvO Jul 17 '13 at 13:13
    
Unfortunately I don't really know what to do do preserve metadata 1.20 AND create an array with the same size as original /dev/sdb2. –  Ziwi Jul 17 '13 at 13:40
    
Me neither. I don't think it's possible :( –  JvO Jul 17 '13 at 13:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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