Resizing raid-1 on replacing failed disk

matt brennan

author

2004-10-23 04:11 UTC #0 lore raw

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)

Quoted 11 lines

# 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>

Quoted 4 lines

    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

Guy

2004-10-23 05:41 UTC #1 lore raw

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: [email protected] [mailto:[email protected]] On Behalf Of matt brennan
Sent: Saturday, October 23, 2004 12:11 AM
To: [email protected]
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)

Quoted 11 lines

# 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>

Quoted 4 lines

    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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Guy

2004-10-23 06:12 UTC #2 lore raw

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: [email protected] [mailto:[email protected]] On Behalf Of Guy
Sent: Saturday, October 23, 2004 1:42 AM
To: 'matt brennan'; [email protected]
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: [email protected] [mailto:[email protected]] On Behalf Of matt brennan
Sent: Saturday, October 23, 2004 12:11 AM
To: [email protected]
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)

Quoted 11 lines

# 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>

Quoted 4 lines

    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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

matt brennan

author

2004-10-23 06:31 UTC #3 lore raw

In reply to Guy

Guy wrote <snipped together from serveral replies>:

Quoted 2 lines

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)...

Quoted 4 lines

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!

Quoted 4 lines

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.

Quoted 3 lines

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?

Quoted 4 lines

- 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

Quoted 8 lines

- 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

Neil Brown

2004-10-25 05:14 UTC #4 lore raw

Quoted 4 lines · On Saturday October 23, [email protected] 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

matt brennan

author

2004-11-04 04:44 UTC #5 lore raw

partition sizing and raid1

In reply to 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):

Quoted 5 lines

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

Jim Paris

2004-11-04 05:24 UTC #6 lore raw

Re: partition sizing and raid1

Quoted 1 line

I created a new raid1 array on two 300GB disks

...

Quoted 2 lines

Quoted 2 lines
Disk /dev/hda: 255 heads, 63 sectors, 16709 cylinders Units = cylinders of 16065 * 512 bytes

...

Quoted 1 line

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

Gordon Henderson

2004-11-04 08:10 UTC #7 lore raw

Re: partition sizing and raid1

In reply to matt brennan

Quoted 5 lines · 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

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

Quoted 9 lines

I guess I stuffed up with the partitioning (from fdisk):
Quoted 5 lines
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