'GEFS on OpenBSD: A very early preview' - MARC

[prev in list] [next in list] [prev in thread] [next in thread]

List: openbsd-tech
Subject: GEFS on OpenBSD: A very early preview
From: ori () eigenstate ! org
Date: 2026-09-15 15:45:05
Message-ID: EBB049B251DCF60A8C9A0575F6FC7DC9 () eigenstate ! org
[Download RAW message or body]

Before anyone asks: I am *not* proposing to put
this in tree for a while yet.

What is it
----------
So, as people may have seen at EuroBSD, I've got a
rough, buggy, issue-filled preview of GEFS running
on OpenBSD. The port is NOT ready for production,
and data loss is currently expected, especially on
error.

However, the port has reached the state where (with
some exceptions) the remaining problems are reasonably
understood, and people can poke at them.

For those who haven't watched my talk, GEFS is a
new, crash-safe, snapshotting, copy on write FS
that I wrote for 9front, and which I am in the
process of moving to OpenBSD. The file system is
described in full here:

https://orib.dev/gefs.pdf

It's under 9,000 lines of code in kernel at the
moment, though I expect it'll grow a bit over time,
since there's a good deal missing.

Porting
-------
I'm approaching this as a proper, in-kernel file
system that keeps the data structure and fiddly
code fairly in sync between Plan 9 and OpenBSD,
but the code itself is copied and pasted. My goal
is that it will continue to rhyme, so that fixes
can be shared, but the requirements of the two
environments means that the code probably won't
be ported, and trying to shove in some abstraction
layer seems like a bad idea.

Problems
--------
So, IMO, the biggest of the remaining problems:

Consistency Protocol:
This is the big unknown for me; A write to the
superblock needs to come after all writes in
the snapshot, but as long as it is written after
the blocks have hit disk, it's safe. There are
also a couple of fixes to backport from 9Front
on the write ordering.

Error handling and porting brain damage:
Error handling is largely commented out. I'm
going to have to go through the error handling
paths bit by bit and convert it with care; the
approach to error handling I took on 9front is
not acceptable for OpenBSD. There's a few other
things, like some globals being used that would
prevent more than one mount at a time.

Userspace tools:
At least, I assume that telling people to boot
9front in a VM to create or fsck is not a good
long term solution. Snapshot management and the
associated ioctls will also go here.

Posix persnicketies:
The system that this was ported from was not
a posix system, so there are likely to be many
places where we don't quite get the constraints
right.

Regress:
There's a small test suite for Plan 9. There's
none for OpenBSD.

Hardlinks:
Easy to implement, but needs a refcount file
by file.

Kqueue:
Easy to implement, but needs a refcount file
by file.

NFS:
Has some ugly hooks, not sure what would be
needed to add them.

Other missing pieces:
Things like bootloader support, adding boot
environments, quotas, and other niceties; this
is well down the list. Quotas, in particular,
would allow LLVM to continue in its attempt to
grow to the size of the known universe without
us preallocating a /usr/obj of that size.

I'm sure I've forgotten some.

Right now: I'm not looking to fix KNF; as things
get touched, I'll start to move them over, but I
would prefer to keep the code closer with the
original until it's closer to ready for upstreaming.

There are also a few non-fatal issues independent
of 9front and OpenBSD, such as slow deletions of
large files; I've got ideas to improve them.

Getting it
----------

as one patch:

https;//orib.dev/gefs.diff

The git repo is hidden on shithub, and the
server is tiny and will get overloaded if
people clone fresh repos from it. Instead,
get a copy of the initial repo from github,
and pull only the updates.

# first, get a copy of the upstream from
# somewhere else
git clone https://github.com/openbsd/src
cd src

# now, add my server, and get just the diffs
git remote add gefs git://shithub.us/ori/openbsd
git fetch gefs
git checkout -b gefs gefs/gefs

Note, I will be rebasing and force-pushing
the branch occasionally in order to keep up
with openbsd current; commit ids will change.

[prev in list] [next in list] [prev in thread] [next in thread]

Configure |

About |
News |
Add a list |
Sponsored by KoreLogic

The author is presenting an early preview of the GEFS file system running on OpenBSD, emphasizing that the port is not yet production-ready and potential data loss exists, particularly during error conditions. GEFS is described as a new, crash-safe, snapshotting, and copy on write file system that the author developed for 9front and is currently porting to OpenBSD. The full description of the file system can be found in a linked document. At the time of writing, the kernel implementation of GEFS comprises under nine thousand lines of code, though the author anticipates further growth as more functionality is added.

The methodology for porting is approached as creating a proper, in-kernel file system that maintains synchronization of the data structure and complex code between the Plan 9 environment and OpenBSD. The implementation relies on copying and pasting code segments, aiming to preserve the structure so that fixes can be shared; however, the differences between the two operating environments suggest that a complete porting of the code may not be feasible, making the introduction of abstraction layers counterproductive.

Several significant technical challenges are identified regarding this porting effort. The consistency protocol represents a major unknown, specifically concerning the required ordering of a write to the superblock relative to all writes within a snapshot, though safety is maintained if the superblock write occurs after blocks have been committed to disk. Furthermore, error handling presents difficulties; since error handling paths are largely commented out, the author must carefully convert these paths to fit OpenBSD standards, as the error handling approach used on 9front is deemed unacceptable for OpenBSD. Other issues include constraints related to global variables that affect simultaneous mounting and discrepancies arising because the source system was not a POSIX environment.

Specific features require careful implementation considerations. The author notes that userspace tools, including snapshot management and associated ioctls, must be developed. Furthermore, the system must address POSIX peculiarities, as the source base was not POSIX. Features such as hardlinks and kqueue require the implementation of reference counting logic on a per-file basis. Integration with NFS also presents hurdles, requiring the definition of necessary hooks. Beyond these specific components, further considerations include implementing support for bootloaders, adding boot environments, and managing quotas, particularly as this would allow the system to accommodate future growth without preallocating excessive space.

To facilitate the process of obtaining the code, the author provides a specific procedure involving git operations. This involves cloning the OpenBSD source tree, setting up a remote reference to the GEFS repository, fetching the necessary differences, and checking out the GEFS branch within the OpenBSD source directory. The author plans to occasionally rebase and force-push these changes to keep pace with the evolution of the OpenBSD commits. Non-fatal issues, such as the slow deletion of large files, are also noted, and the author has ideas for improving these aspects.