linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Expanding size of existing raid1 md device
@ 2003-04-24 18:48 Sean Kormilo
  2003-04-24 18:54 ` Mike Dresser
  2003-04-24 18:57 ` Mike Black
  0 siblings, 2 replies; 9+ messages in thread
From: Sean Kormilo @ 2003-04-24 18:48 UTC (permalink / raw)
  To: linux-raid

Hi,

I'm wondering if there is any way to do the following...

Assume I've got a system with 2 18GB disks. Each disk has 2 partitons
which are then setup as mirrored md devices.
/dev/md0 uses small 100MB partitions on each drive
/dev/md1 uses the rest of each disk (ie: ~17.9GB)

I'd like to be able to upgrade the system to use 36GB disks, such that
the /dev/md1 partition expands to take up the rest of the additional
space provided by the 36GB disk.

So, the process might look something like:
- fail and remove the partition for both md arrays
- remove 1 of the 18GB disks
- insert new 36GB disk
- partition 36GB disk with 100MB partition for /dev/md0
- partition 36GB disk with 35.9GB partition for /dev/md1
- hotadd the 36GB disk partitions so that it syncs with 18GB disk
- wait for sync to complete
- fail and remove the partitions on both md arrays on the 18GB disk
- remove the 18GB disk
- insert new 36GB disk
- partition 36GB disk with 100MB partition for /dev/md0
- partition 36GB disk with 35.9GB partition for /dev/md1
- hotadd the 36GB disk partitions so that it syncs with the other 36GB
disk

Having tried this, it works except that /dev/md1 does not make use of
the additional space provided by the 36GB disks even though the
partitions on both disks are larger. It appears to me that it is using
the value from the superblock when the array was created (which makes
sense).

Is there some way to force the md driver to expand to use the maximum
size available based on the disks/partitions in the array? Perhaps from
mdadm? Or is some kind of patch to the kernel required to make this
work? If so, any pointers as to where I'd look?

Thanks!

Sean.




-- 

Sean C. Kormilo, STORM Software Architect, Nortel Networks
              email: skormilo@nortelnetworks.com
  


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Expanding size of existing raid1 md device
  2003-04-24 18:48 Expanding size of existing raid1 md device Sean Kormilo
@ 2003-04-24 18:54 ` Mike Dresser
  2003-04-24 20:52   ` Sean Kormilo
  2003-04-24 18:57 ` Mike Black
  1 sibling, 1 reply; 9+ messages in thread
From: Mike Dresser @ 2003-04-24 18:54 UTC (permalink / raw)
  To: Sean Kormilo; +Cc: linux-raid

On 24 Apr 2003, Sean Kormilo wrote:

> I'd like to be able to upgrade the system to use 36GB disks, such that
> the /dev/md1 partition expands to take up the rest of the additional
> space provided by the 36GB disk.

Out of curiosity, and judging from the size of your disks, this is a scsi
system.

Can you create a new set of arrays on the 36's, and just copy the data
over from the 18's?

Mike


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Expanding size of existing raid1 md device
  2003-04-24 18:48 Expanding size of existing raid1 md device Sean Kormilo
  2003-04-24 18:54 ` Mike Dresser
@ 2003-04-24 18:57 ` Mike Black
  2003-04-24 20:47   ` Sean Kormilo
  1 sibling, 1 reply; 9+ messages in thread
From: Mike Black @ 2003-04-24 18:57 UTC (permalink / raw)
  To: Sean Kormilo, linux-raid

I've done this with a single partition but it should work for multiple also.

Sounds like you already partioned the new 36G correctly.
Before you insert the new 36G disk you need to re-create the raid array and resize the file system:
Let's assume you've already sync'd hda to the 36G hdc and replaced hda with a brand-new 36G
mdadm --create /dev/md0 -l1 -n2 /dev/hdc1 missing
resize2fs -p -f /dev/md0
e2fsck -C 0 /dev/md0
mdadm --add /dev/md0 /dev/hda1

And repeat for md1

----- Original Message ----- 
From: "Sean Kormilo" <skormilo@nortelnetworks.com>
To: "linux-raid" <linux-raid@vger.kernel.org>
Sent: Thursday, April 24, 2003 2:48 PM
Subject: Expanding size of existing raid1 md device


