Frequently asked Q&A

This is list of very frequent questions and the answers to them.

Q1. I recreate the writeboost'd device the second time and it's too slow
A. Writeboost is log-structured caching. Since it's log-structured, it requires "log-replay" at the startup to reconstruct the in-memory metadata from the logs and also validate the logs (each has checksum). The spending time of log-replay is mostly proportional to the size of the caching device. It may take hours in case the caching device is huge but I have no priority to optimize the log-replay algorithm. This may first sound disappointing to you but since storage server maintenance is really occasional and maintenance typically includes other tasks, taking hours to restart isn't much to care. Since the awesome performance and the safety of writeboost is given by the log-structured nature, the shortcoming is negligible.

Q2. Can't create a writeboost'd device
A. This is typically because you forgot to have the first sector of caching device zeroed out before first constructing the writeboost'd device. By zeroing out the sector, writeboost reformats the caching device in initialization. Note don't do this when you rebuild the writeboost'd device otherwise the cached data are all gone.

Q3. Why optional parameters are set zero by default?
A. It's a design decision. Disabling additional feature by default makes the test codes more readable because which features are enabled is clarified. The cons for the decision is that users need to understand the features and set by themselves. However, I don't want users to blindly use writeboost and set the features without understandings and setting these features disabled by default encourages them to learn about it. As the best optimized values should be decided on each use case they should learn it. In addition, based on my philosophy, I want to keep the kernel code simple. And I think setting some default values should be done by userland management tools.

Q4. How much memory do we need to construct a writeboost'd device?
A. Roughly 1.0% of the caching device size. For example, if your caching device is 100GB then the system requires extra 1GB memory for writeboost.

Q5. drop_caches never ends
A. drop_caches waits for all dirty data is written back and the dirty data may locates in the rambuf other than caching device. You have to first flush the dirty caches in the rambuf to the caching device. Do dmsetup suspend and then dmsetup resume to forcibly flush the current rambuf.