Re: dm-writeboost: Progress Report

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

Hi, Paul,

> Would I be incorrect in assuming that this increased write performance comes
> with the trade-off of a greater risk of losing data in the case of power
> failure or crash?
Incorrect. Performance and Robustness are irrelevant if it's designed correctly.
Writeboost's log contains both data blocks (4KB * N) and corresponding metablock (16B for each).
After crash, it can replay the log on the cache device and it guarantees no data lost.
Like the usual block device, those data acked to write barrier (REQ_FUA or REQ_FLUSH) are
guaranteed not to be lost.

FYI,
The worst thing in using writeboost or even other cache softwares is that the cache device
gone out of order (which means it can neither read nor write anymore).
The filesystem doesn't go inconsistent (need not fsck) in that worst situation is writeboost's another characteristic.
Writeboost writes back the dirty data on the cache device in the same order they were written.
Therefore, if the cache device is gone we can at least obtain the filesystem of the moment the last
write-back was done.
Read this article for SSD failure (http://lkcl.net/reports/ssd_analysis.html)
SSDs are very likely to go insane. Use trustworthy SSD is my advice.

Considering these characteristics,
Maybe, we can call dm-writeboost "log-structured write buffer" rather than "log-structured caching".

Thanks for your interest,
Akira