linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: raz ben yehuda <raziebe@013.net>,
	linux-raid@vger.kernel.org,
	Jacek Danecki <jacek.danecki@intel.com>,
	"Labun, Marcin" <Marcin.Labun@intel.com>
Subject: Re: Subject: [001/002 ] raid0 reshape
Date: Thu, 21 May 2009 21:48:36 +1000	[thread overview]
Message-ID: <18965.16276.485692.812516@notabene.brown> (raw)
In-Reply-To: message from Dan Williams on Tuesday May 19

On Tuesday May 19, dan.j.williams@intel.com wrote:
> On Sat, May 2, 2009 at 2:46 PM, raz ben yehuda <raziebe@013.net> wrote:
> > Neil Hello
> > The bellow is the raid0 grow code.I have decided to fix raid0 and not
> > perform the transformation raid0-raid4-raid0 due to two reasons:
> > 1. raid0 zones. this patch support any zone transformations.
> > 2. Undesired dependency of raid0 over raid4 re-striping code.
> 
> Hi Raz,
> 
> Can you explain a bit more about why the raid4 approach is
> undesirable?  I think making reshape only available to raid0 arrays
> where all the members are the same size is a reasonable constraint.
> We then get the nice benefit of reusing the raid5 reshape
> infrastructure.  In other words I am not convinced that the benefits
> of reimplementing reshape in raid0 outweigh the costs.

I've been thinking about this too... Is it something we really want to
do?

My thoughts include:

 - I don't like special cases - it would be nice to support reshape on
   all arrays, even RAID0 with different sizes devices.
 - Anyone who does this with a raid0 made of simple drives is asking
   for trouble.  But a RAID0 over a bunch of RAID5 or RAID1 might make
   sense. 
 - Maybe we should support different sized drives in RAID4.  As long
   as the parity drive is as big as the largest data drive it could be
   made to work.  Similarly hot spares would need to be big, but you
   could have 2 hot spares and take the smallest one that is big
   enough.
   If a drive in the RAID4+ (or is it is the thing called NORAID?)
   failed and was replaced with a bigger drive, it would be cool to be
   able to incorporate that extra space into the array.

   If we did all that, then the 0->4->0 conversion could make use of
   the same code.
 - Surely RAID0 is (like LVM) just a legacy idea until we get sensible
   file systems that actually understand multiple devices and do all
   this stuff for you are a more sensible level - so why are we
   busting a gut(*) to make RAID0 work well??  Answer is of course
   that no-one has made a sensible file system yet. (well... maybe zfs
   or btrfs, not sure)
 - If you read the DDF spec carefully, you find there is a secondary
   raid level which stripes over heterogeneous arrays a different way.
   You divide every primary array up into N chunks, so the chunk sizes are
   different on different arrays.  Then you make a secondary array by
   striping over those chunks.
   So e.g. you might have a 4Gig RAID5 and a 1GIG RAID1.  So the
   stripes array on top of these could take 4Meg from the RAID5, then
   1Meg from the RAID1, then another 4 from the RAID5 etc.
   So we want to support that?  And would we want to reshape such a
   thing??

So: lots of thoughts, some pointing in different directions.
But I'm not against reshape code appearing in RAID0 providing it is
well designed, maintainable, reliable, and doesn't slow down normal
RAID0 processing.  I suspect we can get there.

NeilBrown




* is that an Australian term??? not sure.  http://www.wordwebonline.com/en/BUSTAGUT

  parent reply	other threads:[~2009-05-21 11:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-02 21:46 Subject: [001/002 ] raid0 reshape raz ben yehuda
2009-05-10 22:31 ` Neil Brown
2009-05-12 16:59   ` Raz
2009-05-19 18:09 ` Dan Williams
2009-05-19 22:27   ` Raz
2009-05-21 11:48   ` Neil Brown [this message]
2009-05-21 12:33     ` OT: busting a gut (was Re: Subject: [001/002 ] raid0 reshape) John Robinson
2009-05-21 19:20     ` Subject: [001/002 ] raid0 reshape Greg Freemyer
2009-05-25 12:19       ` Goswin von Brederlow
2009-05-25 20:06         ` Raz
2009-05-27 21:55           ` Bill Davidsen
2009-05-25 22:14         ` Neil Brown
2009-05-26 11:17           ` Goswin von Brederlow
2009-05-26 11:51             ` Neil Brown
2009-05-28 19:07               ` Goswin von Brederlow
2009-05-22  7:53     ` Dan Williams
2009-05-23 22:33     ` Raz

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=18965.16276.485692.812516@notabene.brown \
    --to=neilb@suse.de \
    --cc=Marcin.Labun@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=jacek.danecki@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=raziebe@013.net \
    /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).