6  * THE JOURNAL:
8  * The journal is treated as a circular buffer of buckets - a journal entry
10  * journal at runtime, and will be needed for bcache on raw flash support.
12  * Journal entries contain a list of keys, ordered by the time they were
13  * inserted; thus journal replay just has to reinsert the keys.
15  * We also keep some things in the journal header that are logically part of the
18  * journal) can't be moved or wear leveled, so it contains just enough
19  * information to find the main journal, and the superblock only has to be
20  * rewritten when we want to move/wear level the main journal.
22  * Currently, we don't journal BTREE_REPLACE operations - this will hopefully be
29  * OPEN JOURNAL ENTRIES:
31  * Each journal entry contains, in the header, the sequence number of the last
32  * journal entry still open - i.e. that has keys that haven't been flushed to
35  * We track this by maintaining a refcount for every open journal entry, in a
36  * fifo; each entry in the fifo corresponds to a particular journal
39  * journal entries
41  * We take a refcount on a journal entry when we add some keys to a journal
47  * A struct btree_write can only hold a refcount on a single journal entry, but
48  * might contain keys for many journal entries - we handle this by making sure
49  * it always has a refcount on the _oldest_ journal entry of all the journal
52  * JOURNAL RECLAIM:
55  * journal entries; from that and the current journal sequence number we compute
56  * last_seq - the oldest journal entry we still need. We write last_seq in each
57  * journal entry, and we also have to keep track of where it exists on disk so
58  * we don't overwrite it when we loop around the journal.
60  * To do that we track, for each journal bucket, the sequence number of the
61  * newest journal entry it contains - if we don't need that journal entry we
63  * journal bucket we still need; all this is tracked in struct journal_device
66  * JOURNAL FILLING UP:
68  * There are two ways the journal could fill up; either we could run out of
69  * space to write to, or we could have too many open journal entries and run out
74  * If the journal fills up, we start flushing dirty btree nodes until we can
75  * allocate space for a journal write again - preferentially flushing btree
76  * nodes that are pinning the oldest journal entries first.
80  * Only used for holding the journal entries we read in btree_journal_read()
90  * We put two of these in struct journal; we used them for writes to the
91  * journal that are being staged or in flight.
104 struct journal {  struct
109 	/* used when waiting because the journal was full */  argument
126  * Embedded in struct cache. First three fields refer to the array of journal  argument
131 	 * For each journal bucket, contains the max sequence number of the
132 	 * journal writes it contains - so we know when a bucket can be reused.
136 	/* Journal bucket we're currently writing to */
139 	/* Last journal bucket that still contains an open journal entry */
142 	/* Next journal bucket to be discarded */
155 	/* Bio for journal reads/writes to this device */
163 	(fifo_idx(&(c)->journal.pin, (l)) > fifo_idx(&(c)->journal.pin, (r)))
178 void bch_journal_next(struct journal *j);
186 void bch_journal_space_reserve(struct journal *j);