> Hi,
> 
> I'm wondering if there is any way to do the following...
> 
> Assume I've got a system with 2 18GB disks. Each disk has 2 partitons
> which are then setup as mirrored md devices.
> /dev/md0 uses small 100MB partitions on each drive
> /dev/md1 uses the rest of each disk (ie: ~17.9GB)
> 
> I'd like to be able to upgrade the system to use 36GB disks, such that
> the /dev/md1 partition expands to take up the rest of the additional
> space provided by the 36GB disk.
> 
> So, the process might look something like:
> - fail and remove the partition for both md arrays
> - remove 1 of the 18GB disks
> - insert new 36GB disk
> - partition 36GB disk with 100MB partition for /dev/md0
> - partition 36GB disk with 35.9GB partition for /dev/md1
> - hotadd the 36GB disk partitions so that it syncs with 18GB disk
> - wait for sync to complete
> - fail and remove the partitions on both md arrays on the 18GB disk
> - remove the 18GB disk
> - insert new 36GB disk
> - partition 36GB disk with 100MB partition for /dev/md0
> - partition 36GB disk with 35.9GB partition for /dev/md1
> - hotadd the 36GB disk partitions so that it syncs with the other 36GB
> disk
> 
> Having tried this, it works except that /dev/md1 does not make use of
> the additional space provided by the 36GB disks even though the
> partitions on both disks are larger. It appears to me that it is using
> the value from the superblock when the array was created (which makes
> sense).
> 
> Is there some way to force the md driver to expand to use the maximum
> size available based on the disks/partitions in the array? Perhaps from
> mdadm? Or is some kind of patch to the kernel required to make this
> work? If so, any pointers as to where I'd look?
> 
> Thanks!
> 
> Sean.
> 
> 
> 
> 
> -- 
> 
> Sean C. Kormilo, STORM Software Architect, Nortel Networks
>               email: skormilo@nortelnetworks.com
>   
> 
> -
> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Expanding size of existing raid1 md device
  2003-04-24 18:57 ` Mike Black
@ 2003-04-24 20:47   ` Sean Kormilo
  2003-04-24 21:14     ` Scott McDermott
  0 siblings, 1 reply; 9+ messages in thread
From: Sean Kormilo @ 2003-04-24 20:47 UTC (permalink / raw)
  To: Mike Black; +Cc: linux-raid

Mike,

One thing I forgot to mention is that I want to be able to do this
without taking the system down at all.

I'm not sure I quite understand the process... I'd already have an
existing /dev/md0 and /dev/md1. Is "mdadm --create" supposed to allow me
to basically re-create the array? When I try this I get the following.
In this case, I removed /dev/sdb2 from /dev/md1 prior to attempting the
re-creation of the array. If I try to do it with both disks already
there I get the same error:

/usr/share/scsirastools/mdadm --create /dev/md1 -l1 -n2 /dev/sda2 missing
mdadm: /dev/sda2 appear to be part of a raid array:
    level=1 devices=2 ctime=Thu Apr 24 07:23:43 2003
Continue creating array? y
mdadm: SET_ARRAY_INFO failed for /dev/md1: File exists

Sean.

> I've done this with a single partition but it should work for multiple also.
> 
> Sounds like you already partioned the new 36G correctly.
> Before you insert the new 36G disk you need to re-create the raid array and resize the file system:
> Let's assume you've already sync'd hda to the 36G hdc and replaced hda with a brand-new 36G
> mdadm --create /dev/md0 -l1 -n2 /dev/hdc1 missing
> resize2fs -p -f /dev/md0
> e2fsck -C 0 /dev/md0
> mdadm --add /dev/md0 /dev/hda1
> 
> And repeat for md1
> 
> ----- Original Message ----- 
> From: "Sean Kormilo" <skormilo@nortelnetworks.com>
> To: "linux-raid" <linux-raid@vger.kernel.org>
> Sent: Thursday, April 24, 2003 2:48 PM
> Subject: Expanding size of existing raid1 md device
> 
> 
> > Hi,
> > 
> > I'm wondering if there is any way to do the following...
> > 
> > Assume I've got a system with 2 18GB disks. Each disk has 2 partitons
> > which are then setup as mirrored md devices.
> > /dev/md0 uses small 100MB partitions on each drive
> > /dev/md1 uses the rest of each disk (ie: ~17.9GB)
> > 
> > I'd like to be able to upgrade the system to use 36GB disks, such that
> > the /dev/md1 partition expands to take up the rest of the additional
> > space provided by the 36GB disk.
> > 
> > So, the process might look something like:
> > - fail and remove the partition for both md arrays
> > - remove 1 of the 18GB disks
> > - insert new 36GB disk
> > - partition 36GB disk with 100MB partition for /dev/md0
> > - partition 36GB disk with 35.9GB partition for /dev/md1
> > - hotadd the 36GB disk partitions so that it syncs with 18GB disk
> > - wait for sync to complete
> > - fail and remove the partitions on both md arrays on the 18GB disk
> > - remove the 18GB disk
> > - insert new 36GB disk
> > - partition 36GB disk with 100MB partition for /dev/md0
> > - partition 36GB disk with 35.9GB partition for /dev/md1
> > - hotadd the 36GB disk partitions so that it syncs with the other 36GB
> > disk
> > 
> > Having tried this, it works except that /dev/md1 does not make use of
> > the additional space provided by the 36GB disks even though the
> > partitions on both disks are larger. It appears to me that it is using
> > the value from the superblock when the array was created (which makes
> > sense).
> > 
> > Is there some way to force the md driver to expand to use the maximum
> > size available based on the disks/partitions in the array? Perhaps from
> > mdadm? Or is some kind of patch to the kernel required to make this
> > work? If so, any pointers as to where I'd look?
> > 
> > Thanks!
> > 
> > Sean.
> > 
> > 
> > 
> > 
> > -- 
> > 
> > Sean C. Kormilo, STORM Software Architect, Nortel Networks
> >               email: skormilo@nortelnetworks.com
> >   
> > 
> > -
> > 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
-- 

Sean C. Kormilo, STORM Software Architect, Nortel Networks
              email: skormilo@nortelnetworks.com
  


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Expanding size of existing raid1 md device
  2003-04-24 18:54 ` Mike Dresser
