Status update - moving, portability/FUSE

If you've noticed things have been quieter lately, you haven't been imagining things - I've been busy with getting ready for a rather big move, and in the process I'm taking an extended road trip. I'm pretty happy about it - I've been feeling stuck in a rut and it's been hard to make progress writing code, and I think a change of scenery has been long overdue.

In the short term though, all my bigger machines are packed up onto a trailer which is going to make a lot of my normal work more difficult - I can't run most of the tests on my laptop. I'm hoping (hint, hint) someone in the bcachefs community has spare server capacity for that sort of thing, but until then (or I get my machines set up) I do have other things I need to work on.

Portability:

I've been asked a few times about the potential for porting bcachefs to other operating systems. The short answer is: quite good.

As I've mentioned before, nearly all (about 90%) of the bcachefs code already builds and runs in userspace, and is used by bcachefs-tools. The core filesystem code is more or less structured as a library, and bcachefs-tools mostly just implements command line interfaces to it.

What this means is that most of the code is not particularly tied to the Linux kernel - if most of the code already works in userspace, we're most of the way to being able to run it on other operating systems, either in userspace or as a native filesystem driver.

The main thing left to be done is related to that last 10% of the code that doesn't build in userspace - fs.c and fs-io.c. This is code that right now is relatively coupled to the Linux VFS, but implements things that are necessary to actually have a filesystem, not just e.g. running fsck - e.g. the  direct IO and buffered IO paths. What needs to happen is going through the code in these two files, and refactoring it in such a way that code that'll be useful for implementing the VFS driver for other operating systems can be split out from the code that's truly specific to Linux's VFS. It'll probably be messy, but it's not a huge amount of code to deal with.

My current thinking is that the easiest way to tackle this will be by writing a bcachefs FUSE driver. That's something that would be useful regardless, and it can be part of bcachefs-tools - so there's a low barrier there, since most of the code already is built in bcachefs-tools.

Once bcachefs has been ported to just one other VFS interface (FUSE), porting it to other operating systems will be dramatically more straightforward. I personally don't want to work on those ports myself, but I do plan on working on the FUSE port while I'm travelling.