On 12/15/18 12:22 PM, Michael Lyle wrote:
On Fri, Dec 14, 2018 at 8:08 PM Coly Li colyli@suse.de wrote:
Commit b1092c9af9ed ("bcache: allow quick writeback when backing idle") just looks at single bcache device. If there are I/Os for other bcache device on the cache set, and a single bcache device is idle, a faster writeback rate for this single idle bcache device will happen, I/O to read dirty data on cache for writeback will have negative impact to I/O requests of other bcache devices.
Yes, but this will potentially fill the queue on the idle device. If you have an application that is intermittently doing I/O every few seconds, the latency of the individual I/Os will be high. I was told during review that this was unacceptable, and revised my patch. But now we have merged a change that is more like my first patch that was rejected...
The original patch only looks at a single bcache, this fix looks at all bcache devices.
If only a single bcache attached on cache set, by default it will be idle for 30 seconds before the writeback rate to be set to a high rate. And if more bcache devices attached, longer threshold required. For 4 bcache devices attached the default idle threshold will be about 120 seconds. If I/O comes between more than 30 seconds (even minutes), I will not take it as an online system, most cases the latency should not be sensitive, or bcache is not proper for such workload.
Coly Li