@ 2003-04-24 20:52   ` Sean Kormilo
  2003-04-24 21:02     ` Ross Vandegrift
  2003-04-24 21:25     ` Scott McDermott
  0 siblings, 2 replies; 9+ messages in thread
From: Sean Kormilo @ 2003-04-24 20:52 UTC (permalink / raw)
  To: Mike Dresser; +Cc: linux-raid

Mike,

Again, I probably wasn't clear enough in my first request...

I'd prefer to be able to do this without having to unmount or take down
any of the filesystems on the box (it is an NFS server). I cannot think
of a way to create a new set of arrays and switching to them without
unmounting the filesystems.

Sean.


> On 24 Apr 2003, Sean Kormilo wrote:
> 
> > I'd like to be able to upgrade the system to use 36GB disks, such that
> > the /dev/md1 partition expands to take up the rest of the additional
> > space provided by the 36GB disk.
> 
> Out of curiosity, and judging from the size of your disks, this is a scsi
> system.
> 
> Can you create a new set of arrays on the 36's, and just copy the data
> over from the 18's?
> 
> Mike
-- 

Sean C. Kormilo, STORM Software Architect, Nortel Networks
              email: skormilo@nortelnetworks.com
  


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Expanding size of existing raid1 md device
  2003-04-24 20:52   ` Sean Kormilo
@ 2003-04-24 21:02     ` Ross Vandegrift
  2003-04-24 21:25     ` Scott McDermott
  1 sibling, 0 replies; 9+ messages in thread
From: Ross Vandegrift @ 2003-04-24 21:02 UTC (permalink / raw)
  To: Sean Kormilo; +Cc: Mike Dresser, linux-raid

