Contributed by Peter N. M. Hansteen on 2026-11-01 from the most excellent file shredder dept.
\nAs 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.
\nNow 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:
\n\n\nList: openbsd-tech\nSubject: Re: GEFS on OpenBSD: A very early preview\nFrom: ori () eigenstate ! org\nDate: 2026-10-31 17:08:42\n\nSo, it's probably time for a few updates. First\noff, thanks to Martijn, and everyone else who\ntried it out and sent patches.\n\nEverything is updated and rebased, and the diff\nhas been regenerated with all of the lastest.\n
\n\n\nI've gone through a the error handling code. In\ntheory the filesystem will handle errors mostly\ncorrectly. There are probably still places where\ntheory diverges from reality. I've also forward\nported most of the important bugfixes from 9front.\n\nThe file system now leaves the first FS block\nunused by default -- we can put disklabels there,\nwhich makes it hard to put the superblock there as\nwell.\n\nSome userspace tools have been done (you can now\nmkfs on openbsd!), but snapshot control hasn't.\nI'm thinking we have a userspace 'gefs' program\nthat lets you handle this, trying to keep the\ninterface similar to the 9front ctl file. The\n:\n\n gefs debug [0|1]\n gefs usereserve\n gefs retain snap timespec\n gefs snap name newname\n gefs fork name newname\n\nThe consistency protocol is still the biggest\nmissing piece; I've been reading the old code\nfor softupdates, since it had the same flavor\nof problem.\n\nwhat gefs wants, in the ideal case, is some way\nto put ordering barriers in the commit phases,\nwhile still accepting new block i/o, something\n:\n\n\t0) normal use, generate dirty blocks and\n\t write back in any order.\n holding mutlk {\n\t\t1) barrier(), ensure that all blocks\n\t\t written before the commit will be\n\t\t on disk before the commit finishes\n\t\t2) enqueue free list/deadlist data\n\t\t3) prepare arena header/footer + superblock\n\t }\n\t4) enqueue arena headers\n\t5) barrier()\n\t6) enqueue superblock\n\t7) enqueue arena footers\n\t8) wait for enqueued blocks to hit disk\n\t9) free blocks no longer used by previous gen\n\non 9front, I have a priority queue of blocks that\nare sorted by (gen, addr) tuples, which means that\nwrites within a generation are flushed to disk as\nsequentially as they can be, while not crossing\ngeneration boundaries.\n\nI'm currently thinking I'll implement the same in\nOpenBSD -- launch syncer kprocs that do synchronous\nI/O to the block device. If we kick things out of\ncache and write it back to disk early, that should\ngenerally be safe -- The only blocks the buffer\ncache must not reorder are the arena headers and\nsuperblocks, so a flag to pin them unwritten may\nbe all that's needed here.\n\nI'm open to other ideas, though.\n\n:\n
Followed by a quoted part of the previous message that has the links to the code and documentation.
\nIf you are as excited as we are about this new file system development and are in a position to test, please do.
\n", "date_modified": "2026-11-01T20:13:29+00:00", "date_published": "2026-11-01T20:13:29+00:00", "external_url": "https://www.undeadly.org/cgi?action=article;sid=20261101115637", "id": "urn:aggr:item:1f8a38b5c335b7b846715128d460e4f42cdfb054", "image": "https://www.undeadly.org/images/MangaRamblo_25_x.png", "summary": "Comments", "tags": [ "news", "openbsd" ], "title": "Work on GEFS (the Good Enough File System) for OpenBSD progresses", "url": "https://aggr.aymericbeaumet.com/items/lobste-rs/2026-11-01-work-on-gefs-the-good-enough-file-system-for-openbsd/" } ], "language": "en", "title": "undeadly.org", "version": "https://jsonfeed.org/version/1.1" }