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:	Fri, 18 Sep 2009 22:08:03 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Neil Brown <neilb@...e.de>
Cc:	Christoph Hellwig <hch@...radead.org>,
	James Bottomley <James.Bottomley@...e.de>,
	Lars Ellenberg <lars.ellenberg@...bit.com>,
	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>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Kyle Moffett <kyle@...fetthome.net>,
	Lars Marowsky-Bree <lmb@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"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 Fri, Sep 18 2009, Neil Brown wrote:
> On Thursday September 17, hch@...radead.org wrote:
> > On Thu, Sep 17, 2009 at 10:02:45AM -0600, James Bottomley wrote:
> > > 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.
> > 
> > Yes.  RDBD has spend tons of time out of tree, and if they want to put
> > it in now I think requiring them to do their homework is a good idea.
> 
> What homework?
> 
> If there was a sensible unifying framework in the kernel that they
> could plug in to, then requiring them do to that might make sense.  But
> there isn't.  You/I/We haven't created a solution (i.e. there is no
> equivalent of the VFS for virtual block devices) and saying that
> because we haven't they cannot merge DRBD hardly seems fair.
> 
> Indeed, merging DRBD must be seen as a *good* thing as we then have
> more examples of differing requirements against which a proposed
> solution can be measured and tested.
> 
> I thought the current attitude was "merge then fix".  That is what the
> drivers/staging tree seems to be all about.  Maybe you could argue
> that DRBD should go in to 'staging' first (though I don't think that
> is appropriate or require myself), but keeping it out just seems
> wrong.

FWIW, I agree with Neil here. If drbd is merge clean, lets go ahead and
merge it. While it would be nice to offload the raid unification onto
drbd, it's not exactly fair.

-- 
Jens Axboe

--
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/