All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: raz ben yehuda <raziebe@gmail.com>
Cc: linux raid <linux-raid@vger.kernel.org>
Subject: Re: Subject: Raid0 Reshape . Preface
Date: Wed, 17 Jun 2009 21:55:00 +1000	[thread overview]
Message-ID: <19000.55700.831349.967378@notabene.brown> (raw)
In-Reply-To: message from raz ben yehuda on Wednesday June 17

On Wednesday June 17, raziebe@gmail.com wrote:
> Neil Hello
> This email is followed by a set of the raid0 reshape patches for your inspection.
> hopefully i haven't mess anything in this set.

Hi Raz,

 I've had a bit of a look and while it would need a few refinements it
 seems to generally make sense - though there are a lot of details I
 haven't looked at thoroughly yet.

 However... I'm not at all sure I want to continue with this
 direction.

 The more I think about it, the more I feel I would prefer to use the
 raid5 module for all restriping.
 So to reshape a raid0, we would convert it to degraded-raid4, reshape
 that, then convert back to raid0.

 I would really like to keep the raid0 module very simple and clean.

 For the above to work, the most significant changes that would be
 needed to raid5 are:

  1/ add multi-zone support for raid4.
     Much of the complexity of this would be in init_stripe
     (to set sh->disks and the various sh->dev[].)
     and raid5_compute_sector (to choose the correct stripe).

  2/ add non-power-of-2 chunks support.
     We already use sector_div quite a lot, so this probably isn't
     a big problem.

  3/ Record the size of each device in the metadata.
     This isn't needed for raid0 as each device records its own size,
     but for raid4, one device might be missing, and we need to know
     how big it is.
     For v0.90 there is room in the superblock to store this
     information.
     For v1.x there isn't - I only allowed 2 bytes per device, and
     we really need another 8.   This is not an insurmountable problem
     as we can add a feature flag to change the size of the per-device
     information from 2 to 16 bytes.

 I would certainly like to see how this approach pans out before
 committing one way or the other.

NeilBrown

  reply	other threads:[~2009-06-17 11:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-16 21:51 Subject: Raid0 Reshape . Preface raz ben yehuda
2009-06-17 11:55 ` Neil Brown [this message]
2009-06-17 12:17   ` John Robinson
2009-06-17 22:31     ` Neil Brown
2009-06-21 18:19       ` Bill Davidsen

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=19000.55700.831349.967378@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=raziebe@gmail.com \
    /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.