betrfs

Please note that the benchmark sources are also available, e.g.; https://github.com/oscarlab/betrfs/blob/master/benchmarks/mi...

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

Looks like only works with Linux kernel - 3.11? https://github.com/oscarlab/betrfs/blob/master/README.md , so definitely have not been updated for awhile. I am not even sure it wants to be production ready but may be it is a playground for ideas.

Indeed, sounds very interesting. However, from their github [1]: > NOTE: The BetrFS prototype currently only works on the 3.11.10 kernel. This is a tad limiting, hopefully they will port it to latest... [1] https://github.com/oscarlab/betrfs

This is really interesting... ... so I'm really a bit bewildered and sad by some of the engineering choices they made along the way, like requiring a modified kernel: https://github.com/oscarlab/betrfs/blob/master/README.md#com... The reasons are detailed just above that link target, but are somewhat absurd IMHO: they modified the kernel's `struct task_struct` to pass error values, rather than fixing one of their libraries to handle its own error values. In return, nobody ever gets to use this without patching a kernel (which is, by the way, so ancient of a fork at this point that Forget It). I know it's unfair of a random internetfolk to complain about the engineering choices of a project like this, I'm sure I don't know the influences and tradeoffs first hand, etc, etc, but... Ow. I would've tried this. But not on a 3.11 kernel fork.