diff options
author | Kent Overstreet <kent.overstreet@gmail.com> | 2015-07-17 19:23:54 -0700 |
---|---|---|
committer | Kent Overstreet <kent.overstreet@gmail.com> | 2015-07-17 19:23:54 -0700 |
commit | cf974fbe204ac7f190fa1a024a762b4450e9d08c (patch) | |
tree | 04fbc164a96d543ed8fe2eef2136adaaceee2e76 | |
parent | dfeaedf583f5d71d5eb43fb401f7946b016a10a8 (diff) |
todo
-rw-r--r-- | Todo.mdwn | 23 |
1 files changed, 12 insertions, 11 deletions
@@ -1,16 +1,17 @@ bcache/bcachefs todo list: - * Asynchronous btree node splits - - The last source of tail latency in the index update path is btree node - splits/compacts - a btree node split has to write out the new node(s) and - then update the parent node, all synchronously. - - This is particularly painful with bcachefs, as we end up doing a lot more - index updates (dirents/inodes/xattrs) as a proportion of total IO. - - Need to get the design for this written down. Slava and I had it worked out, - but we didn't write anything down so we'll have to go over it again. + * Implement epochs, and get rid of read retry path + + The idea is a refcount on allocator cycles - "epochs" - if something (e.g. + copygc) is buffering extents where GC can't find them (for recalculating the + oldest gen), it can take a ref on the current epoch; current epoch - oldest + existing epoch = how much more out of date pointer gens can be, for keys gc + can't find - then the allocator can wait if this is too big. + + For foreground reads, the trick is the read takes a (percpu) refcount on the + current epoch, and releases it when the read completes; then when the + allocator wants to start another cycle, it bumps the epoch, then waits for + all the references from foreground reads to go to 0 on the previous epoch. * Lockless btree lookups |