md Grow for Raid 5

md Grow for Raid 5

[John Poirier]

Greets,
A lot of RAID 5 hardware controllers can grow a RAID 5 array (online 
capacity expansion). Will this be available in software RAID?

John

Re: md Grow for Raid 5

[Frank Wittig]

It actually is available.
I've tested it and it worked fine for me. But taking a backup is highly 
recommended.
The trick is not to use mdadm, since growing with mdadm is not possible 
at the moment. Use raid-tools instead.
The program raidreconf comes along with raidtools. This prog takes two 
raid-tab files as input which describe the array configuration before 
and after reconfiguration. (See man raidreconf for further details)
I've testet growing an array of 3 disks to 4 disks. Having LVM2 grow its 
volume group along with the raid was another (very tricky) thing...

Greetings,
Frank


John Poirier wrote:

> Greets,
> A lot of RAID 5 hardware controllers can grow a RAID 5 array (online 
> capacity expansion). Will this be available in software RAID?

Re: md Grow for Raid 5

[Mike Hardy]

Frank Wittig wrote:
> It actually is available.
> I've tested it and it worked fine for me. But taking a backup is highly 
> recommended.
> The trick is not to use mdadm, since growing with mdadm is not possible 
> at the moment. Use raid-tools instead.
> The program raidreconf comes along with raidtools. This prog takes two 
> raid-tab files as input which describe the array configuration before 
> and after reconfiguration. (See man raidreconf for further details)

I'll second both major points here:

raidreconf does work, but it can fail and leave things completely 
destroyed (imagine one bad block somewhere after parity was partially 
migrated), so take a backup.

Given that you're taking a backup already then, creating a new array 
(with its optimized resync) might be faster if its an online backup.

I'm 2 for 4 now on raidreconf working, with the two failures (sadly) 
being of the "operator error" variety - raidreconf is picky and fails 
slow if your disk sizes aren't what it expects, I found. It got to the 
end and ran out of space on me due to a slightly different "250GB" disk 
size once. The other was a bad block along the way - I should have done 
smartctl -t long on all drives prior to resize. Both lessons learned...

-Mike

Re: md Grow for Raid 5

[berk walker]

Have you guys seen/tried mdadm 1.90?  I am delightfully experiencing the 
neat issues [read problems] with MY system [sys1], and am too into 
myself to be able to take on serious other-probs.  The doc [which is 
still a tad lite, NB]  has a grow command.  Understand that your files 
exist on/in a filesystem, which has a _size_.  Growing RAID and growing 
fs are two, nonrelated things.  But if you want #2, then you have to do 
both 1 & 2.  There is definately more than one way to "skin a cat", so 
pgms of which you are familiar might be queried first.

Price - 2cents
b-
caveat:
You may not get what you paid for -
    but, you always pay for what you get.    <-Practise .sig

Mike Hardy wrote:

>
> Frank Wittig wrote:
>
>> It actually is available.
>> I've tested it and it worked fine for me. But taking a backup is 
>> highly recommended.
>> The trick is not to use mdadm, since growing with mdadm is not 
>> possible at the moment. Use raid-tools instead.
>> The program raidreconf comes along with raidtools. This prog takes 
>> two raid-tab files as input which describe the array configuration 
>> before and after reconfiguration. (See man raidreconf for further 
>> details)
>
>
> I'll second both major points here:
>
> raidreconf does work, but it can fail and leave things completely 
> destroyed (imagine one bad block somewhere after parity was partially 
> migrated), so take a backup.
>
> Given that you're taking a backup already then, creating a new array 
> (with its optimized resync) might be faster if its an online backup.
>
> I'm 2 for 4 now on raidreconf working, with the two failures (sadly) 
> being of the "operator error" variety - raidreconf is picky and fails 
> slow if your disk sizes aren't what it expects, I found. It got to the 
> end and ran out of space on me due to a slightly different "250GB" 
> disk size once. The other was a bad block along the way - I should 
> have done smartctl -t long on all drives prior to resize. Both lessons 
> learned...
>
> -Mike
> -
> 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: md Grow for Raid 5

[Mike Hardy]

berk walker wrote:
> Have you guys seen/tried mdadm 1.90?  I am delightfully experiencing the 

I believe the mdadm based grow does not work for raid5, but only for 
raid0 or raid1. raidreconf is actually capable of adding disks to raid5 
and re-laying out the stripes / moving parity blocks, etc

You're very correct about needing to grow the FS after growing the 
device though. Most FS's have tools for that, or there's LVM...

-Mike

Re: md Grow for Raid 5

[Neil Brown]

