Lines Matching defs:keys
90 * BTREE_INSERT will just take a list of keys and insert them into the btree -
104 * This means that there are always stale/invalid keys in the btree. They're
122 * can append new keys to an existing btree node without rewriting it. This
123 * means each set of keys we write is sorted, but the node is not.
125 * We maintain this log structure in memory - keeping 1Mb of keys sorted would
126 * be expensive, and we have to distinguish between the keys we have written and
127 * the keys we haven't. So to do a lookup in a btree node, we have to search
129 * these extra searches is quite low (normally most of the keys in a btree node
165 * a few keys each) - highly inefficient in terms of amount of metadata writes,
168 * The journal is just a log of keys we've inserted; on startup we just reinsert
169 * all the keys in the open journal entries. That means that when we're updating
170 * a node in the btree, we can wait until a 4k block of keys fills up before
238 * keys.
243 struct rb_root keys;
596 * This is a refcount that blocks prio_write() until the new keys are