lkml.org 
[lkml]   [2013]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Bcache v. whatever
On Tue, Jan 15, 2013 at 11:15:38PM +0000, James Bottomley wrote:
> I think md integration would be a bit of a mistake, since md is pretty
> much only a raid engine at this point in time. There are also a couple
> of other dm cache targets, so it would be nice to have one rather than
> three. This all, however, seems to be under discussion on the dm list.

The raid vs. caching bit is a bit beside the point IMO; they both
aggregate block devices and expose virtual block devices, and the
mechanism for doing so isn't part of the generic framework.

I'm not morally opposed to dm integration, I'm just more comfortable
with the md code and find it easier to understand and work with.

And the goal I care about is just commonality of userspace interfaces
and tooling, which integration with either would accomplish.

> > So I'm not sure why it'd go in via dm, it seems to me it'd make just as
> > much sense for it to go in via Neil Brown's tree. Unless there's
> > something I'm missing?
>
> Um, well there's no caching patches in the md tree; it's RAID only. The
> basic caching stuff is all in the dm tree, which is why it's the natural
> one.
>
> It seems to me that your stuff is progressing on the dm list, so I don't
> really see a need to circumvent the process in the dm tree ... unless
> there's some problem I'm not seeing?

I haven't been active on dm-devel, besides the occasional cross
posting... not sure what activity you're referring to on the dm list,

But if Alasdair wants to pick it up I'm not complaining, I don't
particularly care who merges it.


\
 
 \ /
  Last update: 2013-01-16 01:41    [W:0.071 / U:2.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site