I have a RAID 1 array which is in a degraded state and want to add another drive to it.

# mdadm --detail /dev/md1 
        Version : 1.2
  Creation Time : Fri Mar 21 17:23:00 2014
     Raid Level : raid1
     Array Size : 488254464 (465.64 GiB 499.97 GB)
  Used Dev Size : 488254464 (465.64 GiB 499.97 GB)
   Raid Devices : 2
  Total Devices : 1
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Jun  9 00:10:04 2015
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           Name : mars:1  (local to host mars)
           UUID : 3458a3fd:a510d0a7:605d8cd5:9880c31e
         Events : 25816

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       2       0        0        2      removed

I am trying to use an identical drive to the first one, identically formatted to hold the whole size. However, mdadm refuses to add it

# mdadm /dev/md1 --add /dev/sdc1 
mdadm: /dev/sdc1 not large enough to join array

The parted output indicates that the two drives have different sector sizes, but I'm not sure what that is and if it can be rectified. If it can't, what are my options?

# parted /dev/sdb unit s print
Model: ATA SAMSUNG HD502HJ (scsi)
Disk /dev/sdb: 976773168s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start  End         Size        Type     File system  Flags
 1      2048s  976773119s  976771072s  primary  ext4         raid, type=fd

# parted /dev/sdc unit s print
Model: ATA SAMSUNG HD502HJ (scsi)
Disk /dev/sdc: 976771055s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start  End         Size        Type     File system  Flags
 1      2048s  976769023s  976766976s  primary               raid, type=fd
  • Do you have LVM on the RAID, or a filesystem, or something else? Jun 8, 2015 at 23:54
  • The new disk may have come with a stupid host protected area enabled which is why it is reporting a smaller size. Check with sudo hdparm -N /dev/sdc
    – psusi
    Jun 10, 2015 at 14:59

4 Answers 4


976766976 from /dev/sdb is smaller than 976771072 from /dev/sdc.

It's not an identical drive.

  • Well, they are the same model ... mars:~ # hdparm -I /dev/sdb | grep Model Model Number: SAMSUNG HD502HJ mars:~ # hdparm -I /dev/sdc | grep Model Model Number: SAMSUNG HD502HJ Jun 8, 2015 at 21:42

Your new disk is a little over 1MB smaller than the existing one. This may be a different model (despite having the same identification, it might have been manufactured in a different factory, to slightly different specifications), or it might have a few more defective sectors noticed during the factory tests.

On sdb, you have a partition sdb1 which spans over the whole disk, minus 1 sector for the MBR plus unused sectors to align the partition to 1MB (which is recommended for performance). The array spans the whole partition; its size is the size of the partition minus 128MB, which is the reshape area.

The size of sdc, 976771055 sectors, is 17 sectors less than the size of the array 976771072 sectors. Therefore you cannot fit the array on the new disk.

You could make an array with the same data and a smaller reshape area. Since it almost fits, just shaving 2MB off the 128MB would be enough. I don't think it's possible to resize the reshape area on an existing array, so you'd have to back it up, create a new one, and restore the data.

What I would do is to shrink one of the partitions on the array by 2MB.

Anyway, the easiest solution seems to me to create a new RAID-1 array with sdc1 as the sole active volume. If you want to keep the size of the partitions on the array, pass --data-offset=126M to create a reshape area that will make it all fit. Better, create an array spanning the whole partition minus a few MB as a safety margin in case this problem happens again. Then copy all the data from the old array to the new one. If you're making a smaller area, do a file copy instead of a partition copy for the partition you want to shrink, or (if you have multiple partitions) do that partition first and then shrink it. Finally wipe the array on sdb1, then add sdb1 to the new array.

Alternatively, shrink the content of the existing array so that the last 2MB (at least) are not assigned to any partition, then use mdadm /dev/md1 --grow --size=… to shrink the existing array.

  • I ended up creating a new, slightly smaller, degraded array with /dev/sdc1, copying the data between the two raid arrays and then adding /dev/sdb1 to the new array Jun 9, 2015 at 19:42

The disk has HPA. I have the same disk and removed HPA successfully reclaiming the lost sectors making both drives identical. See https://superuser.com/a/642765

# hdparm -N /dev/sdx
# hdparm -N p976773168 /dev/sdx

Simply create a partition on sdc identical to sdb I know this trick(first make a backup and avoid partition span outside the disk,for example,2 disk 220G sdb 210G sdc,make two partitions under 210G,maybe two identical partition of 199G in this case)

sfdisk -d /dev/sdb > part_table
sfdisk /dev/sdc < part_table

And then retry to add sdc1

  • You would be creating a partition that spans outside the disk. That's a very bad idea. If data is to be written outside the disk, it'll be lost. Jun 9, 2015 at 1:17
  • Even if sdb1 and sdc1 are identical and not take all data of disk?For example disk sdb is 200G sdc 220G,but sdb1 and sdc1 are 199G identical
    – elbarna
    Jun 9, 2015 at 16:27
  • I'm talking about the case of this question, of course. Sure, if the partitions didn't span beyond the end of sdc, that would be safe. But they do so it isn't. Jun 9, 2015 at 16:33
  • I can edit the question with the warning
    – elbarna
    Jun 9, 2015 at 16:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .