diff options
| author | IkiWiki <ikiwiki.info> | 2021-04-11 17:00:27 -0700 |
|---|---|---|
| committer | IkiWiki <ikiwiki.info> | 2021-04-11 17:00:27 -0700 |
| commit | 8b21c5666ada780beaa2c8147c8418a0158f49c6 (patch) | |
| tree | d7b3e93e333aea679663429bdcf2c57e7a8d96c8 | |
| parent | e0ecc0d713da9512dc1ffdbf0ec1fc5165bd6765 (diff) | |
| parent | ca5107a90dd49b640c922e2f72bf032447b1ac28 (diff) | |
Merge branch 'master' of /home/bcachefs/bcachefs
| -rw-r--r-- | Roadmap.mdwn | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/Roadmap.mdwn b/Roadmap.mdwn index b61cc9a..13e4442 100644 --- a/Roadmap.mdwn +++ b/Roadmap.mdwn @@ -34,7 +34,7 @@ even when our memery accesses are not cached. On my Ryzen 3900X single threaded lookups across 16M keys go at 1.3M second, and scale almost linearly - with 12 threads it's about 12M/second. We can do 16M random inserts at 670k per second single threaded; with 12 threads we achieve -2.4 random inserts per second. +2.4M random inserts per second. Btree locking is very well optimized. We have external btree iterators which make it easy to aggressively drop and retake locks, giving the filesystem as a @@ -57,7 +57,7 @@ where we're losing performance. Filesystem metadata operation performance (e.g. fsmark): On most benchmarks, we seem to be approaching or sometimes mathing XFS on performance. There are -exceptions: multithreaded rm -rf of empty files is currently roughly 4k slower +exceptions: multithreaded rm -rf of empty files is currently roughly 4x slower than XFS - we bottleneck on journal reclaim, which is flushing inodes from the btree key cache back to the inodes btree. |