Work on GEFS (the Good Enough File System) for OpenBSD progresses

2026-11-01T20:13:29+00:00

Contributed by Peter N. M. Hansteen on 2026-11-01 from the most excellent file shredder dept.

As previously reported, Ori Bernstein is working on GEFS, the "Good Enough File System" imported to OpenBSD, and his EuroBSDCon 2026 presentation was very well received. In fact, the video is among the most frequently played from the conference.

Now Ori has followed up with more evolved code that includes several important steps towards makin the new file system fit for general use. In a message to tech@, Ori writes:

List:       openbsd-tech
Subject:    Re: GEFS on OpenBSD: A very early preview
From:       ori () eigenstate ! org
Date:       2026-10-31 17:08:42

So, it's probably time for a few updates. First
off, thanks to Martijn, and everyone else who
tried it out and sent patches.

Everything is updated and rebased, and the diff
has been regenerated with all of the lastest.

I've gone through a the error handling code. In
theory the filesystem will handle errors mostly
correctly. There are probably still places where
theory diverges from reality. I've also forward
ported most of the important bugfixes from 9front.

The file system now leaves the first FS block
unused by default -- we can put disklabels there,
which makes it hard to put the superblock there as
well.

Some userspace tools have been done (you can now
mkfs on openbsd!), but snapshot control hasn't.
I'm thinking we have a userspace 'gefs' program
that lets you handle this, trying to keep the
interface similar to the 9front ctl file. The
commands below should suffice:

  gefs debug [0|1]
  gefs usereserve
  gefs retain snap timespec
  gefs snap name newname
  gefs fork name newname

The consistency protocol is still the biggest
missing piece; I've been reading the old code
for softupdates, since it had the same flavor
of problem.

what gefs wants, in the ideal case, is some way
to put ordering barriers in the commit phases,
while still accepting new block i/o, something
like the following sequence of steps:

	0) normal use, generate dirty blocks and
	  write back in any order.
      holding mutlk {
		1) barrier(), ensure that all blocks
		 written before the commit will be
		 on disk before the commit finishes
		2) enqueue free list/deadlist data
		3) prepare arena header/footer + superblock
	 }
	4) enqueue arena headers
	5) barrier()
	6) enqueue superblock
	7) enqueue arena footers
	8) wait for enqueued blocks to hit disk
	9) free blocks no longer used by previous gen

on 9front, I have a priority queue of blocks that
are sorted by (gen, addr) tuples, which means that
writes within a generation are flushed to disk as
sequentially as they can be, while not crossing
generation boundaries.

I'm currently thinking I'll implement the same in
OpenBSD -- launch syncer kprocs that do synchronous
I/O to the block device. If we kick things out of
cache and write it back to disk early, that should
generally be safe -- The only blocks the buffer
cache must not reorder are the arena headers and
superblocks, so a flag to pin them unwritten may
be all that's needed here.

I'm open to other ideas, though.

Quoth ori@eigenstate.org:

Followed by a quoted part of the previous message that has the links to the code and documentation.

If you are as excited as we are about this new file system development and are in a position to test, please do.

undeadly.org

Work on GEFS (the Good Enough File System) for OpenBSD progresses