All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Marowsky-Bree <lmb@suse.de>
To: device-mapper development <dm-devel@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: mirroring: [patch 1 of 8] device failure tolerance
Date: Thu, 30 Jun 2005 13:33:53 +0200	[thread overview]
Message-ID: <20050630113353.GC31922@marowsky-bree.de> (raw)
In-Reply-To: <16a7b346170f3909d57592016a32abc0@redhat.com>

On 2005-06-29T13:07:49, Jonathan E Brassow <jbrassow@redhat.com> wrote:

> This patch defines a couple more states that logs can return, and 
> checks for those states in the mirror code.  The states are useful for 
> logs that have cluster support.

OK. Let me just ask one question, which I'll preface with the following:

I totally love the idea of md / DM convergence. I'm not yet quite clear
how this is to be achieved, but having two separate frameworks which at
least considerable overlap doesn't make sense - this isn't like two
filesystems, this is like two VFS layers and obviously silly. So, I
appreciate movement into that direction.

However, what's going on now is that features are being added to the DM
raid code, instead of figuring out a path of convergence.

RAID code takes, that's the experience we've got with Linux so far,
quite some time to stabilize. Duplicating it definetely doesn't seem
smart, if I may be so blunt. The RAID code in md is, nowadays, very
stable, and even already has patches for faster resync etc (merged in
-mm).

md is, in certain ways, more mature, which is exemplified by md's
ability to actually provide sane logging. DM has new cool features (like
the online remapping and stuff).

Why is the approach of reinventing a wheel with a slightly different
number of edges taken?

Is it believed that DM will supersede all aspects of md one day? Ain't
that slightly silly? ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

WARNING: multiple messages have this Message-ID (diff)
From: Lars Marowsky-Bree <lmb@suse.de>
To: device-mapper development <dm-devel@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [dm-devel] mirroring: [patch 1 of 8] device failure tolerance
Date: Thu, 30 Jun 2005 13:33:53 +0200	[thread overview]
Message-ID: <20050630113353.GC31922@marowsky-bree.de> (raw)
In-Reply-To: <16a7b346170f3909d57592016a32abc0@redhat.com>

On 2005-06-29T13:07:49, Jonathan E Brassow <jbrassow@redhat.com> wrote:

> This patch defines a couple more states that logs can return, and 
> checks for those states in the mirror code.  The states are useful for 
> logs that have cluster support.

OK. Let me just ask one question, which I'll preface with the following:

I totally love the idea of md / DM convergence. I'm not yet quite clear
how this is to be achieved, but having two separate frameworks which at
least considerable overlap doesn't make sense - this isn't like two
filesystems, this is like two VFS layers and obviously silly. So, I
appreciate movement into that direction.

However, what's going on now is that features are being added to the DM
raid code, instead of figuring out a path of convergence.

RAID code takes, that's the experience we've got with Linux so far,
quite some time to stabilize. Duplicating it definetely doesn't seem
smart, if I may be so blunt. The RAID code in md is, nowadays, very
stable, and even already has patches for faster resync etc (merged in
-mm).

md is, in certain ways, more mature, which is exemplified by md's
ability to actually provide sane logging. DM has new cool features (like
the online remapping and stuff).

Why is the approach of reinventing a wheel with a slightly different
number of edges taken?

Is it believed that DM will supersede all aspects of md one day? Ain't
that slightly silly? ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"


  reply	other threads:[~2005-06-30 11:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-29 18:07 mirroring: [patch 1 of 8] device failure tolerance Jonathan E Brassow
2005-06-30 11:33 ` Lars Marowsky-Bree [this message]
2005-06-30 11:33   ` [dm-devel] " Lars Marowsky-Bree
2005-06-30 15:13 ` Greg Freemyer
2005-06-30 15:38   ` Jonathan E Brassow
2005-06-30 16:38     ` Greg Freemyer
2005-06-30 18:00       ` Jonathan E Brassow

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=20050630113353.GC31922@marowsky-bree.de \
    --to=lmb@suse.de \
    --cc=dm-devel@redhat.com \
    --cc=linux-kernel@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 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.