On 21 May 2022, Coly Li spake thusly: > When all journal buckets are fully filled by active jset with heavy > write I/O load, the cache set registration (after a reboot) will load > all active jsets and inserting them into the btree again (which is > called journal replay). If a journaled bkey is inserted into a btree > node and results btree node split, new journal request might be > triggered. For example, the btree grows one more level after the node > split, then the root node record in cache device super block will be > upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no > space in journal buckets, the journal replay has to wait for new journal > bucket to be reclaimed after at least one journal bucket replayed. This > is one example that how the journal no-space deadlock happens. > > The solution to avoid the deadlock is to reserve 1 journal bucket in It seems to me that this could happen more than once in a single journal replay (multiple nodes might be split, etc). Is one bucket actually always enough, or is it merely enough nearly all the time? -- NULL && (void)
