Resizing raid-1 on replacing failed disk

Resizing raid-1 on replacing failed disk

[matt brennan]

I would like replace a failed disk in a raid-1 with a larger disk - and 
ultimately increase the size of the array (and ext3 partition) by 
subsequently adding a second larger disk in lieu of the currently active 
one.

I am hoping someone will scan the following and briefly reply: "this 
looks ok" or "you forgot step(s) X" before I commence.

<disclaimer>
I have read the software-raid-howto, list faq, mdadm man pages and 
trawled this mailing list to try to ensure I am not posting a question 
that has been answered before. If you believe that this topic is well 
covered elsewhere, please smack me up and post a link.
</disclaimer>

Currently:

kernel: 2.4.18
mdadm: 0.7.2-2 (version reported by dpkg)

> # mdadm --detail /dev/md0
> /dev/md0:
>         Version : 00.90.00
>   Creation Time : Sun Dec 23 05:46:51 2001
>      Raid Level : raid1
>      Array Size : 39078016 (37.26 GiB 40.01 GB)
>     Device Size : 39078016 (37.26 GiB 40.01 GB)
>      Raid Disks : 2
>     Total Disks : 2
> Preferred Minor : 0
>     Persistance : Superblock is persistant
<snip>
>     Number   Major   Minor   RaidDisk   State
>        0       3        1        0      active sync   /dev/hda1
>        1      22        1        1      faulty   /dev/hdc1
>            UUID : 3e9f6b0c:e3c4d3cc:761130b2:d4f74686

Plan:

- backup
- physcially remove the failed disk
- physcially replace the failed disk with a larger disk
- add the new disk to the array and allow to resync
- fail and remove the active smaller disk
- physcially replace the active smaller disk with a larger disk
- resize the ext3 partition

Help:

Could you indicate whether this is possible with the listed kernel and 
mdadm version before I kick off?

Thanks and regards,

   matt

RE: Resizing raid-1 on replacing failed disk

[Guy]

You will be replacing your boot disk (I think).  This will be a grub or lilo
issue.  Please wait for someone to help with this!  But not me!  I don't
trust my advice!  Other than my advice to wait for help. :)

I don't recall if the size will just grow when you replace with a larger
disk.  But if you know it will, then this should work (other than booting).
Oops, I recall some issue resizing a file system, don't recall the issue, or
how to deal with it.  Will search and send another message if I find it.

But I do have other notes:
- backup
* logically remove the failed disk - "mdadm /dev/md0 -r /dev/hdc1"
- physically remove the failed disk
- physically replace the failed disk with a larger disk
- add the new disk to the array and allow to resync
- fail and remove the active smaller disk
* fail the smaller disk - "mdadm /dev/md0 -f /dev/hda1"
* wait a few seconds (was some issue with failing and removing too quickly)
* remove the smaller disk - "mdadm /dev/md0 -r /dev/hda1"
- physically replace the active smaller disk with a larger disk
- resize the ext3 partition

Guy

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of matt brennan
Sent: Saturday, October 23, 2004 12:11 AM
To: linux-raid@vger.kernel.org
Subject: Resizing raid-1 on replacing failed disk

I would like replace a failed disk in a raid-1 with a larger disk - and 
ultimately increase the size of the array (and ext3 partition) by 
subsequently adding a second larger disk in lieu of the currently active 
one.

I am hoping someone will scan the following and briefly reply: "this 
looks ok" or "you forgot step(s) X" before I commence.

<disclaimer>
I have read the software-raid-howto, list faq, mdadm man pages and 
trawled this mailing list to try to ensure I am not posting a question 
that has been answered before. If you believe that this topic is well 
covered elsewhere, please smack me up and post a link.
</disclaimer>

Currently:

kernel: 2.4.18
mdadm: 0.7.2-2 (version reported by dpkg)

> # mdadm --detail /dev/md0
> /dev/md0:
>         Version : 00.90.00
>   Creation Time : Sun Dec 23 05:46:51 2001
>      Raid Level : raid1
>      Array Size : 39078016 (37.26 GiB 40.01 GB)
>     Device Size : 39078016 (37.26 GiB 40.01 GB)
>      Raid Disks : 2
>     Total Disks : 2
> Preferred Minor : 0
>     Persistance : Superblock is persistant
<snip>
>     Number   Major   Minor   RaidDisk   State
>        0       3        1        0      active sync   /dev/hda1
>        1      22        1        1      faulty   /dev/hdc1
>            UUID : 3e9f6b0c:e3c4d3cc:761130b2:d4f74686

Plan:

