2

Apparently once should always leave a bit of empty space at the end of each raid1 partition. But if we're too late for that, what can be done if a replacement RAID1 drive is slightly smaller than the surviving drive?

Can the array be resized to be smaller?

In this case, hdparm shows:

Model=ST31000524AS, FwRev=JC45, SerialNo=9VPBMQJD CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168

Model=ST1000DM003-1CH162, FwRev=CC44, SerialNo=S1D7LDD7 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168

But fdisk partitioned the older drive at 976760832 blocks and the new one at 976760001 due to a different logical sector size. There is one partition, formatted ext3.

See also swapping out a faulty drive in a raid array with a new one... but WD changed the block size?

Community
  • 1
Bryce
  • 551
  • 5
  • 13

1 Answers1

4

If you can tolerate some downtime for your storage array, you could do something like this:

  • Unmount the filesystem(s) on the existing array. Or remount the filesystem(s) read-only. (The point is to get the filesystem(s) to a quiesent state that is safe to copy.)

  • Create a new, degraded RAID1 array with your new drive, taking care to partition it so as to leave some empty space at the end of the drive (having learned your lesson).

  • Create the necessary filesystem(s) on the new array, then copy over all files from the old array to the new.

  • Remove the old array completely, and add the old disk to the new array. After resync, the new array will no longer be degraded.

  • Update the fstab and the mdadm.conf to reflect the new reality, and put the new array into production (i.e. mount it in the expected place).

Of course, if your existing array contains the root filesystem (or is otherwise essential to the running system), then you will have to schedule some downtime for the server.

Steven Monday
  • 13,019
  • 4
  • 35
  • 45
  • Excellent answer. In the end it turns out I added this drive and mdadm simply accepted it: /dev/sdb1 blocks=976760001 /dev/sdc1 blocks=976760832. The ext3 filesystem must not have quite filled up the original partition, so it all worked out OK. Had there been a greater size difference your technique is wonderful. – Bryce May 11 '13 at 21:20