Big update

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>

1 files changed, 18 insertions, 36 deletions

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