On Thu, Apr 24, 2003 at 04:52:34PM -0400, Sean Kormilo wrote:
> I'd prefer to be able to do this without having to unmount or take down
> any of the filesystems on the box (it is an NFS server). I cannot think
> of a way to create a new set of arrays and switching to them without
> unmounting the filesystems.

I don't think there's a way to do this.  Not only would you have to
change to the new volume without unmounting the filesystems (seems
impossible), you'd be changing the filesystem out from under the NFS
server.  I'm willing to bet that won't go over well at all...


-- 
Ross Vandegrift
ross@willow.seitz.com

A Pope has a Water Cannon.                               It is a Water Cannon.
He fires Holy-Water from it.                        It is a Holy-Water Cannon.
He Blesses it.                                 It is a Holy Holy-Water Cannon.
He Blesses the Hell out of it.          It is a Wholly Holy Holy-Water Cannon.
He has it pierced.                It is a Holey Wholly Holy Holy-Water Cannon.
He makes it official.       It is a Canon Holey Wholly Holy Holy-Water Cannon.
Batman and Robin arrive.                                       He shoots them.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Expanding size of existing raid1 md device
  2003-04-24 20:47   ` Sean Kormilo
@ 2003-04-24 21:14     ` Scott McDermott
  2003-04-25 11:57       ` Sean Kormilo
  0 siblings, 1 reply; 9+ messages in thread
From: Scott McDermott @ 2003-04-24 21:14 UTC (permalink / raw)
  To: linux-raid

Sean Kormilo on Thu 24/04 16:47 -0400:
> One thing I forgot to mention is that I want to be able to
> do this without taking the system down at all.

You can only do that if you have built your kernel with the
online ext[23]-resize patches.  Otherwise there is no way to
grow a mounted filesystem.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Expanding size of existing raid1 md device
  2003-04-24 20:52   ` Sean Kormilo
  2003-04-24 21:02     ` Ross Vandegrift
@ 2003-04-24 21:25     ` Scott McDermott
  1 sibling, 0 replies; 9+ messages in thread
From: Scott McDermott @ 2003-04-24 21:25 UTC (permalink / raw)
  To: linux-raid

Sean Kormilo on Thu 24/04 16:52 -0400:
> I'd prefer to be able to do this without having to unmount
> or take down any of the filesystems on the box (it is an
> NFS server).

As long as your clients have hard-mounted your NFS server,
they will just block until the server comes back up and
nothing untoward will happen.  As long as you keep all your
inode and device numbers the same (eg, don't make a new FS,
grow the one you have in place), there should be no
problems.  This will work fine if you just take the system
down, grow the array to whatever you like (same major/minor
nums, which are part of NFS cookie I think), then grow the
filesystem with resize2fs, and bring the server back up.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Expanding size of existing raid1 md device
  2003-04-24 21:14     ` Scott McDermott
@ 2003-04-25 11:57       ` Sean Kormilo
  0 siblings, 0 replies; 9+ messages in thread
From: Sean Kormilo @ 2003-04-25 11:57 UTC (permalink / raw)
  To: Scott McDermott; +Cc: linux-raid

Scott,

I'm using XFS and have the ability to grow the filesystem. That piece
isn't a problem. The issue I have is "growing" the md raid1 device.

Sean.

> Sean Kormilo on Thu 24/04 16:47 -0400:
> > One thing I forgot to mention is that I want to be able to
> > do this without taking the system down at all.
> 
> You can only do that if you have built your kernel with the
> online ext[23]-resize patches.  Otherwise there is no way to
> grow a mounted filesystem.
> -
> 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
-- 

Sean C. Kormilo, STORM Software Architect, Nortel Networks
              email: skormilo@nortelnetworks.com
  


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2003-04-25 11:57 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-04-24 18:48 Expanding size of existing raid1 md device Sean Kormilo
2003-04-24 18:54 ` Mike Dresser
2003-04-24 20:52   ` Sean Kormilo
2003-04-24 21:02     ` Ross Vandegrift
2003-04-24 21:25     ` Scott McDermott
2003-04-24 18:57 ` Mike Black
2003-04-24 20:47   ` Sean Kormilo
2003-04-24 21:14     ` Scott McDermott
2003-04-25 11:57       ` Sean Kormilo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).