[dm-devel] dm-writeboost: Progress Report

[Akira Hayakawa]

Hi, Joe,

> Do you have any benchmarks yet?  Which situations does it out perform
> bcache and dm-cache?
Yes, I do.
Writeboost outperforms other cache softwares in case of bursty random writes.
With the fio script below, dm-writeboost recorded a throughput as high as the
sequential write throughput of the cache device (259MB/266MB. only 3% loss).
This is because Writeboost makes a log on the RAM and writes it out to the
cache device in sequential manner. I don't think other cache softwares can achieve
this high level of throughput.

[global]
filename=/dev/mapper/perflv
randrepeat=1
ioengine=libaio
bs=4k
ba=4k
size=16GB
direct=1
gtod_reduce=1
norandommap
iodepth=64
stonewall

[perf]
rw=randwrite


Unfortunately, I don't have any results with synthetic workload emulates databases
or file servers. But, it is easy to imagine Writeboost can improve them if they are
backed by RAID-ed storage whose writes are really slow compared to read with
typical RAID mode like RAID-5.
Since our softwares are just providing "caching" choosing one as the silver bullet
is just a fantasy. Since Writeboost provides really a peculiar caching there must be
some situations that Writeboost is the best.

To tell the truth, I don't have any more equipments to have benchmark more. Why I
need my software in the tree is not only to have the "many eyes" on my code to improve
the quality but also to have Writeboost participate in public benchmark
(like this http://www.accelcloud.com/2012/04/18/linux-flashcache-and-bcache-performance-testing/).

Beside the performance, please consider the compact codebase of Writeboost. As a writeback
caching it should be as simple as possible to reduce potential bugs.

By the way, Writeboost improves only writes so if you need more improvement on reads
you can stack dm-cache (write-through) under dm-writeboost. They are orthogonal.
dm-cache seems to be good for read caching.

For read caching, I have an another plan to develop separate cache module that, on the other hand,
purely focuses on improving reads. I have a name "dm-readboost" in my mind.
Since write cache and read cache require different data structures and controls they should be separated.
So, if dm-cache can be simpler and optimized by deleting the support for writeback mode I really prefer it.

>> 5. Add regression tests under testing/ of my Github tree
>> --------------------------------------------------------
>> Joe's test-suite is really well-designed but it has too many things before stand-by.
> 
> I'm not sure what you mean here?
device-mapper-test-suite is a flexible framework but it has too many dependencies outside Ruby.

Akira