bcachefs
patreon
Status update - moving, portability/FUSE
🕑 Added 2017-06-13 23:48:51 +0000 UTC 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.
Comments
Hi Kent, tell me more about your server capacity needs. Maybe i can help you out.
Dave494
Please give detailed and easy-to-follow steps on how to convert ext4 into bcachefs on an installed Ubuntu (16.04 64-bit). Will GRUB2 still boot up Ubuntu with this fs or not? Will bcachefs get updates with Ubuntu from the repository (like when you install another web browser and it gets updated with Ubuntu itself). Thanks.
Kyan Zero The Real
Great
Illuminati Games
Awesome
Why don't we continue this conversation over messages?
Kent Overstreet
That would do perfectly! I'm a Debian user.
Does SSH access to a dual socket E5-2667v3 with 32GB RAM sound useful? It's located in Virginia. What OS would you want on it?
Kent Overstreet
It's actually not disks I need - for the vast majority of tests I try to run everything out of ram. What I need is SSH access to a machine with beefy CPUs and 32+ GB of ram, located not too far away network wise (U.S./Canada)
You rock Kent! Happy travels. I have a 36-drive capable machine. Any way I can make it useful for you and/or anyone else working on bcachefs ?
Great stuff Kent! Good luck with the move!
