The README[1] is enough to understand, this is a really funky implementation and does nothing to bring useful functionality into the kernel.

It relies on TokuDB, which is a database server meant for userland, already a complex piece of code, patent-encumbered, probably well tweaked but heavy. It does not port that to the kernel, rather it reimplements userland interfaces in-kernel. For example, the file-based interfaces TokuDB expects are proxied to files in a different filesystem.

B_epsilon trees are a useful data structure, they may have a place in filesystems, but it will take a from scratch implementation to prove it. Repackaging TokuDB's patented fractal trees with extra duct tape does not address any needs outside of superficial marketing.

[1]: https://github.com/oscarlab/betrfs/blob/master/README.md

> Last commit was from march... why was this posted now and is there any interest/activity left?

I work in an adjacent research group at UNC, and I can assure you that this is a very active project. Unfortunately, because most venues now use double-blind review, the updated code can't be posted until after the associated paper(s) are accepted.

I'd encourage any potentially interested parties to star/watch the GitHub repo to keep an eye on development. I've seen some very impressive benchmark improvements from work currently in the pipeline.

> PS I would have to create a completly new system from scratch just to test this since my systems won't boot with such a prehistoric kernel.

This is most certainly a use case for running this in a virtual machine.

Using a VM to benchmark disk IO is a whole other can of worms.

When the limiting factor for IO perf that you’re trying to measure with your benchmark is the filesystem, rather than the disk, you don’t actually want a real disk backing your filesystem; that would just introduce noise to your measurements. Instead, you want your filesystem to be backed with an entirely in-memory block-device loopback image or some equivalent — which VMs are perfectly capable of (and in fact better at) providing.

Think of it by analogy to e.g. GPU benchmarking: you’d never use anything slower than the fastest CPU you can get your hands on, because you want to benchmark the GPU on its own as a single system bottleneck; not how well the GPU idles when held back by a bottleneck somewhere else in the system.

I don’t think you want to benchmark datastructures designed to be efficient on high latency disks using low latency memory. Many file systems can be efficient with low latency disks, that’s not very impressive. What’s impressive is being efficient with high latency storage.

Who said anything about low latency? The thing you get from a simulated block device is predictable, controllable latency. Latency that can be deterministically replayed. Latency that can be precisely normalized away in the benchmark results, without worrying about inter-batch anomalies (if using separate disks) or the effects of wear (on the same disk.)

If it’s backed by ram, I would expect the performance characteristics to differ from ssd or hdd, especially in respect to latency concerns.