Resizing raid-1 on replacing failed disk

Resizing raid-1 on replacing failed disk

am 23.10.2004 06:11:07 von 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.


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.


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

> 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

am 23.10.2004 07:41:50 von bugzilla

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.


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.


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

> 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

am 23.10.2004 08:12:51 von bugzilla

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.


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.


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

> 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

-
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

am 23.10.2004 08:31:59 von matt brennan

Guy wrote :

> 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



-
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

am 25.10.2004 07:14:57 von 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
-
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

partition sizing and raid1

am 04.11.2004 05:44:36 von 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

-
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: partition sizing and raid1

am 04.11.2004 06:24:36 von 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
-
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: partition sizing and raid1

am 04.11.2004 09:10:06 von 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
-
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