On Wed, 28 Jun 2017, Coly Li wrote: > On 2017/6/27 下午8:04, tang.junhui@xxxxxxxxxx wrote: > > Hello Eric, Coly, > > > > I use a 1400G SSD device a bcache cache device, > > and attach with 10 back-end devices, > > and run random small write IOs, > > when gc works, It takes about 15 seconds, > > and the up layer application IOs was suspended at this time, > > How could we bear such a long time IO stopping? > > Is there any way we can avoid this problem? > > > > I am very anxious about this question, any comment would be valuable. > > I encounter same situation too. > Hmm, I assume there are some locking issue here, to prevent application > to send request and insert keys in LSM tree, no matter in writeback or > writethrough mode. This is a lazy and fast response, I need to check the > code then provide an accurate reply :-) What controls the frequency? On our system I noticed this: ]# tail /sys/block/bcache0/bcache/cache/internal/*gc* ==> /sys/block/bcache0/bcache/cache/internal/btree_gc_average_duration_ms <== 1455 ==> /sys/block/bcache0/bcache/cache/internal/btree_gc_average_frequency_sec <== 3521 ==> /sys/block/bcache0/bcache/cache/internal/btree_gc_max_duration_ms <== 7036 So usually it takes 1.4s, as much as 7s on our systems. Average frequency is almost an hour. Can GC just be triggered more frequently? Say, once every 5min? Is that configurable? -Eric > > > -- > Coly Li > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >
