linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: James Lee <james.lee@cantab.net>
Cc: Bill Davidsen <davidsen@tmr.com>, linux-raid@vger.kernel.org
Subject: Re: Proposal: non-striping RAID4
Date: Thu, 15 Nov 2007 17:01:02 +1100	[thread overview]
Message-ID: <18235.57502.462218.1934@notabene.brown> (raw)
In-Reply-To: message from James Lee on Thursday November 15

On Thursday November 15, james.lee@cantab.net wrote:
> 
> Neil: any comments on whether this would be desirable / useful / feasible?

1/ Have in raid4 variant which arranges the data like 'linear' is
   something I am planning to do eventually.  If your filesystem nows
   about the geometry of the array , then it can distribute the data
   across the drives and can make up for a lot of the benefits of
   striping.  The big advantage of such an arrangement is that it is
   trivial to add a drive - just zero it and make it part of the
   array.  No need to re-arrange what is currently there.
   However I was not thinking of support different sizes devices in
   such a configuration.

2/ Having an array with redundancy where drives are of different sizes
   is awkward, primarily because if there was a spare that as not as
   large as the largest device, you may-or-may not be able to rebuild
   in that situation.   Certainly I could code up those decisions, but
   I'm not sure the scenario is worth the complexity.
   If you have drives of different sizes, use raid0 to combine pairs
   of smaller one to match larger ones, and do raid5 across devices
   that look like the same size.

3/ If you really want to use exactly what you have, you can partition
   them into bits and make a variety of raid5 arrays as you suggest.
   md will notice and will resync in series so that you don't kill
   performance.

NeilBrown

  reply	other threads:[~2007-11-15  6:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-10  0:57 Proposal: non-striping RAID4 James Lee
2007-11-12  1:29 ` Bill Davidsen
2007-11-13 23:48   ` James Lee
2007-11-14  1:06     ` James Lee
2007-11-14 23:16       ` Bill Davidsen
2007-11-15  0:24         ` James Lee
2007-11-15  6:01           ` Neil Brown [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-11-23 15:58 Chris Green
2008-05-22 21:15 Tony Germano
2008-05-22 22:10 ` David Lethe
2008-05-22 22:56   ` Tony Germano
2008-05-23 15:12 ` Roger Heflin
2008-05-23 15:47 ` Chris Green
2008-05-24 14:21   ` Bill Davidsen
2008-05-24 14:19     ` Chris Green
2008-05-28 23:14       ` Bill Davidsen
2008-05-30 17:23         ` Tony Germano

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=18235.57502.462218.1934@notabene.brown \
    --to=neilb@suse.de \
    --cc=davidsen@tmr.com \
    --cc=james.lee@cantab.net \
    --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).