Live data from Hacker News

BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage

betrfs.org

31–40 of 48 posts

Re: BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage

#31

What's the story with patent/license on fractal tree by tokutek (now percona)? Can you use it for personal use only? Ie. you can't use it at work without a license? What about Bε-trees - are there patent free implementations?

Tokutek licensed the fractal tree under GPLv2 with an explicit patent license to make clear that anyone could use the fractal tree code. I don't know what Percona did after the aquisiton.

[deleted]

Re: BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage

#32
A filesystem using complex data structures, with no mention of reliability? It seems like a huge omission. Personally I think simplicity (and reliability, which usually accompanies it) is the most important for a filesystem --- it doesn't matter how fast it is, if it is prone to data loss from bugs or whatever else.

Re: BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage

#33

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 li…

All the reasons given boil down to “we didn’t want to mess with TokuDB”. The build process (requiring specific GCC versions, CMake, and a bunch of packages including Valgrind), the errno patch to task_struct, and the half dozen libc stub functions are all there because TokuDB expects userspace libc. I don’t know whether the authors ever attempted to patch TokuDB itself (or streamline it down to the essentials for the…

Perhaps TokuDB was evolving rapidly at the time they were trying to incorporate it into this filesystem.

It seems like the choices are:

1. Fork TokuDB.

2. Fork the kernel.

If the goal is research, the first one of those would then slow down the research. The second one only gets you stuck on an old kernel, which while not great for end users, isn't as big of a problem for a researcher as having their researcher slowed down.

Re: BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage

#34
post #6

Earlier quoted context omitted.

Pronounce btrfs as “butter fs” and betrfs as “bee-turr fs” or something, then there is no confusion ;) But yeah I agree, betrfs and btrfs are way too similar names.

I can’t beleive it’s not butrfs.

Your sound a bit bitrfs.

Re: BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage

#35
post #2

Btrfs vs betrfs... This is going to cause so much confusion Ah, but the project isn't new, so I guess it's not a new problem

BtrFS stands for B-tree File System. BetrFS stands for B^{\epsilon}-tree File System. They are both named after their primary data structure.

Re: BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage

#36
post #30

Earlier quoted context omitted.

Tokutek licensed the fractal tree under GPLv2 with an explicit patent license to make clear that anyone could use the fractal tree code. I don't know what Percona did after the aquisiton.

Any idea what year the patent clock times out?

2027

Re: BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage

#38

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 li…

All the reasons given boil down to “we didn’t want to mess with TokuDB”. The build process (requiring specific GCC versions, CMake, and a bunch of packages including Valgrind), the errno patch to task_struct, and the half dozen libc stub functions are all there because TokuDB expects userspace libc. I don’t know whether the authors ever attempted to patch TokuDB itself (or streamline it down to the essentials for the…

This isn't completely fair, although most of it is.

Some of the reasons for modifying Linux are performance enhancements to the filesystem layer that only make sense with a Bε-tree filesystem (and are not possible without patching Linux). They cover this in the hour-long talk at MS research linked elsewhere in this thread.[1] (Yes, it's long, but it's a pretty good presentation.)

E.g., they describe modifying the page cache to write-through small modifications to file data, rather than dirtying the entire page and writing it back later (a form of write amplification).

[1]: https://www.youtube.com/watch?v=fBt5NuNsoII

Re: BetrFS: An in-kernel file system that uses Bε trees to organize on-disk storage

#39
post #38

Earlier quoted context omitted.

All the reasons given boil down to “we didn’t want to mess with TokuDB”. The build process (requiring specific GCC versions, CMake, and a bunch of packages including Valgrind), the errno patch to task_struct, and the half dozen libc stub functions are all there because TokuDB expects userspace libc. I don’t know whether the authors ever attempted to patch TokuDB itself (or streamline it down to the essentials for the…

This isn't completely fair, although most of it is. Some of the reasons for modifying Linux are performance enhancements to the filesystem layer that only make sense with a Bε-tree filesystem (and are not possible without patching Linux). They cover this in the hour-long talk at MS research linked elsewhere in this thread.[1] (Yes, it's long, but it's a pretty good presentation.) E.g., they describe modifying the pag…

> E.g., they describe modifying the page cache to write-through small modifications to file data, rather than dirtying the entire page and writing it back later (a form of write amplification).

Considering that all the storage on the market now has sectors at least as large as a 4k page, this isn't actually reducing write amplification. At most, in some cases it might save a tiny bit of bus traffic.

Post reply on HN