bcachefs
patreon
More bcachefs btree benchmarks
🕑 Added 2018-01-28 03:32:51 +0000 UTC rand_mixed is 3/4 lookups, 1/4 updateLookups, both sequential and random, are beautifully fast.
Random updates ought to scale better than that, but I haven't profiled it yet so I'm not sure what's going on.
Could probably do better on sequential inserts/deletes too, but I haven't even tried to optimize those yet.
seq_insert: 10.0M with 1 threads in 11 sec, 1067 nsec per iter, 914k per sec
seq_lookup: 10.0M with 1 threads in 0 sec, 19 nsec per iter, 47.9M per sec
seq_delete: 10.0M with 1 threads in 6 sec, 649 nsec per iter, 1.4M per sec
rand_insert: 10.0M with 1 threads in 19 sec, 1861 nsec per iter, 524k per sec
rand_insert: 10.0M with 4 threads in 9 sec, 3708 nsec per iter, 1.0M per sec
rand_lookup: 10.0M with 1 threads in 8 sec, 831 nsec per iter, 1.1M per sec
rand_lookup: 10.0M with 4 threads in 2 sec, 924 nsec per iter, 4.1M per sec
rand_mixed: 10.0M with 1 threads in 13 sec, 1281 nsec per iter, 762k per sec
rand_mixed: 10.0M with 4 threads in 4 sec, 1903 nsec per iter, 2.0M per sec
Comments
Kent Overstreet
look at packed bkeys. It's like that, only better.
In current implementation, we keep inode,snapshot field in struct bkey, it take up too much space in btree, because each key need the same field in btree. Why we not implemented a btree for single inode or snapshot, It will take up less space?
Kent Overstreet
Sounds like a great project for someone looking to help out :)
Good works! If you need some help to test file system and/or writing testing code please involve me. I don't use c/c++ in last years but no problem to restart using. I am a bache user, and would like to start to use bcache on my desktop in a few weeks :)! May be i could be useful to write tutorial and documentation (my engish in not perfect :) ) as i go on with installation
davidak
Very good! I would like to see graphs of the performance of the different versions in the future when you actually improve it.