- backup
- physcially remove the failed disk
- physcially replace the failed disk with a larger disk
- add the new disk to the array and allow to resync
- fail and remove the active smaller disk
- physcially replace the active smaller disk with a larger disk
- resize the ext3 partition

Help:

Could you indicate whether this is possible with the listed kernel and 
mdadm version before I kick off?

Thanks and regards,

   matt
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Resizing raid-1 on replacing failed disk

[Guy]

I found the warning!
"You must resize the partition now. The device that the partition on is now
about 500Gb, but the partition is still 250Gb. If you're partition is ext2
or ext3, you can use resize2fs. A word of caution for you. I've used this
utility many times, and it is necessary to do a e2fsck -f on the partition
to be resized BOTH before and after. The program itself will require you to
do it before. If you skip doing it after resize2fs completes, you will
almost assuredly ruin your filesystem. I've skipped the fsck after the
resize2fs myself 2-3 times, and it killed the filesystem every time.

TJ Harrell"

Guy

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Guy
Sent: Saturday, October 23, 2004 1:42 AM
To: 'matt brennan'; linux-raid@vger.kernel.org
Subject: RE: Resizing raid-1 on replacing failed disk

You will be replacing your boot disk (I think).  This will be a grub or lilo
issue.  Please wait for someone to help with this!  But not me!  I don't
trust my advice!  Other than my advice to wait for help. :)

I don't recall if the size will just grow when you replace with a larger
disk.  But if you know it will, then this should work (other than booting).
Oops, I recall some issue resizing a file system, don't recall the issue, or
how to deal with it.  Will search and send another message if I find it.

But I do have other notes:
- backup
* logically remove the failed disk - "mdadm /dev/md0 -r /dev/hdc1"
- physically remove the failed disk
- physically replace the failed disk with a larger disk
- add the new disk to the array and allow to resync
- fail and remove the active smaller disk
* fail the smaller disk - "mdadm /dev/md0 -f /dev/hda1"
* wait a few seconds (was some issue with failing and removing too quickly)
* remove the smaller disk - "mdadm /dev/md0 -r /dev/hda1"
- physically replace the active smaller disk with a larger disk
- resize the ext3 partition

Guy

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of matt brennan
Sent: Saturday, October 23, 2004 12:11 AM
To: linux-raid@vger.kernel.org
Subject: Resizing raid-1 on replacing failed disk

I would like replace a failed disk in a raid-1 with a larger disk - and 
ultimately increase the size of the array (and ext3 partition) by 
subsequently adding a second larger disk in lieu of the currently active 
one.

I am hoping someone will scan the following and briefly reply: "this 
looks ok" or "you forgot step(s) X" before I commence.

<disclaimer>
I have read the software-raid-howto, list faq, mdadm man pages and 
trawled this mailing list to try to ensure I am not posting a question 
that has been answered before. If you believe that this topic is well 
covered elsewhere, please smack me up and post a link.
</disclaimer>

Currently:

kernel: 2.4.18
mdadm: 0.7.2-2 (version reported by dpkg)

> # mdadm --detail /dev/md0
> /dev/md0:
>         Version : 00.90.00
>   Creation Time : Sun Dec 23 05:46:51 2001
>      Raid Level : raid1
>      Array Size : 39078016 (37.26 GiB 40.01 GB)
>     Device Size : 39078016 (37.26 GiB 40.01 GB)
>      Raid Disks : 2
>     Total Disks : 2
> Preferred Minor : 0
>     Persistance : Superblock is persistant
<snip>
>     Number   Major   Minor   RaidDisk   State
>        0       3        1        0      active sync   /dev/hda1
>        1      22        1        1      faulty   /dev/hdc1
>            UUID : 3e9f6b0c:e3c4d3cc:761130b2:d4f74686

Plan:

- backup
- physcially remove the failed disk
- physcially replace the failed disk with a larger disk
- add the new disk to the array and allow to resync
- fail and remove the active smaller disk
- physcially replace the active smaller disk with a larger disk
- resize the ext3 partition

Help:

Could you indicate whether this is possible with the listed kernel and 
mdadm version before I kick off?

Thanks and regards,

   matt
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resizing raid-1 on replacing failed disk

[matt brennan]

Guy wrote <snipped together from serveral replies>:

> You will be replacing your boot disk (I think).  This will be a grub
> or lilo issue.  

Thanks for your help! The array is not a boot disk (my bad - should have
clarified)...

> But I do have other notes: 
> * logically remove the failed disk - "mdadm /dev/md0 -r /dev/hdc1"
> * fail the smaller disk - "mdadm /dev/md0 -f /dev/hda1"
> * wait a few seconds (was some issue with failing and removing too quickly)
> * remove the smaller disk - "mdadm /dev/md0 -r /dev/hda1"

