> 2022年9月16日 15:10，Zou Mingzhe <mingzhe.zou@xxxxxxxxxxxx> 写道：
>
>
>
> 在 2022/9/15 22:44, Coly Li 写道:
>>> 2022年9月15日 20:05，mingzhe.zou@xxxxxxxxxxxx 写道：
>>>
>>> From: mingzhe <mingzhe.zou@xxxxxxxxxxxx>
>>>
>>> If the data in the cache is dirty, gc thread cannot reclaim the space.
>>> We need to writeback dirty data to backing, and then gc can reclaim
>>> this area. So bcache will writeback dirty data more aggressively.
>>>
>> The writeback operation should try to avoid negative influence to front end I/O performance. Especially the I/O latency.
>>> Currently, there is no io request within 30 seconds of the cache_set,
>>> all backing devices in it will be set to the maximum writeback rate.
>> The idle time depends how many backing devices there are. If there is 1 backing device, the idle time before maximum writeback rate setting is 30 seconds, if there are 2 backing device, the idle time will be 60 seconds. If there are 6 backing device attached with a cache set, the maximum writeback rate will be set after 180 seconds without any incoming I/O request. That is to say, the maximum writeback rate setting is not a aggressive writeback policy, it is just try to writeback more dirty data without interfering regular I/O request when the cache set is really idle.
> The idle time does not depend on how many backing devices there are. Although the threshold of c->idle_counter is c->attached_dev_nr * 6, each backing device has its own writeback thread. If all backing devices are in writeback mode (writeback_percent is not 0) , it should be fixed for 30 seconds.
I think you catch a bug in set_at_max_writeback_rate(). The correct calculation should be,
if ((counter / dev_nr) < (dev_nr * 6))
return false;
The fix patch will be posted and Cc you soon, after it is tested.
Thanks.
Coly Li
