[dm-devel] dm-writeboost: About inclusion into mainline

[Mike Snitzer]

On Wed, Nov 26 2014 at 10:02am -0500,
Akira Hayakawa <ruby.wktk at gmail.com> wrote:

> Hi,
> 
> I am wondering what's the next step of dm-writeboost, my log-structured SSD-caching driver.
> I want to discuss this.
> 
> I will start from introducing my activity on dm-writeboost.
> It was more than a year ago that I proposed my dm-writeboost for staging.
> Mike Snitzer, a maintainer of device-mapper, rejected it because dm-writeboost at that moment wasn't even suitable for staging.
> (http://www.redhat.com/archives/dm-devel/2013-September/msg00075.html)
> It is clear that the comment was really right. The code was actually terrible.
> Since then, with helps of DM guys, dm-writeboost's design and implementation has been polished.
> And it was included into Joe's linux-2.6 where he develops his drivers.
> (https://github.com/jthornber/linux-2.6/tree/thin-dev/drivers/md)
> I found some bugs and fixed them after this inclusion. I am confident the quality is good enough for staging.
> 
> Now, I can't find the way how I go over the wall.
> It seems that third party drivers are rarely merged into the md.
> The fact is, no third party driver (meaning proposed by other than RH) was included since I am involved with device-mapper, for 2 years.
> I am really afraid dm-writeboost will never be into the md ever after.
> 
> In one sense, this sounds too conservative. New features are always rejected. As a result, third party developers, including me, are losing their willingness.

You're painting with a really wide-brush here.  Both dm-verity and
dm-switch started out as targets from 3rd party developers (Google and
Dell/Equallogic respectively).  But while their feature was needed their
implementation was lacking, so Mikulas rewrote them before they were
included.

But yes, in general, I need to do better about getting to
review/inclusion of 3rd party DM targets.  I have my hands full
maintaining what DM targets we already have (not to mention DM core
itself).

It isn't just full targets (like DM dedup or DM lightnvm) that need
proper review.  It is also DM core changes like adding blk-mq support to
request-based DM.  Those changes are very much on my TODO.  DM dedup and
the blk-mq changes near the top!

But as you can see from what I've staged for 3.19 inclusion I haven't
been sitting around idle:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-for-3.19

Though you'll note that the focus of development has been on improving
both DM thinp and DM cache (and DM core as needed).  Those targets are
the bread winners from my perspective (lots of consumers and need for
enterprise stability).

All said, I _should_ be able to dedicate time to my backlog of DM review
tasks the first few weeks of Decemeber.  But sadly that doesn't include
time for dm-writeboost yet.

> As you know, developing driver is a hard work and spend lot of
> time. Actually, I spent hundreds or thousands of my private hours on
> my driver (hoping that my driver will be included and become famous)
> but I am almost giving up dm-writeboost if it has no hope. I know,
> storage softwares should become safe-side but I also know that
> willingness is the only key for non-paid development.

If you're looking for fame you're developing the wrong software.  You're
working on a well-worn software layer.

Upstream has both dm-cache and bcache.  Please demonstrate that
dm-writeboost offers an advantage over either of these already upstream
caching solutions with at least _some_ convincing benchmark data.

Mike