linux-kernel - Re: [GIT PULL] DRBD for 2.6.32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Sep 2009 10:02:45 -0600
From:	James Bottomley <James.Bottomley@...e.de>
To:	Lars Ellenberg <lars.ellenberg@...bit.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, drbd-dev@...ts.linbit.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bart Van Assche <bart.vanassche@...il.com>,
	Dave Jones <davej@...hat.com>, Greg KH <gregkh@...e.de>,
	Jens Axboe <jens.axboe@...cle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Kyle Moffett <kyle@...fetthome.net>,
	Lars Marowsky-Bree <lmb@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Neil Brown <neilb@...e.de>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	Nikanth Karthikesan <knikanth@...e.de>,
	Philipp Reisner <philipp.reisner@...bit.com>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [GIT PULL] DRBD for 2.6.32

On Thu, 2009-09-17 at 10:12 +0200, Lars Ellenberg wrote:
> 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:
> e.g.
> 
> Andrew Morton:
> http://lkml.org/lkml/2009/5/1/307
> 
> 	"Oh.  Thanks.  Well we should all get cracking on it then."
> 
> Lars Marowsky-Bree:
> http://lkml.org/lkml/2009/5/5/224
> 
> 	"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,
> 
> 	James Bottomley:
> 	http://lkml.org/lkml/2009/5/5/226
> 
> 		"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."
> 
> 	Neil Brown:
> 	http://lkml.org/lkml/2009/5/5/332
> 
> 		"I cannot imagine that there would be any. Given its
> 		history, its popularity, and its modularity, there can
> 		be no question about merging it"
> 
> hch:
> > 
> > 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.
> 
> http://www.openformats.org/en1
> proprietary:
> "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?

So I think Christoph's NAK is rooted in the fact that we have a
proliferation of in-kernel RAID implementations and he's trying to
reunify them all again.

As part of the review, reusing the kernel RAID (and actually logging)
logic did come up and you added it to your todo list.  Perhaps expanding
on the status of that would help, since what's being looked for is that
you're not adding more work to the RAID reunification effort and that
you do have a plan and preferably a time frame for coming into sync with
it.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/