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", "content_markdown": "Contributed by [Peter N. M. Hansteen](https://nxdomain.no/~peter/blogposts/) on 2026-11-01 from the most excellent file shredder dept.\n\nAs *[previously](https://www.undeadly.org/cgi?action=article;sid=20260918115729)* reported, Ori Bernstein is working on GEFS, the \"Good Enough File System\" imported to *[OpenBSD](https://www.openbsd.org/)*, and his *[EuroBSDCon 2026](https://2026.eurobsdcon.org/) [presentation](https://events.eurobsdcon.org/2026/talk/NVMSCJ/)* was very well received. In fact, the video is among the most frequently played from the conference.\n\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](https://marc.info/?l=openbsd-tech&m=179346643071941&w=2) to `tech@`, Ori writes:\n\n> ```\n> List: openbsd-tech\n> Subject: Re: GEFS on OpenBSD: A very early preview\n> From: ori () eigenstate ! org\n> Date: 2026-10-31 17:08:42\n> \n> So, it's probably time for a few updates. First\n> off, thanks to Martijn, and everyone else who\n> tried it out and sent patches.\n> \n> Everything is updated and rebased, and the diff\n> has been regenerated with all of the lastest.\n> ```\n\n> ```\n> I've gone through a the error handling code. In\n> theory the filesystem will handle errors mostly\n> correctly. There are probably still places where\n> theory diverges from reality. I've also forward\n> ported most of the important bugfixes from 9front.\n> \n> The file system now leaves the first FS block\n> unused by default -- we can put disklabels there,\n> which makes it hard to put the superblock there as\n> well.\n> \n> Some userspace tools have been done (you can now\n> mkfs on openbsd!), but snapshot control hasn't.\n> I'm thinking we have a userspace 'gefs' program\n> that lets you handle this, trying to keep the\n> interface similar to the 9front ctl file. The\n> commands below should suffice:\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> \n> The consistency protocol is still the biggest\n> missing piece; I've been reading the old code\n> for softupdates, since it had the same flavor\n> of problem.\n> \n> what gefs wants, in the ideal case, is some way\n> to put ordering barriers in the commit phases,\n> while still accepting new block i/o, something\n> like the following sequence of steps:\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> \n> on 9front, I have a priority queue of blocks that\n> are sorted by (gen, addr) tuples, which means that\n> writes within a generation are flushed to disk as\n> sequentially as they can be, while not crossing\n> generation boundaries.\n> \n> I'm currently thinking I'll implement the same in\n> OpenBSD -- launch syncer kprocs that do synchronous\n> I/O to the block device. If we kick things out of\n> cache and write it back to disk early, that should\n> generally be safe -- The only blocks the buffer\n> cache must not reorder are the arena headers and\n> superblocks, so a flag to pin them unwritten may\n> be all that's needed here.\n> \n> I'm open to other ideas, though.\n> \n> Quoth ori@eigenstate.org:\n> ```\n\nFollowed by a quoted part of the [previous message](https://marc.info/?l=openbsd-tech&m=178948744271633&w=2) that has the links to the code and documentation.\n\nIf you are as excited as we are about this new file system development and are in a position to test, please do.\n", "dateCreated": "2026-11-02T16:59:20.971254334+00:00", "date_created": "2026-11-01T20:13:29+00:00", "date_modified": "2026-11-01T20:13:29+00:00", "date_published": "2026-11-01T20:13:29+00:00", "description": "Comments", "external_url": "https://www.undeadly.org/cgi?action=article;sid=20261101115637", "git": { "commit": "20068632b65d2830a2d54f25ca1d90d697bea2c0", "path": "items/lobste-rs/2026/11/2026-11-01-work-on-gefs-the-good-enough-file-system-for-openbsd.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/20068632b65d2830a2d54f25ca1d90d697bea2c0/items/lobste-rs/2026/11/2026-11-01-work-on-gefs-the-good-enough-file-system-for-openbsd.md" }, "id": "urn:aggr:item:1f8a38b5c335b7b846715128d460e4f42cdfb054", "isBasedOn": { "@id": "https://www.undeadly.org/cgi?action=article;sid=20261101115637" }, "mainEntity": { "@id": "https://www.undeadly.org/cgi?action=article;sid=20261101115637", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/lobste-rs/2026-11-01-work-on-gefs-the-good-enough-file-system-for-openbsd/#webpage" }, "author": [ { "@type": "Person", "name": "undeadly.org via jbauer" } ], "dateModified": "2026-11-01T20:13:29+00:00", "datePublished": "2026-11-01T20:13:29+00:00", "headline": "Work on GEFS (the Good Enough File System) for OpenBSD progresses", "image": { "@type": "ImageObject", "caption": "Front page", "height": 90, "url": "https://www.undeadly.org/images/MangaRamblo_25_x.png", "width": 160 }, "timeRequired": "PT3M", "url": "https://www.undeadly.org/cgi?action=article;sid=20261101115637", "wordCount": 565 }, "name": "Archived snapshot: Work on GEFS (the Good Enough File System) for OpenBSD progresses", "preview": { "alt": "Front page", "color": null, "height": 90, "placeholder": { "data_url": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNk+A8AAQUBAScY42YAAAAASUVORK5CYII=", "hash": "" }, "url": "https://www.undeadly.org/images/MangaRamblo_25_x.png", "width": 160 }, "reading_minutes": 3, "replicated_at": null, "source": "lobste-rs", "source_name": "Lobsters: Top Stories of the Past Week", "summary": "Comments", "tags": [ "openbsd" ], "temporalCoverage": "2026-11-02T16:59:20.971254334+00:00", "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/", "word_count": 565 }