All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: Laurent CARON <lcaron@apartia.fr>
Cc: Linux <linux-raid@vger.kernel.org>
Subject: Re: Expanding array by changing disks (one by one)
Date: Thu, 14 Apr 2005 12:04:26 +0100	[thread overview]
Message-ID: <425E4E3A.7070403@dgreaves.com> (raw)
In-Reply-To: <425E41C8.7050704@apartia.fr>

Laurent CARON wrote:

> Hello,
>
> We are in the process of increasing the size our RAID Arrays as our 
> storage needs increase.

Hi,
I'm no expert but I'll bounce some thoughts back at you...

>
> I've got 2 solutions for this:
>
> - Copy the data over a new array and replace the disks

pros:
sane and minimal risk of data loss since you don't delete data until the 
new one is up.
quickest solution (in manpower, elapsed time and system outages)

cons:
doesn't test Neils grow mode in mdadm (without which none of this would 
be possible)

> - Replace each disk (one after the other(after resync)) of the 
> existing array with a bigger one.

and the corollorary of sane would be... <joke>

>
> Start:
>    - Array is ok
> - Remove 1 disk
>    - Array is degraded
> - Add a bigger disk
>    - Resync
> - Remove another disk
>    - Array is degraded
> - Add a bigger disk
>    - Resync
> .....
>
This seems like it would work with mdadm's shiny new(?) grow command.
It looks from the man page like you use the grow command *after* 
changing out all the disks; yes?
Shiny and new means you need a reliable backup.
And this is likely to be slow - 1 resync per disk - and needs a system 
shutdown/outage for each disk swapped (assuming not hot-swap-able)
If you do have hot-swap then this seems like quite a nice option (no 
outages)

Mad speculative question ...
Would doing this work:
- add new big disk
- mdadm --remove a disk
- dd if=<removed disk> of=<new disk>
- mdadm -add new disk?
- remove small disk

if so it'd be a lot quicker than a resync each time...

> Would this be the 'state of the art' way ?

Have you seen EVMS? It has the ability to add devices to a raid5 array.
I'd class that as state of the art since you aren't 'throwing away' the 
smaller disks.

> Will the filesystem cope with it?

yes assuming it has a growfs.

>
> Is my mind completely broken?

not yet - let us know after you try it...

David

      parent reply	other threads:[~2005-04-14 11:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-14 10:11 Expanding array by changing disks (one by one) Laurent CARON
2005-04-14 10:15 ` Andy Smith
2005-04-14 11:02 ` Gordon Henderson
2005-04-14 15:08   ` Mike Hardy
2005-04-14 11:04 ` David Greaves [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=425E4E3A.7070403@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=lcaron@apartia.fr \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.