Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>, linux-raid@vger.kernel.org
Subject: Re: Reshaping raid0/10
Date: Mon, 12 Mar 2007 09:36:39 +1100	[thread overview]
Message-ID: <17908.33911.135761.236374@notabene.brown> (raw)
In-Reply-To: message from H. Peter Anvin on Saturday March 10

On Saturday March 10, hpa@zytor.com wrote:
> Neil Brown wrote:
> > 
> > If I wanted to reshape a raid0, I would just morph it into a raid4
> > with a missing parity drive, then use the raid5 code to restripe it.
> > Then morph it back to regular raid0.
> > 
> 
> Wow, that made my brain hurt.
> 
> Given the fact that we're going to have to do this on kernel.org soon, 
> what would be the concrete steps involved (we're going to have to change 
> 3-member raid0 into 4-member raid0)...

Well.... it's not straight forward at all.

Firstly: it can only work if all your drives are the same size
(rounded to 64K).  If they aren't raid0 will use all the available
space on each drive, while raid5 will only use the amount that is
available on the first drive.

If that condition is met, then you can safely convert to a raid4 with
one extra (missing) device by simply creating an array with the same
drives (so you have to stop and restart the array - you cannot do that
bit while the array is live).  You seem to need --assume-clean
to create the raid4 degraded... That is probably a bug in mdadm.

md/raid5 won't grow a degraded array, so now you have to add the new
drive and let it sync the parity information onto it even though you
aren't going to ultimately use it.  This is a bit of a bore.  It could
probably be fixed but it wouldn't be entirely trivial (meaning a day
rather than an hour).

Once you have the non-degraded raid4, the next step would be
  mdadm -G /dev/mdX -n 5 --backup-file=/root/something
(a 5 drive raid4 contains your 4drive raid0).  Growing to a degraded
array is not a problem.  However md won't currently let you do this
on a raid4.   The patch to fix this is trivial and is below.

The --backup-file is needed as there is no spare for mdadm to store
some temporary data on.

Once the grow finishes, you can unmount, stop the array, and create it
as a raid0.

This seems to work - I just tried it on a rather small filesystem
(100M per drive) and it all went quite smoothly.

I hope to be able to get all this automated one days so you can just
  mdadm -G /dev/mdX -n 4
on a raid0 and it will work.

The need to sync the new disk first adds some real awkwardnesses.  It
would actually be a lot easier if the parity device was the first of
the array instead of the last.. retro fitting a new raid4 layout which
you cannot accidentally corrupt be using an old kernel might be
awkward though... not impossible.

Changing a raid0 to a raid4 while on-line is also non-trivial.  Raid0
doesn't keep track of requests-in-flight so knowing when all raid0
requests have completed and it is ok to start handling requests via
raid4 will need some care..

But with the following patch and a small down-time window at each end,
you can use md to grow a raid0 today...  But I suggest you try it on
test data first.

NeilBrown


Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./drivers/md/raid5.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff .prev/drivers/md/raid5.c ./drivers/md/raid5.c
--- .prev/drivers/md/raid5.c	2007-03-02 15:48:35.000000000 +1100
+++ ./drivers/md/raid5.c	2007-03-12 09:02:41.000000000 +1100
@@ -4104,6 +4104,10 @@ static struct mdk_personality raid4_pers
 	.spare_active	= raid5_spare_active,
 	.sync_request	= sync_request,
 	.resize		= raid5_resize,
+#ifdef CONFIG_MD_RAID5_RESHAPE
+	.check_reshape	= raid5_check_reshape,
+	.start_reshape  = raid5_start_reshape,
+#endif
 	.quiesce	= raid5_quiesce,
 };
 

  parent reply	other threads:[~2007-03-11 22:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-21 16:28 Reshaping raid0/10 Jan Engelhardt
2007-02-21 19:59 ` Neil Brown
2007-02-22  6:09   ` dean gaudet
2007-02-23 12:59   ` Jan Engelhardt
2007-02-23 20:17     ` Neil Brown
2007-03-10 20:21       ` H. Peter Anvin
2007-03-10 21:19         ` Jan Engelhardt
2007-03-11 22:36         ` Neil Brown [this message]
2007-05-29  4:51           ` H. Peter Anvin

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=17908.33911.135761.236374@notabene.brown \
    --to=neilb@suse.de \
    --cc=hpa@zytor.com \
    --cc=jengelh@linux01.gwdg.de \
    --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