[Cialug] Replacing failed RAID 1 drive

Zachary Kotlarek zach at kotlarek.com
Tue Sep 30 17:25:04 CDT 2014


On Sep 30, 2014, at 3:07 PM, Rob Cook <rdjcook at gmail.com> wrote:

> I have a CentOS 6.5 box with 2 1.5Tb drives in a RAID 1 with LVM partitions
> on top of that. One of the drives /dev/sdb has failed.
> 
> I've been googling quite a bit and I think that I should be ok following
> this guide:
> 
> http://www.howtoforge.com/replacing_hard_disks_in_a_raid1_array
> 
> Fail then remove the drive from the array, replace with similar or larger
> then recreate. The one question I have is what to do with the LVM
> partitons? Naively they should recreate given this is a RAID 1 so it's the
> same data on both drives so I shouldn't have to worry. Or is that to
> simplistic of a view?


When you say “LVM on top of RAID” I assume you mean something like this:
	/dev/sd* (physical block devices) => md0 (mdadm array) => pv1 (LVM “physical” volume) => vg1 (LVM volume group) => lv1 (LVM logical volume) => /mnt/foo (filesystem)

If that’s the case then the LVM physical volume and everything higher in the stack has no idea that you’re swapping disks and doesn’t need to be told anything.

—

On a related note, sometimes mdadm commands that reference physical devices, like this:
	mdadm --manage /dev/md1 --fail /dev/sdb2
will fail with an error like:
	No such device: /dev/sdb2
because the file /dev/sdb2 no longer exists (because the disk is dead or pulled).

But you still need to tell mdadm about it so it can update the array. Instead you should use the short name:
	mdadm --manage /dev/md1 --fail sdb2
or whatever other device name shows up when you ask mdadm about the array or look at /proc/mdstat. That bypasses any device-file lookup and uses the references that mdadm tracks internally.

	Zach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2749 bytes
Desc: not available
URL: <http://cialug.org/pipermail/cialug/attachments/20140930/f4a5c51e/attachment.bin>


More information about the Cialug mailing list