From: david@lang.hm
To: David Greaves <david@dgreaves.com>
Cc: Paul Clements <paul.clements@steeleye.com>,
Jan Engelhardt <jengelh@computergmbh.de>,
Al Boldi <a1426z@gawab.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
netdev@vger.kernel.org, linux-raid@vger.kernel.org
Subject: Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
Date: Mon, 13 Aug 2007 01:31:24 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0708130127260.22470@asgard.lang.hm> (raw)
In-Reply-To: <46C01052.4050708@dgreaves.com>
On Mon, 13 Aug 2007, David Greaves wrote:
> david@lang.hm wrote:
>> per the message below MD (or DM) would need to be modified to work
>> reasonably well with one of the disk components being over an unreliable
>> link (like a network link)
>>
>> are the MD/DM maintainers interested in extending their code in this
>> direction? or would they prefer to keep it simpler by being able to
>> continue to assume that the raid components are connected over a highly
>> reliable connection?
>>
>> if they are interested in adding (and maintaining) this functionality then
>> there is a real possibility that NBD+MD/DM could eliminate the need for
>> DRDB. however if they are not interested in adding all the code to deal
>> with the network type issues, then the argument that DRDB should not be
>> merged becouse you can do the same thing with MD/DM + NBD is invalid and
>> can be dropped/ignored
>>
>> David Lang
>
> As a user I'd like to see md/nbd be extended to cope with unreliable links.
> I think md could be better in handling link exceptions. My unreliable memory
> recalls sporadic issues with hot-plug leaving md hanging and certain lower
> level errors (or even very high latency) causing unsatisfactory behaviour in
> what is supposed to be a fault 'tolerant' subsystem.
>
>
> Would this just be relevant to network devices or would it improve support
> for jostled usb and sata hot-plugging I wonder?
good question, I suspect that some of the error handling would be similar
(for devices that are unreachable not haning the system for example), but
a lot of the rest would be different (do you really want to try to
auto-resync to a drive that you _think_ just reappeared, what if it's a
different drive? how can you be sure?) the error rate of a network is gong
to be significantly higher then for USB or SATA drives (although I suppose
iscsi would be limilar)
David Lang
next prev parent reply other threads:[~2007-08-13 8:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-12 10:35 [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid]) Al Boldi
2007-08-12 11:28 ` Jan Engelhardt
2007-08-12 16:39 ` david
2007-08-12 17:03 ` Jan Engelhardt
2007-08-12 17:45 ` Iustin Pop
2007-08-13 1:41 ` Paul Clements
2007-08-13 3:21 ` david
2007-08-13 8:03 ` David Greaves
2007-08-13 8:31 ` david [this message]
2007-08-13 12:43 ` David Greaves
2007-08-13 9:02 ` Jan Engelhardt
2007-08-13 7:51 ` David Greaves
2007-08-12 11:51 ` Evgeniy Polyakov
2007-08-12 15:28 ` Al Boldi
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=Pine.LNX.4.64.0708130127260.22470@asgard.lang.hm \
--to=david@lang.hm \
--cc=a1426z@gawab.com \
--cc=david@dgreaves.com \
--cc=jengelh@computergmbh.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul.clements@steeleye.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).