linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: sander@humilis.net
Cc: NeilBrown <neilb@suse.de>,
	linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Steinar H. Gunderson" <sgunderson@bigfoot.com>
Subject: Re: [PATCH 000 of 5] md: Introduction
Date: Tue, 17 Jan 2006 14:26:11 +0300	[thread overview]
Message-ID: <43CCD453.9070900@tls.msk.ru> (raw)
In-Reply-To: <20060117095019.GA27262@localhost.localdomain>

Sander wrote:
> Michael Tokarev wrote (ao):
[]
>>Neil, is this online resizing/reshaping really needed? I understand
>>all those words means alot for marketing persons - zero downtime,
>>online resizing etc, but it is much safer and easier to do that stuff
>>'offline', on an inactive array, like raidreconf does - safer, easier,
>>faster, and one have more possibilities for more complex changes. It
>>isn't like you want to add/remove drives to/from your arrays every
>>day... Alot of good hw raid cards are unable to perform such reshaping
>>too.
[]
> Actually, I don't understand why you bother at all. One writes the
> feature. Another uses it. How would this feature harm you?

This is about code complexity/bloat.  It's already complex enouth.
I rely on the stability of the linux softraid subsystem, and want
it to be reliable. Adding more features, especially non-trivial
ones, does not buy you bugfree raid subsystem, just the opposite:
it will have more chances to crash, to eat your data etc, and will
be harder in finding/fixing bugs.

Raid code is already too fragile, i'm afraid "simple" I/O errors
(which is what we need raid for) may crash the system already, and
am waiting for the next whole system crash due to eg superblock
update error or whatnot.  I saw all sorts of failures due to
linux softraid already (we use it here alot), including ones
which required complete array rebuild with heavy data loss.

Any "unnecessary bloat" (note the quotes: I understand some
people like this and other features) makes whole system even
more fragile than it is already.

Compare this with my statement about "offline" "reshaper" above:
separate userspace (easier to write/debug compared with kernel
space) program which operates on an inactive array (no locking
needed, no need to worry about other I/O operations going to the
array at the time of reshaping etc), with an ability to plan it's
I/O strategy in alot more efficient and safer way...  Yes this
apprpach has one downside: the array has to be inactive.  But in
my opinion it's worth it, compared to more possibilities to lose
your data, even if you do NOT use that feature at all...

/mjt

  reply	other threads:[~2006-01-17 11:26 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 [this message]
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
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=43CCD453.9070900@tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=sander@humilis.net \
    --cc=sgunderson@bigfoot.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).