linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: Wil Reichert <wil.reichert@gmail.com>
Cc: NeilBrown <neilb@suse.de>, linux-raid@vger.kernel.org
Subject: Re: [PATCH 00/18] Assorted md patches headed for 2.6.30
Date: Thu, 12 Feb 2009 18:44:22 +0100	[thread overview]
Message-ID: <20090212174422.GA20703@rap.rap.dk> (raw)
In-Reply-To: <7a329d910902120728u146e7cddk6e7d990668c16345@mail.gmail.com>

On Thu, Feb 12, 2009 at 07:28:59AM -0800, Wil Reichert wrote:
> On Thu, Feb 12, 2009 at 2:45 AM, NeilBrown <neilb@suse.de> wrote:
> > On Thu, February 12, 2009 8:53 pm, Keld Jørn Simonsen wrote:
> >> On Thu, Feb 12, 2009 at 08:21:12PM +1100, NeilBrown wrote:
> >>> On Thu, February 12, 2009 7:11 pm, Keld Jørn Simonsen wrote:
> >>> > On Thu, Feb 12, 2009 at 02:10:10PM +1100, NeilBrown wrote:
> >>> >> Comments and testing very welcome.
> >>> >
> >>> > I would rather have functionality to convert raid10 to raid5.
> >>> > raid1 should be depreciated, as raid10,n2 for all purposes is the same
> >>> > but better implementation and performance, and raid10,f2 and raid10,o2
> >>> > are even better.  Nobody should use raid1 anymore.
> >>>
> >>> That is a fairly simplistic view.
> >>
> >> It was also formulated to provoke some thoughts.
> >>
> >>> raid1 supports --write-mostly and --write-behind which raid10 is
> >>> unlikely
> >>> ever to support.
> >>
> >> why?
> >>
> >> Anyway would it not be possible that this functionality be implemented
> >> for raid10,n2?
> >
> > It would be possible, but it might not be sensible.
> >
> > write-mostly and write-behind only really make sense when you have the
> > clear distinction between drives that raid1 gives you.
> > These options don't make sense for raid10 in general.  Only in very specific
> > layouts.
> > If you like, raid1 is an implementation of a specific raid10 layout,
> > where it makes sense to add some extra functionality.
> >
> >>
> >> Some code to grow raid10 would also be desirable. Maybe it is some of
> >> the same operations that need to be applied: getting the old data in,
> >> have it restructured for the new format, in a safe way, and possibly
> >> with the help of an extra disk, or possibly not. It sounds non-trivial
> >> to me too.
> >
> > What particular growth scenarios are you interested it?
> > Just adding a drive and restriping onto that?  i.e keep that
> > same nominal layout but increase 'raid-disks'?
> >
> > That would be quite similar to the raid5 grow operation so it shouldn't
> > be too hard to achieve.
> > A 'grow' which changed the layout (e.g. near to far) would be a lot
> > harder.
> 
> I'd previously seen the wikipedia article regarding Linux RAID10 and
> its mention of the 3 disk case.  Out of academic curiousity, how does
> the 2 disk RAID10 work?  Is it just a matter of have 2 identical
> volumes and reading subsequent stripes from the alteranate drives?  Or
> is the algorithm more complicated?

There are 3 different layouts for raid10: near, far and offset.
Basically raid10 with 2 disks works as RAID 1 - and "near" and linux
raid1 is almost equivalent. far and offset has somewhat different
placements of blocks on the disks, which should lead to faster operation
for some common tasks.

