Messages in this thread | | | Date | Wed, 10 Dec 2014 19:21:13 +0900 | From | Akira Hayakawa <> | Subject | Re: staging: writeboost: Add dm-writeboost |
| |
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 >
| |