From 2a2219526e2243d95dd283da73f01d6de2b62a77 Mon Sep 17 00:00:00 2001 From: Kent Overstreet Date: Mon, 11 Sep 2023 17:26:07 -0400 Subject: Big update Signed-off-by: Kent Overstreet --- Todo.mdwn | 54 ++++++++++++++++++------------------------------------ 1 file changed, 18 insertions(+), 36 deletions(-) (limited to 'Todo.mdwn') diff --git a/Todo.mdwn b/Todo.mdwn index 5138bb9..06fbdb5 100644 --- a/Todo.mdwn +++ b/Todo.mdwn @@ -1,33 +1,30 @@ -#TODO +# TODO ## Kernel developers -### Current priorities +### P0 features - * Replication + * Disk space accounting rework: now that we've got the btree write buffer, we + can store disk space accounting in btree keys (instead of the current hacky + mechanism where it's only stored in the journal). - * Compression is almost done: it's quite thoroughly tested, the only remaining - issue is a problem with copygc fragmenting existing compressed extents that - only breaks accounting. + This will make it possible to store many more counters - meaning we'll be + able to store per-snapshot-id accounting. - * NFS export support is almost done: implementing i_generation correctly - required some new transaction machinery, but that's mostly done. What's left - is implementing a new kind of reservation of journal space for the new, long - running transactions. + We also need to add separate counters for compressed/uncompressed size, and + broken out by compression type. - * Allocation information (currently just bucket generation numbers & priority - numbers, for LRU caching) needs to be moved into a btree, and we need to - start persisting actual allocation information so we don't have to walk all - extents at mount time. + It'd also be really nice to add more counters to the inode for + compressed/uncompressed size. Right now the inode just has `bi_sectors`, + which the ondisk size for fallocate purposes, i.e. discounting replication. + We could add something like - Just moving the existing prios/gens to a btree will be a significant - improvement - besides getting us incrementally closer to persisting full - allocation information, the existing code is a rather hacky mechanism dating - from the early days of bcache and has recently been the source of an annoying - bug due to the design being a bit fragile, and it'll be a performance - improvement since it'll get rid of the last source of forced journal flushes. + bi_sectors_ondisk_compressed + bi_sectors_ondisk_uncompressed -### Other +### P1 features + +### P2 features * When we're using compression, we end up wasting a fair amount of space on internal fragmentation because compressed extents get rounded up to the @@ -45,9 +42,6 @@ * Do data journalling when we don't have a full block to write? Possible solution, we want data journalling anyways - * Inline extents - good for space efficiency for both small files, and - compression when extents happen to compress particularly well. - * Full data journalling - we're definitely going to want this for when the journal is on an NVRAM device (also need to implement external journalling (easy), and direct journal on NVRAM support (what's involved here?)). @@ -55,23 +49,11 @@ Would be good to get a simple implementation done and tested so we know what the on disk format is going to be. -### Low priority - - * NOCOW - -### Optional -(Will not be implemented by the lead developer.) - - * It is possible to add bcache functionality to bcachefs. - If there is someone who wishes to implement this it would be an ok addition. - However using it as a filesystem should still be better. - ## Developers * End user documentation needs a lot of work - complete man pages, etc. * bcachefs-tools needs some fleshing out in the --help department - * Write a tool to benchmark tail-latency. ## Users -- cgit v1.2.3