best regards
keld
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-02-12 17:44 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-12  3:10 [PATCH 00/18] Assorted md patches headed for 2.6.30 NeilBrown
2009-02-12  3:10 ` [PATCH 03/18] md: occasionally checkpoint drive recovery to reduce duplicate effort after a crash NeilBrown
2009-02-12 17:26   ` John Stoffel
2009-02-13 16:20   ` Bill Davidsen
2009-02-13 16:34     ` Jon Nelson
2009-02-12  3:10 ` [PATCH 07/18] md/raid5: simplify interface for init_stripe and get_active_stripe NeilBrown
2009-02-12  3:10 ` [PATCH 08/18] md/raid5: change raid5_compute_sector and stripe_to_pdidx to take a 'previous' argument NeilBrown
2009-02-12  3:10 ` [PATCH 02/18] md: write bitmap information to devices that are undergoing recovery NeilBrown
2009-02-12  3:10 ` [PATCH 06/18] md: Represent raid device size in sectors NeilBrown
2009-02-12  3:10 ` [PATCH 05/18] md: Make mddev->size sector-based NeilBrown
2009-02-12  3:10 ` [PATCH 04/18] md: be more consistent about setting WriteMostly flag when adding a drive to an array NeilBrown
2009-02-12  3:10 ` [PATCH 01/18] md: never clear bit from the write-intent bitmap when the array is degraded NeilBrown
2009-02-12  3:10 ` [PATCH 13/18] md/raid5: refactor raid5 "run" NeilBrown
2009-02-12  3:10 ` [PATCH 11/18] md/raid5: Add support for new layouts for raid5 and raid6 NeilBrown
2009-02-12  3:10 ` [PATCH 17/18] md: add ->takeover method for raid5 to be able to take over raid1 NeilBrown
2009-02-12  3:10 ` [PATCH 12/18] md/raid5: finish support for DDF/raid6 NeilBrown
2009-02-12  3:10 ` [PATCH 18/18] md/raid5: allow layout/chunksize to be changed on an active2-drive raid5 NeilBrown
2009-02-12  3:10 ` [PATCH 16/18] md: add ->takeover method to support changing the personality managing an array NeilBrown
2009-02-12  3:10 ` [PATCH 15/18] md: hopefully enable suspend/resume of md devices NeilBrown
2009-02-12  3:10 ` [PATCH 10/18] md/raid5: simplify raid5_compute_sector interface NeilBrown
2009-02-12  3:10 ` [PATCH 09/18] md/raid6: remove expectation that Q device is immediately after P device NeilBrown
2009-02-12 16:56   ` Andre Noll
2009-02-13 22:19     ` Dan Williams
2009-02-16  0:08     ` Neil Brown
2009-02-13 16:37   ` Bill Davidsen
2009-02-16  5:15     ` Neil Brown
2009-02-12  3:10 ` [PATCH 14/18] md: md_unregister_thread should cope with being passed NULL NeilBrown
2009-02-12  8:11 ` [PATCH 00/18] Assorted md patches headed for 2.6.30 Keld Jørn Simonsen
2009-02-12  9:13   ` Steve Fairbairn
2009-02-12  9:46     ` Keld Jørn Simonsen
2009-02-12 10:52       ` NeilBrown
2009-02-12 11:16         ` Keld Jørn Simonsen
2009-02-12 10:53       ` Julian Cowley
2009-02-13 16:54         ` Bill Davidsen
2009-02-16  5:35           ` Neil Brown
2009-02-16 17:31             ` Nagilum
2009-02-12 22:57     ` Dan Williams
2009-02-13 16:56     ` Bill Davidsen
2009-02-12  9:21   ` NeilBrown
2009-02-12  9:53     ` Keld Jørn Simonsen
2009-02-12 10:45       ` NeilBrown
2009-02-12 11:11         ` Keld Jørn Simonsen
2009-02-12 15:28         ` Wil Reichert
2009-02-12 17:44           ` Keld Jørn Simonsen [this message]
2009-02-12  9:42 ` Farkas Levente
2009-02-12 10:40   ` NeilBrown
2009-02-12 11:17     ` Farkas Levente
2009-02-13 17:02       ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2009-03-10  8:24 jzc-sina
     [not found] <7554605.886551236670855947.JavaMail.coremail@bj163app40.163.com>
2009-03-13  1:00 ` 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=20090212174422.GA20703@rap.rap.dk \
    --to=keld@dkuug.dk \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=wil.reichert@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 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).