On Tuesday March 8, mhardy@h3c.com wrote:
> 
> berk walker wrote:
> > Have you guys seen/tried mdadm 1.90?  I am delightfully experiencing the 
> 
> I believe the mdadm based grow does not work for raid5, but only for 
> raid0 or raid1. raidreconf is actually capable of adding disks to raid5 
> and re-laying out the stripes / moving parity blocks, etc

There are different dimensions for growing....
You can make the component devices bigger, or you can add component
devices.  You can increase storage or you can increase redundancy.

If you replace all the devices in a raid1, raid5, or raid6 with large
devices (presumably one at a time allowing for a reconstruct each
time) then mdadm will allow you to "grow" the array to make use of the
extra space.

mdadm will also allow you to "grow" and raid1 array by adding extra
devices.  This only increases redundancy, not capacity.

I code to allows you to "grow" a linear array by adding a drive to
it.  I'm not sure if I have submitted this code.

I plan a raid4 version that organises the data in a linear rather than
a striped fashion.   It would be quite simple for mdadm to 'grow' this
sort of array.

All of these do not require moving data around, so they are easy.

Growing a raid5 or raid6 by adding another drive is conceptually
possible to do while the array is online, but I have not definite
plans to do this (I would like to).  Growing a raid5 into a raid6
would also be useful.
These require moving lots of data around, and need to be able to cope
with drive failure and system crash.... a fun project..

As has been said, raidreconf does at least some of this off-line.

NeilBrown

Re: md Grow for Raid 5

[David Greaves]

Neil Brown wrote:

>Growing a raid5 or raid6 by adding another drive is conceptually
>possible to do while the array is online, but I have not definite
>plans to do this (I would like to).  Growing a raid5 into a raid6
>would also be useful.
>These require moving lots of data around, and need to be able to cope
>with drive failure and system crash.... a fun project..
>  
>
EVMS has this already.

It works and is supported (whereas I didn't think raidreconf was).
It would be nice to move the EVMS raid5 extension code into the core md.

FYI, I used EVMS briefly and found it to be an excellent toolset. It's a 
teeny bit rough and a bit OTT for a personal server though so I'm 
sticking with md/lvm2 for now :)

David

Re: md Grow for Raid 5

[Frank Wittig]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Mike Hardy wrote:

> You're very correct about needing to grow the FS after growing the 
> device though. Most FS's have tools for that, or there's LVM...
> 
> -Mike

I've tested with LVM2 an found, that resizing is not supported at the 
moment (newest kernel with FC3).
LVM can only grow by adding PVs to the VG. Growing PVs is not supported.
The only way is to export and reimport the VG configuration with 
vgcfgbackup and vgcfgrestore and to alter the number of physical extends 
of the grown PV manually.

Greetings,
Frank

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: md Grow for Raid 5

[berk walker]

Already are, John.  mdadm, and two or three others.
b-
John Poirier wrote:

> Greets,


> A lot of RAID 5 hardware controllers can grow a RAID 5 array (online 
> capacity expansion). Will this be available in software RAID?
>
> John
>
> -
> 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: md Grow for Raid 5

[Mike Tran]

How does mdadm grow a raid5 array?
Could you please provide an URL to other tools which can perform online 
capacity expansion of md raid5 arrays?

--
Regards,
Mike T.

berk walker wrote:

>
>
> Already are, John.  mdadm, and two or three others.
> b-
> John Poirier wrote:
>
>> Greets,
>
>
>
>> A lot of RAID 5 hardware controllers can grow a RAID 5 array (online 
>> capacity expansion). Will this be available in software RAID?
>>
>> John
>>
>> -
>

Re: md Grow for Raid 5

[berk walker]

Mike, check him out, google him.  Man is really open, good/talanted, and 
the author of mdadm.

That being said, the dox for it do seem a bit lean, but at least give 
it/him a look, ok?
And on other tools, google on that, also.  Google is the compuweenies 
friend - *usually* works for me. [if you need help on whatis google, 
etc, priv. mail me]
b-

Mike Tran wrote:

> How does mdadm grow a raid5 array?
> Could you please provide an URL to other tools which can perform 
> online capacity expansion of md raid5 arrays?
>
> -- 
> Regards,
> Mike T.
>
> berk walker wrote:
>
>>
>>
>> Already are, John.  mdadm, and two or three others.
>> b-
>> John Poirier wrote:
>>
>>> Greets,
>>
>>
>>
>>
>>> A lot of RAID 5 hardware controllers can grow a RAID 5 array (online 
>>> capacity expansion). Will this be available in software RAID?
>>>
>>> John
>>>
>>> -
>>
>>
>
>
> -
> 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
>
> .
>