linux-kernel - Re: [PATCH 04/16] DRBD: bitmap

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:	Tue, 05 May 2009 17:51:29 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Lars Marowsky-Bree <lmb@...e.de>
Cc:	Neil Brown <neilb@...e.de>,
	Lars Ellenberg <lars.ellenberg@...bit.com>,
	Philipp Reisner <philipp.reisner@...bit.com>,
	linux-kernel@...r.kernel.org, Jens Axboe <jens.axboe@...cle.com>,
	Greg KH <gregkh@...e.de>, Sam Ravnborg <sam@...nborg.org>,
	Dave Jones <davej@...hat.com>,
	Nikanth Karthikesan <knikanth@...e.de>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	Kyle Moffett <kyle@...fetthome.net>,
	Bart Van Assche <bart.vanassche@...il.com>
Subject: Re: [PATCH 04/16] DRBD: bitmap

On Tue, 2009-05-05 at 19:48 +0200, Lars Marowsky-Bree wrote:
> On 2009-05-03T15:21:41, Neil Brown <neilb@...e.de> wrote:
> 
> > As I said, I don't immediately see the benefits of the activity log
> > format, however,
> >  1/ I am happy to listen to its benefits being explained
> >  2/ If we were to agree that merging DRBD functionality into md
> >    (for which there isn't a concrete proposal, but the suggestion
> >     seems to be floating around) were a good thing, I don't have any
> >     problem with supporting an activity log in md in the name of
> >     compatibility.
> 
> So, let's take a step back here.
> 
> All of this is extremely beneficial discussion to be had. As some of you
> are (painfully, sometimes ;-) aware, I'm a big fan of converging RAID
> implementations/back-ends, and the goal is well received.
> 
> But this will take a while, and both drbd, md, md/nbd, or even dm-raid1
> have large existing user bases, and HA environments don't switch easily.
> All are actively maintained.
> 
> Sharing more and more of the code strikes me as a mid-term goal, and
> full converges as a long-term one (alas).
> 
> What I think this argument has shown that drbd's design is sound (even
> if some choices, like that of the alternatives, are up for discussion),
> similar to different file systems (of which we seem to have plenty
> too).
> 
> 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.
> 
> I think I've not read anything in the last 3-5 days which still would
> rate as a reason for rejection or delay.
> 
> Did I miss something?

No ... 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.

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/