Thank you for this extra detail!

> If you're partition is ext2 or ext3, you can use resize2fs. A word of
> caution for you. I've used this utility many times, and it is
> necessary to do a e2fsck -f on the partition to be resized BOTH
> before and after.

And thanks again - this surely will help! It would perhaps be handy to 
have a tip on this (or more generally the resize array process) in the 
software-raid-faq (noting that e2fsck stuff is a file system rather than 
md issue). Perhaps I can contribute after completion.

> Please wait for someone to help with this!  But not
> me!  I don't trust my advice!  Other than my advice to wait for help.
> :)

Could someone else please comment on the overall feasibility of resizing 
a raid-1 array to physically larger disks via this process?

> - backup
> * logically remove the failed disk - "mdadm /dev/md0 -r /dev/hdc1"
> - physically remove the failed disk
> - physically replace the failed disk with a larger disk
> - add the new disk to the array and allow to resync
> * fail the smaller disk - "mdadm /dev/md0 -f /dev/hda1"
> * wait a few seconds (was some issue with failing and removing too quickly)
> * remove the smaller disk - "mdadm /dev/md0 -r /dev/hda1"
> - physically replace the active smaller disk with a larger disk
 > ** e2fsck -f
> - resize the ext3 partition
> ** e2fsck -f

Thanks and regards,

   matt

Re: Resizing raid-1 on replacing failed disk

[Neil Brown]

On Saturday October 23, raid@classforge.com wrote:
> 
> Could someone else please comment on the overall feasibility of resizing 
> a raid-1 array to physically larger disks via this process?
> 

Just adding a larger drive will not make a raid-1 larger.  
To make a raid-1 larger once all component drives (or partitions) are
large enough you have to either:
  1/ recreate the array (mdadm -C ....)
  2/ resize the array using a very recent 2.6 kernel and mdadm 1.7.0
      or later.

NeilBrown

partition sizing and raid1

[matt brennan]

I created a new raid1 array on two 300GB disks but it came in 
underweight in size...

Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/md0                129013     27322     95137  23% /home

I guess I stuffed up with the partitioning (from fdisk):

> Disk /dev/hda: 255 heads, 63 sectors, 16709 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
>    Device Boot    Start       End    Blocks   Id  System
> /dev/hda1             1     16709 134215011   fd  Linux raid autodetect

This was accepting fdisk's default max size.

I realise this is not an fdisk mailing list but I guess you've probably 
hit this problem when creating large disk arrays. Could anyone please 
provide a quick hint on what I've stuffed up?

kernel: 2.4.18

dpkg (debian woody) says fdisk is:
ii  util-linux     2.11n-7        Miscellaneous system utilities.

the fdisk man page suggests using cfdisk... is this likely to help? it 
looks like a will have to recreate the raid1 array anyway. :-(

   matt

Re: partition sizing and raid1

[Jim Paris]

> I created a new raid1 array on two 300GB disks
...
> >Disk /dev/hda: 255 heads, 63 sectors, 16709 cylinders
> >Units = cylinders of 16065 * 512 bytes
...
> kernel: 2.4.18

255 * 63 * 16709 * 512 = 137GB.  

From the Large Disk HOWTO:

"For large IDE disks (over 137 GB): make sure your kernel is 2.4.19/2.5.3 or later."

-jim

Re: partition sizing and raid1

[Gordon Henderson]

On Thu, 4 Nov 2004, matt brennan wrote:

> I created a new raid1 array on two 300GB disks but it came in
> underweight in size...
>
> Filesystem           1M-blocks      Used Available Use% Mounted on
> /dev/md0                129013     27322     95137  23% /home

Is the disk connected to an ATA-100 or 133 controller? IIRC, you will only
see ~130MB unless it's a 133 controller...

> I guess I stuffed up with the partitioning (from fdisk):
>
> > Disk /dev/hda: 255 heads, 63 sectors, 16709 cylinders
> > Units = cylinders of 16065 * 512 bytes
> >
> >    Device Boot    Start       End    Blocks   Id  System
> > /dev/hda1             1     16709 134215011   fd  Linux raid autodetect

> This was accepting fdisk's default max size.

Check the cylinder/head/sector against the BIOS. If neccessary, you can
use fdisk (or cfdisk) to force a change, but this will likely destroy any
data on the disk.

Also make sure both disks are partitioned identically - RAID1 will only be
as big as the smallest of the partitions.

It does look like fdisk has picked up the wrong CHS numbers - the disk
only appears to be 127GB is size according to those.

  (255*63*16709*512)/(1024*1024*1024) = 127.

Gordon