linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luca Berra <bluca@comedia.it>
To: linux-raid@vger.kernel.org
Subject: Re: how to which to bigger disk (md can do it?)
Date: Mon, 17 Nov 2003 21:24:58 +0100	[thread overview]
Message-ID: <20031117202457.GC11443@percy.comedia.it> (raw)
In-Reply-To: <3FB8D5A6.4040909@bnap.hu>

On Mon, Nov 17, 2003 at 03:05:26PM +0100, Farkas Levente wrote:
>>Not so weird - it is exactly what I was going to suggest.
>>Providing you get the chunk size, parity algoithm and device order
>>right, and use "--force" to make sure mdadm doesn't re-arrange the
>>devices on on it should work perfectly.
>
>this's one of our production server, so I'd like to be sure. so:
this is the reason i said it is a weird idea, it is not easy to
understand and if you fuck up you fuck up badly!

>- switch the disk one by one (do these steps 8 times):
>   - put out one 120 hd (mdadm /dev/md0 -f /dev/sda1 -r /dev/sda1)
>   - put the new 200 GB one and create a 200 GB partition (Linux raid
>     autodetect)
>   - add to md0 (mdadm -a /dev/hda1) this step do not change the device
>     order???
at this point you will find yourself with a 120GBx8 raid 5 array
now you would have to (but i would be very careful in doing this)

check the exact device order (/proc/mdstat ???)
write it down
check the chunk size
write it down
check the parity algorithm
write it down

umount the fs
stop the damned array

mdadm -C /dev/md<whatever> -c <your chink size> -p <your parity> -n 8 -f <list of all
devices in the same exact order>

THIS WILL REWRITE THE PARITY ON ALL DRIVES, SO IF YOU GET IT WRONG YOU
WILL DESTROY YOUR DATA

(would using missing as the last drive prevent the parity rebuild and
allow to check the expected result ?????)

cross you fingers,
mount your fs back and see what happened
umount it again
>- resize2fs
mount it for the last time


>when should I use --force??
only when you are really sure of what you are doing.

please test it on a test system before doing it on real data

you might well find that a slower way might be better for you

(i don't want to sound catastrophic, but i am not going to be held
responsible if someone reads these instruction and fucks-up badly)

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

  reply	other threads:[~2003-11-17 20:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-16 11:03 how to which to bigger disk (md can do it?) Farkas Levente
2003-11-16 13:31 ` Hendrik Visage
2003-11-16 16:36   ` Farkas Levente
2003-11-16 17:38   ` Maurice Hilarius
2003-11-17  9:29 ` Luca Berra
2003-11-17  9:51   ` Neil Brown
2003-11-17 14:05     ` Farkas Levente
2003-11-17 20:24       ` Luca Berra [this message]
2003-11-17 22:29       ` Neil Brown

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=20031117202457.GC11443@percy.comedia.it \
    --to=bluca@comedia.it \
    --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 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).