[Drbd-dev] [GIT PULL] DRBD for 2.6.32
lars.ellenberg at linbit.com
Thu Sep 17 10:12:51 CEST 2009
I took the liberty to extend the CC list again a little bit.
On Tue, Sep 15, 2009 at 07:19:31PM -0400, Christoph Hellwig wrote:
> On Tue, Sep 15, 2009 at 04:45:13PM +0200, Philipp Reisner wrote:
> > Hi Linus,
> > Please pull
> > git://git.drbd.org/linux-2.6-drbd.git drbd
> > DRBD is a shared-nothing, replicated block device. It is designed to
> > serve as a building block for high availability clusters and
> > in this context, is a "drop-in" replacement for shared storage.
> > It has been discussed and reviewed on the list since March,
> > and Andrew has asked us to send a pull request for 2.6.32-rc1.
This has been discussed before on LKML.
To contrast your NACK by a few previous posts
I perceived effectively as ACKS:
"Oh. Thanks. Well we should all get cracking on it then."
"I would suggest at this time, we may want to refocus on the remaining
objections to merging drbd as a driver in the short-term."
In reply to that,
"I'd agree with that. drbd essentially qualifies as a
driver under our new merge rules, so we should be
thinking about blockers to getting it into the tree
first (serious issues) and working out kinks
(like raid unification) after it gets in."
"I cannot imagine that there would be any. Given its
history, its popularity, and its modularity, there can
be no question about merging it"
> The last thing we need is another bloody raid-reimplementation,
It is not RAID, it is replication, see also that blog post below.
> coupled with a propritary on the wire protocol.
"the mode of presentation of its data is opaque
and its specification is not publicly available"
Which does not apply to DRBD.
So lets settle for "homegrown".
Besides, what was the non-proprietary, generally accepted,
link layer agnostic block-level replication protocol again?
And in case you're referring to MD/NBD or MD/iSCSI or some such,
http://fghaas.wordpress.com/2009/09/16/alternatives-to-drbd/ may be a
worthy read. Certainly not deeply technical, but sufficient to
illustrate the most important points.
> NACK as far as I am concerned.
Too bad :(
What can we do to have that revised?
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
More information about the drbd-dev