Re: staging: writeboost: Add dm-writeboost

[Akira Hayakawa <ruby.wktk@gmail.com>]

Hi,

> BUT if you'd still like dm-writeboost to go into staging
> _without_ any of these 5 work items being completed I'll ack it but to
> be very clear: dm-writeboost will not migrate out of staging until these
> items are resolved.
Yes. I will go into staging.
Greg, I will send you a patch with some fixes on TODO.

I agree with the 5 work times to be done for md.
I add some comments below,

>> i) Get this test so it's performance is similar to raw spindle.
Yes.

>> ii) Write good documentation in Documentation/device-mapper/.  eg. How
>>     do I remove a cache?  When should I use dm-writeboost rather than
>>     bcache or dm-cache?
>>
>> iii) Provide an equivalent to the fsck tool to repair a damaged cache.
OK. I took a look at tools for DM-cache.
I will implement something similar.
But please remember, since Writeboost is log-structured fsck tools aren't essentially needed.
On power failure, some logs at the head may be half done and discarding these logs can roll the state back.

>  iv) perform full code review to catch various implementation issues,
>      any style nits, etc.
>  v) explore/implement read caching support (could the lack of read
>     caching be contributing to why the git_extract test is so poor?)
This will be my first work in staging.

- Akira

On 12/10/14 12:48 AM, Mike Snitzer wrote:
> On Tue, Dec 09 2014 at 10:12am -0500,
> Joe Thornber <thornber@redhat.com> wrote:
> 
>> On Mon, Dec 08, 2014 at 06:04:41AM +0900, Akira Hayakawa wrote:
>>> Mike and Alasdair,
>>> I need your ack
>>
>> Hi Akira,
>>
>> I just spent some time playing with your latest code.  On the positive
>> side I am seeing some good performance with the fio tests.  Which is
>> great, we know your design should outperform dm-cache with small
>> random io.
>>
>> However I'm still getting v. poor results with the git-extract test,
>> which clones a linux kernel repo, and then checks out 5 revisions, all
>> with drop_caches in between.
> 
> Thanks for re-evaluating dm-writeboost performance Joe.
> 
>> It's fine to have different benefits of the caching software depending
>> on the load.  But I think the worst case should always be close to the
>> performance of the raw spindle device.
>>
>> If you get the following work items done I will ack to go upstream:
>>
>> i) Get this test so it's performance is similar to raw spindle.
>>
>> ii) Write good documentation in Documentation/device-mapper/.  eg. How
>>     do I remove a cache?  When should I use dm-writeboost rather than
>>     bcache or dm-cache?
>>
>> iii) Provide an equivalent to the fsck tool to repair a damaged cache.
> 
> I agree with this TODO list.  But I'd also add:
>  iv) perform full code review to catch various implementation issues,
>      any style nits, etc.
> 
>  v) explore/implement read caching support (could the lack of read
>     caching be contributing to why the git_extract test is so poor?)
> 
> Item iv) would be a task for myself and anyone else interested in
> getting dm-writeboost ready for inclusion.  Akira, I can start working
> on dm-writeboost code review once I complete review of the dm-dedup
> target (my current priority) -- but realistically that likely won't be
> until the new year.
> 
> BTW, I'm really not seeing much point putting dm-writeboost in staging.
> I'd be happy to take dm-writeboost into drivers/md/ once the above list
> is resolved.  BUT if you'd still like dm-writeboost to go into staging
> _without_ any of these 5 work items being completed I'll ack it but to
> be very clear: dm-writeboost will not migrate out of staging until these
> items are resolved.
> 
> Thanks,
> Mike
>