linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Ross Vandegrift <ross@jose.lug.udel.edu>,
	linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 000 of 5] md: Introduction
Date: Thu, 19 Jan 2006 11:22:31 +1100	[thread overview]
Message-ID: <17358.56263.806371.53617@cse.unsw.edu.au> (raw)
In-Reply-To: message from Michael Tokarev on Tuesday January 17

On Tuesday January 17, mjt@tls.msk.ru wrote:
> 
> As a sort of conclusion.
> 
> There are several features that can be implemented in linux softraid
> code to make it real Raid, with data safety goal.  One example is to
> be able to replace a "to-be-failed" drive (think SMART failure
> predictions for example) without removing it from the array with a
> (hot)spare (or just a replacement) -- by adding the new drive to the
> array *first*, and removing the to-be-replaced one only after new is
> fully synced.  Another example is to implement some NVRAM-like storage
> for metadata (this will require the necessary hardware as well, like
> eg a flash card -- I dunno how safe it can be).  And so on.

proactive replacement before complete failure is a good idea and is
(just recently) on my todo list.  It shouldn't be too hard.

> 
> The current MD code is "almost here", almost real.  It still has some
> (maybe minor) problems, it still lacks some (again maybe minor) features
> wrt data safety.  Ie, it still can fail, but it's almost here.

concrete suggestions are always welcome (though sometimes you might
have to put some effort into convincing me...)

> 
> While current development is going to implement some new and non-trivial
> features which are of little use in real life.  Face it: yes it's good
> when you're able to reshape your array online keeping servicing your
> users, but i'd go for even 12 hours downtime if i know my data is safe,
> instead of unknown downtime after I realize the reshape failed for some
> reason and I dont have my data anymore.  And yes it's very rarely used
> (which adds to the problem - rarely used code paths with bugs with stays
> unfound for alot of time, and bite you at a very unexpected moment, when
> you think it's all ok...)

If you look at the amount of code in the 'reshape raid5' patch you
will notice that it isn't really very much.  It reuses a lot of the
infrastructure that is already present in md/raid5.  So a reshape
actually uses a lot of code that is used very often.

Compare this to an offline solution (raidreconfig) where all the code
is only used occasionally.  You could argue that the online version
has more code safety than the offline version....

NeilBrown

  parent reply	other threads:[~2006-01-19  0:22 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-17  6:56 [PATCH 000 of 5] md: Introduction NeilBrown
2006-01-17  6:56 ` [PATCH 001 of 5] md: Split disks array out of raid5 conf structure so it is easier to grow NeilBrown
2006-01-17 14:37   ` John Stoffel
2006-01-19  0:26     ` Neil Brown
2006-01-21  3:37       ` John Stoffel
2006-01-22 22:57         ` Neil Brown
2006-01-17  6:56 ` [PATCH 002 of 5] md: Allow stripes to be expanded in preparation for expanding an array NeilBrown
2006-01-17  6:56 ` [PATCH 003 of 5] md: Infrastructure to allow normal IO to continue while array is expanding NeilBrown
2006-01-17  6:56 ` [PATCH 004 of 5] md: Core of raid5 resize process NeilBrown
2006-01-17  6:56 ` [PATCH 005 of 5] md: Final stages of raid5 expand code NeilBrown
2006-01-17  9:55   ` Sander
2006-01-19  0:32     ` Neil Brown
2006-01-17  8:17 ` [PATCH 000 of 5] md: Introduction Michael Tokarev
2006-01-17  9:50   ` Sander
2006-01-17 11:26     ` Michael Tokarev
2006-01-17 14:03       ` Kyle Moffett
2006-01-19  0:28         ` Neil Brown
2006-01-17 16:08       ` Ross Vandegrift
2006-01-17 18:12         ` Michael Tokarev
2006-01-18  8:14           ` Sander
2006-01-18  9:03             ` Alan Cox
2006-01-19  0:22           ` Neil Brown [this message]
2006-01-19  9:01             ` Jakob Oestergaard
2006-01-17 22:38       ` Phillip Susi
2006-01-17 22:57         ` Neil Brown
2006-01-17 14:10   ` Steinar H. Gunderson
2006-01-22  4:42 ` Adam Kropelin
2006-01-22 22:52   ` Neil Brown
2006-01-23 23:02     ` Adam Kropelin
2006-01-23  1:08 ` John Hendrikx
2006-01-23  1:25   ` Neil Brown
2006-01-23  1:54     ` Kyle Moffett
2006-01-17 21:38 Lincoln Dale (ltd)
2006-01-18 13:27 ` Jan Engelhardt
2006-01-18 23:19   ` Neil Brown
2006-01-19 15:33     ` Mark Hahn
2006-01-19 20:12     ` Jan Engelhardt
2006-01-19 21:22       ` Lars Marowsky-Bree
2006-01-19 22:17     ` Phillip Susi
2006-01-19 22:32       ` Neil Brown
2006-01-19 23:26         ` Phillip Susi
2006-01-19 23:43           ` Neil Brown
2006-01-20  2:17             ` Phillip Susi
2006-01-20 10:53               ` Lars Marowsky-Bree
2006-01-20 12:06                 ` Jens Axboe
2006-01-20 18:38                 ` Heinz Mauelshagen
2006-01-20 22:09                   ` Lars Marowsky-Bree
2006-01-21  0:06                     ` Heinz Mauelshagen
2006-01-20 18:41               ` Heinz Mauelshagen
2006-01-20 17:29             ` Ross Vandegrift
2006-01-20 18:36             ` Heinz Mauelshagen
2006-01-20 22:57               ` Lars Marowsky-Bree
2006-01-21  0:01                 ` Heinz Mauelshagen
2006-01-21  0:03                   ` Lars Marowsky-Bree
2006-01-21  0:08                     ` Heinz Mauelshagen
2006-01-21  0:13                       ` Lars Marowsky-Bree
2006-01-23  9:44                         ` Heinz Mauelshagen
2006-01-23 10:26                           ` Lars Marowsky-Bree
2006-01-23 10:38                             ` Heinz Mauelshagen
2006-01-23 10:45                               ` Lars Marowsky-Bree
2006-01-23 11:00                                 ` Heinz Mauelshagen
2006-01-23 12:54                           ` Ville Herva
2006-01-23 13:00                             ` Steinar H. Gunderson
2006-01-23 13:54                             ` Heinz Mauelshagen
2006-01-23 17:33                               ` Ville Herva
2006-01-24  2:02                             ` Phillip Susi
2006-01-20 16:48 Hubert Tonneau
2006-01-20 17:01 Hubert Tonneau
2006-01-20 16:15 ` Christoph Hellwig
2006-01-22  6:45   ` Herbert Poetzl
2006-01-20 18:05 Hubert Tonneau

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=17358.56263.806371.53617@cse.unsw.edu.au \
    --to=neilb@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    --cc=ross@jose.lug.udel.edu \
    /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).