Mike, thanks for reply, > 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 I see. > 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). It's not just improving DM thinp nor DM cache, neither bcache. In fact, they are orthogonal. I think dm-writeboost has reason to be included to compliment dm-cache. Other usage I have in my mind is for backup. The logs (or bunch of side-effects) dm-writeboost generates are chronologically serialized. Sending the logs to backup server for recovery could be a good role of my driver. > 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. There are two benchmark reports that I have posted. Unfortunately, both were ignored. 1) Feb, 2014 http://www.redhat.com/archives/dm-devel/2014-February/msg00000.html The first one is comparing with bcache. Joe mentioned that bcache is also good at write performance (http://www.redhat.com/archives/dm-devel/2014-January/msg00102.html) so I compare with it in terms of it. The result is positive. dm-writeboost can perform nearly seqwrite of the cache device when the incoming patten is random (that's because dm-writeboost is log-structured caching) that is, 3 times faster than bcache with the same workload. The results also shows, dm-writeboost is 5 times efficient than bcache in CPU consumption. 2) May, 2014 http://www.redhat.com/archives/dm-devel/2014-May/msg00052.html This time, I carried out with rather realistic benchmarks. I sent the summary as a split post. 234-299% improvement with dbench for example. http://www.redhat.com/archives/dm-devel/2014-May/msg00073.html These benchmarks are included in device-mapper-test-suite so that everyone can double-check. For these reports, please let me know if they doesn't make sense or you want to see with other particular tests. By the way, I think it's good time to propose for staging again so that not only you but also more developers can try dm-writeboost and give feedback. I know you are busy with other reviewing and not afford to review my driver but I want to merge my driver to main tree since I need more feedback to progress my work. The staging will be better for this situation. (or if you dig md/writeboost that would be appreciated) Your comments on my first proposal for staging were on the design problems. That was, my driver had external userland daemon and self-defined sysfs was pointed out too immature for staging. But for now, I think the design problems are all solved. The tests are in device-mapper-test-suite and the design of dmsetup commands are similar to dm-cache (which was your order, too). I will continue to push my tests to device-mapper-test-suite so that other guys can test my driver easily. - Akira On 11/27/14 12:28 AM, Mike Snitzer wrote: > On Wed, Nov 26 2014 at 10:02am -0500, > Akira Hayakawa <ruby.wktk@xxxxxxxxx> 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 > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
