@@ -1868,14 +1868,16 @@ void bch_initial_gc_finish(struct cache_set *c)
*/
for_each_cache(ca, c, i) {
for_each_bucket(b, ca) {
- if (fifo_full(&ca->free[RESERVE_PRIO]))
+ if (fifo_full(&ca->free[RESERVE_PRIO]) &&
+ fifo_full(&ca->free[RESERVE_BTREE]))
break;
if (bch_can_invalidate_bucket(ca, b) &&
!GC_MARK(b)) {
__bch_invalidate_one_bucket(ca, b);
- fifo_push(&ca->free[RESERVE_PRIO],
- b - ca->buckets);
+ if
(!fifo_push(&ca->free[RESERVE_PRIO], b - ca->buckets))
+ fifo_push(&ca->free[RESERVE_BTREE],
+ b - ca->buckets);
}
}
Hi, Junhui, I have met the similar problem once. It looks like a deadlock between the cache device register thread and bcache_allocator thread. The trace info tell us the journal is full, probablely the allocator thread waits on bch_prio_write()->prio_io()->bch_journal_meta(), but there is no RESERVE_BTREE buckets to use for journal replay at this time, so register thread waits on bch_journal_replay()->bch_btree_insert() The path which your register command possibly blocked: run_cache_set() -> bch_journal_replay() -> bch_btree_insert() -> btree_insert_fn() -> bch_btree_insert_node() -> btree_split() -> btree_check_reserve() ----here we find RESERVE_BTREE buckets is empty, and then schedule out... bch_allocator_thread() ->bch_prio_write() ->bch_journal_meta() You can apply this patch to your code and try to register again. This is for your reference only. Because this patch was not verified in my environment, because my env was damaged last time before I dig into code and write this patch, I hopefully it can resolve your problem:-) Signed-off-by: Hua Rui <huarui.dev@gmail.com> --- drivers/md/bcache/btree.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) }