All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: thomas@fjellstrom.ca
Cc: linux-raid@vger.kernel.org
Subject: Re: potentially lost largeish raid5 array..
Date: Sun, 25 Sep 2011 19:37:47 +1000	[thread overview]
Message-ID: <20110925193747.074d965b@notabene.brown> (raw)
In-Reply-To: <201109231026.53770.thomas@fjellstrom.ca>

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

On Fri, 23 Sep 2011 10:26:53 -0600 Thomas Fjellstrom <thomas@fjellstrom.ca>
wrote:

> On September 23, 2011, NeilBrown wrote:
> > On Fri, 23 Sep 2011 02:09:36 -0600 Thomas Fjellstrom <thomas@fjellstrom.ca>
> > 
> > wrote:
> > > I forgot to say, but: Thank you very much :) for the help, and your
> > > tireless work on md.
> > 
> > You've very welcome .... but I felt I needed to respond to that word
> > "tireless".
> > The truth is that I am getting rather tired of md .... if anyone knows
> > anyone who wants to get into kernel development and is wondering where to
> > start - please consider whispering 'the md driver' in their ear.  Plenty
> > to do, great mentoring possibilities, and competent linux kernel engineers
> > with good experience are unlikely to have much trouble finding a job ;-)
> > 
> > NeilBrown
> 
> Very tempting. How much work do you think it would be to add in full raid10 
> reshape support? ;D (not that I'm volunteering, I don't think I could 
> comprehend a lot of the raid code, at least not at this point in time  
> (extenuating circumstances)).
> 

RAID10 reshape is more complicated than RAID5/6 reshape because there are
more options - more combinations.

So you would probably implement a subset of possible reshapes.  And then
maybe implement another subset.

Providing you have:
  - a clear understanding of the intermediate state and a way to record
    that state in the metadata
  - a way to tell if a given block is in the 'old' layout or the 'new' layout
    or 'being reshaped'
  - somewhere in memory to store all the blocks that are 'being reshaped'

it should be fairly easy.  RAID5/6 has a stripe-cache so the last point is
trivial.  Handling that in RAID10 is probably the biggest single part of the
task.

So: not a trivial task, but not an enormous task either.... which doesn't
narrow it down very much I guess.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

  reply	other threads:[~2011-09-25  9:37 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-23  1:50 potentially lost largeish raid5 array Thomas Fjellstrom
2011-09-23  4:32 ` NeilBrown
2011-09-23  4:49   ` Thomas Fjellstrom
2011-09-23  4:58     ` Roman Mamedov
2011-09-23  5:10       ` Thomas Fjellstrom
2011-09-23  7:06         ` David Brown
2011-09-23  7:37           ` Thomas Fjellstrom
2011-09-23 12:56         ` Stan Hoeppner
2011-09-23 13:28           ` David Brown
2011-09-23 16:22           ` Thomas Fjellstrom
2011-09-23 23:24             ` Stan Hoeppner
2011-09-24  0:11               ` Thomas Fjellstrom
2011-09-24 12:17                 ` Stan Hoeppner
2011-09-24 13:11                   ` (unknown) Tomáš Dulík
2011-09-24 15:16                   ` potentially lost largeish raid5 array David Brown
2011-09-24 16:38                     ` Stan Hoeppner
2011-09-25 13:03                       ` David Brown
2011-09-25 14:39                         ` Stan Hoeppner
2011-09-25 15:18                           ` David Brown
2011-09-25 23:58                             ` Stan Hoeppner
2011-09-26 10:51                               ` David Brown
2011-09-26 19:52                                 ` Stan Hoeppner
2011-09-26 20:29                                   ` David Brown
2011-09-26 23:28                                   ` Krzysztof Adamski
2011-09-27  3:53                                     ` Stan Hoeppner
2011-09-24 17:48                   ` Thomas Fjellstrom
2011-09-24  5:59             ` Mikael Abrahamsson
2011-09-24 17:53               ` Thomas Fjellstrom
2011-09-25 18:07           ` Robert L Mathews
2011-09-26  6:08             ` Mikael Abrahamsson
2011-09-26  2:26           ` Krzysztof Adamski
2011-09-23  5:11     ` NeilBrown
2011-09-23  5:22       ` Thomas Fjellstrom
2011-09-23  8:09         ` Thomas Fjellstrom
2011-09-23  9:15           ` NeilBrown
2011-09-23 16:26             ` Thomas Fjellstrom
2011-09-25  9:37               ` NeilBrown [this message]
2011-09-24 21:57             ` Aapo Laine
2011-09-25  9:18               ` Kristleifur Daðason
2011-09-25 10:10               ` NeilBrown
2011-10-01 23:21                 ` Aapo Laine
2011-10-02 17:00                   ` Aapo Laine
2011-10-05  2:13                     ` NeilBrown
2011-10-05  2:06                   ` NeilBrown
2011-11-05 12:17                 ` Alexander Lyakas
2011-11-06 21:58                   ` NeilBrown

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=20110925193747.074d965b@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=thomas@fjellstrom.ca \
    /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.