3 ms·

GEFS on OpenBSD: A Early Preview

sippingabonedry 11d ago
GEFS: A Good Enough File System https://orib.dev/gefs.pdf https://orib.dev/gefs.pdf
dchest 11d ago
Talk at EuroBSDCon 2026: https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u
g0xA52A2A 11d ago
There was a recent presentation on this at EuroBSDCon for those interested. https://events.eurobsdcon.org/2026/talk/NVMSCJ/ https://events.eurobsdcon.org/2026/talk/NVMSCJ/ https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u
doublepg23 11d ago
This is great timing considering I'm currently dealing with FFS corruption after my OpenBSD server lost power during a storm.
- daneel_w 11d ago
  Are you sure it's not just a dodgy SSD that simply failed to persist data when losing power mid-write? I've had my share of sudden power cuts upon OpenBSD during the past 20+ years, and FFS has so far never gone corrupt on me.
  - doublepg23 11d ago
    I do not believe so? Drive is a 2TB Intel 670p NVMe SSD (INTEL SSDPEKNU020TZ) with 9078 power on hours and 42TBW - so pretty spry, but not at the start of the bathtub curve either. It was mounted as fast storage for a Bitcoin node. Perhaps the only 'unique' thing is it is using a NVMe to PCIe adapter card (Synology M2D20) due to this being my "legacy" server that's still rocking a Broadwell chip.
    - daneel_w 9d ago
      That does sound pretty spry. But it doesn't rule out that it utilizes slow storage which is fronted by a (too) large RAM buffer making the device appear much faster than it really is. Most SSDs are like this.
  - yellowapple 11d ago
    I've seen file corruption with FFS on some of my OpenBSD servers, though them being VMs is likely a factor there.
    - oridb 10d ago
      Qcow2 will zero blocks on power loss, at least in some configurations.
  - fodkodrasz 11d ago
    FFS corrupted multiple times on me, with intel video driver freezing on OpenBSD. My short OpenBSD sidetrack ended after reliably corrupting itself the third time... every time video driver panicking, leaving a corrupted filesystem after reboot, when I had eg. ports install going on during panic. Windows ran fine on the machine (Lenovo 200) before, and Linux ran fine after. FFS (and the intel video drivers) are the weakest part of OpenBSD in my experience, I liked many other aspects.
    - daneel_w 9d ago
      If writes are happening while the power cuts you will lose that data. Journaling doesn't help against this. FFS will need a consistency check if it doesn't "unmount cleanly", but this isn't the same as the file system having been corrupted and losing data. If something really got corrupted and it was something else besides what you were writing in the moment the machine died, it sounds like a lot of data (for whatever reason large amounts of data was still buffered; usually an SSD is the reason) just hadn't persisted yet. With the exception of the old unadvisable softdeps feature, FFS doesn't defer a lot of writing. And It's possible to tell FFS to be fully synchronous, with the caveat that it becomes even slower than the sluggish performer it already is.
- rbc 10d ago
  I've run OpenBSD continuously at home without backup power for something like eight years. They probably loose power about once or twice a quarter. I have yet to detect lost data that was important. Measures are taken. If a storm is coming through, I'll shutdown till it passes. I've been lucky with release driver support. The little Lenovo ThinkCentre's being used seem to chug along without crashing on driver issues, at least with OpenBSD releases. The standard OpenBSD partitioning scheme is also being used. Boot time fsck has never failed when the storage was properly attached and in a good state. Backups are performed using pax. So far, so good.
metalforever 11d ago
Finally . Very good work team !
anthk 11d ago
Ori B. it's a great programmer, he fixed a small bug on the earlier GeFS on 9front versions in no time. It worked fine in my n270 based Atom netbook under 9front, so it will run perfectly well under OpenBSD in a near future. It isn't as resource heavy as ZFS, and it will be more reliable than FFS, for sure.
geoffbp 11d ago
> The git repo is hidden on shithub Heh :)
- irusensei 11d ago
  Is this classic 9front tomfoolery?
  - MisterTea 11d ago
    Indeed. If that URL is too crude then one may also use only9fans.com.
moody__ 11d ago
I've been following (and helping test) gefs on 9front for a while now. 9front's nightly builder has been running off of it for quite a while. Ori's done a fantastic job.
- sellmesoap 10d ago
  Oh my gosh, while I may have heard of 9front in passing I had a little look today and it's super cool! also shithub what an amazing alternative forge, it feels like one of those days when I'm part of the 10,000!
  - creeperhost 10d ago
    For reference, the shithub that plan9 uses is not shithub.sh (to any of my knowledge)
    - moody__ 10d ago
      no they are different, our shithub is shithub.us to be specific.
      - sellmesoap 9d ago
        Ahh thanks for getting my shit straight!
yjftsjthsd-h 11d ago
From https://orib.dev/gefs.pdf https://orib.dev/gefs.pdf - > While snapshot consistency is useful to keep data consistent, disks often fail over time. In order to detect corruption, block pointers contain a hash of the data that they point at. If corrupted data is returned by the underlying storage medium, this is detected via block hashes. And if a programmer error causes the file system to write garbage to disk, this can often be caught early. The corruption is reported, and the damaged data may then be recovered from backups, RAID restoration, or some other means. Okay! It's got CoW, snapshots, and data checksums. Therefore, it's good enough to compete with ZFS while being way smaller and permissively licensed. Now I just want it ported to Linux and the other BSDs:)
- atmosx 11d ago
  I don't think it will compete with ZFS or BTRFS (e.g. I don't think ppl will use GEFS over ZFS or BTRFS for a storage server), but it's a modern, much needed FFS replacement.
  - yjftsjthsd-h 11d ago
    Who said anything about storage servers? I'm using zfs on laptops and desktops right now because I want data checksums and a filesystem that doesn't have a history of breaking horribly (I dropped btrfs after the second time it hosed my rootfs). Given the license issue with zfs - and in particular, the technical fallout like needing dkms - I'd be very pleased to replace it.
    - sippingabonedry 11d ago
      > I dropped btrfs after the second time it hosed my rootfs btrfs fans use the "you're using it wrong" excuse a lot. I recall a failure mode that activated when you fill the FS to 100% and their response was "you should never fill a filesystem to capacity"
      - jeffrallen 11d ago
        Otoh, good luck bringing a CoW filesystem back from 100%. Delete a file? Sure, let me just make a copy of all the metadata that was pointing at it using... the zero blocks I have left. Tradeoffs are a bitch, bitch.
fn-mote 11d ago
Is there any chance of proving a filesystem is correct? Is this one simple enough that it won’t have bugs?? Given the issues with well-known filesystems like ZFS and BetterFS, why shouldn’t I expect data-losing bugs in this one?
- spijdar 11d ago
  I think the premise is basically yes, you should assume there will be data-losing bugs, but: 1. The filesystem should be reasonably good at detecting an error/corruption state and informing you, and 2. You should have backups of said data stored elsewhere, and backups should be tested (e.g. to verify that data can be read back)
- cyberpunk 11d ago
  What well known data-losing bugs are there in zfs? It can be slow, and resource hungry, but afaik it's about as safe as they come (and I've been using it in prod since solaris 10)
  - alethic 11d ago
    There was a long-running data corruption issue with non-raw sends that was finally found and patched in 2025: https://github.com/openzfs/openzfs-docs/issues/494 https://github.com/openzfs/openzfs-docs/issues/494. But I agree, it's about as safe as they come. I trust it far more than any other file system, in large part due to all its built-in redundancy and the way it makes backups trivial (encrypted sends <3)...
  - sellmesoap 11d ago
    I never dug into the failure, but I once had a ZFS get to a state where it would crash the kernel on mount, I was able to mount it with checks turned off an recover what was important, but it was a spooky experience. I live on the bleeding edge of file systems for my desktop, I was on reiser4 back when that was fresh, I daily drive bcachefs (it's been great!) Mostly I've been lucky, I don't usually keep an openbsd system around, but I love FreeBSD and I'll give OpenBSD a try with GEFS for sure!
  - 11d ago
calvinmorrison 11d ago
I have been running GEFS for a number of days and it hasnt crashed 248 ├gefs [ctl.1] 249 ├gefs [mutate.2] 250 ├gefs [sweep.3] 251 ├gefs [tasks.-1] 252 ├gefs [readio.4] 253 ├gefs [syncio.5] 254 ├gefs [srvio.-1] 255 ├gefs [stdio.-1] up 13 days, 15:34:25 send it to production!!
BoingBoomTschak 11d ago
What a wonderful surprise! The nearest thing seem to be modern (v5) XFS + dm-integrity, I'll have to see a comparison once it's stable enough. A thing ZFS suffers from is fragmentation (no way to defragment in-place nor preallocate so stuff like bittorrent doesn't play well with it), which it justifies with its CoW design, wonder if/how it mitigates the problem.
- kjs3 11d ago
  If we're looking at 'future' filesystems, is fragmentation really an issue in an SSD world? Not that there isn't a lot of spinning rust (and will be for quite a while), I don't think it's unreasonable to assume "most block storage is going to be SSD in the future" when allocating resources to priorities.
  - BoingBoomTschak 11d ago
    The day I can furnish my NAS in SSDs for roughly the same price as HDDs probably won't come before any current filesystem is obsoleted for some reason or another, methinks.
    - kjs3 10d ago
      Probably true. My bad.
  - 6d6b73 10d ago
    Fragmentation in ZFS wastes a lot of space. So it doesnt matter if it's SSD or not.
    - kjs3 10d ago
      You're right...I didn't think that through.
- snvzz 10d ago
  >modern (v5) XFS Is still silly, for the same reasons Hans Reiser documented in an article about Reiser4's design. e.g. its b-tree stores directories and small files in the same level of the tree, which makes directory operations bloated, while also hurting cache lines. Fortunately, neither ZFS, Hammer2 or GEFS suffer from this.
ThePowerOfFuet 11d ago
>Error handling is largely commented out. First we do the first 90%, and then we do the last 90%.
- oridb 10d ago
  It's done on 9front. The mechanical work of translating it to OpenBSD is not yet done.
throw0101a 11d ago
From NYC*BUG† May 2023, "GEFS, A Good Enough File System" By Ori Bernstein: * https://www.youtube.com/watch?v=juFndFy72gI https://www.youtube.com/watch?v=juFndFy72gI September 2026 EuroBSDCon presentation from Sunday: * https://www.youtube.com/watch?v=yPoU4QEv_u8&t=49m43s https://www.youtube.com/watch?v=yPoU4QEv_u8&t=49m43s † BSD User Group
tiffanyh 11d ago
All respect to the author on their work, but for me personally - I'm be more interested in Hammer2 (from Dragonfly BSD) to come to OpenBSD. https://github.com/kusumi/openbsd_hammer2 https://github.com/kusumi/openbsd_hammer2
jijji 10d ago
> Error handling is largely commented out. I guess we won't really know when the file system breaks or corrupts data
limagnolia 10d ago
I've always wondered why HAMMER2 from DragonFlyBSD hasn't gotten more attention from other OSes?
- rzerowan 10d ago
  I think its the way their kernel architecture has diverged to this point in time.Seeing as it depends on structures/primitives in DRagonfly that dont exist in the other BSDs. Making a port a bit of a challenge.
  - LargoLasskhyfv 10d ago
    Some people have 'hammered' on it, to varying degrees: https://github.com/kusumi/hammer2 https://github.com/kusumi/hammer2 https://github.com/jdmanring/linux_hammer2 https://github.com/jdmanring/linux_hammer2
Rounin 7d ago
I wonder what it would take to swap out the top layer for a FUSE layer? After all, ten thousand lines is comparatively small, but still a lot of work. On the other hand, having at least one modern file system with most of the bells and whistles that worked everywhere would benefit a lot of people.
tylerius 6d ago
What a nice surprise! It would be great if it finally gets integrated into OpenBSD tree. Corruption Detection and Crash Safety will be more than welcomed here. I can't complain about FFS since it has been fully reliable for me. I have been directly powering off my obsd router for years and never had a problem... in the worst case if I use a very old and semi broken USB drive I have to access console and manually fsck -y some partitions, that's it. I dig the GEFS acronym and concept too.

GEFS: A Good Enough File System https://orib.dev/gefs.pdf https://orib.dev/gefs.pdf

Talk at EuroBSDCon 2026: https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u

g0xA52A2A 11d ago

There was a recent presentation on this at EuroBSDCon for those interested. https://events.eurobsdcon.org/2026/talk/NVMSCJ/ https://events.eurobsdcon.org/2026/talk/NVMSCJ/ https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u

doublepg23 11d ago

This is great timing considering I'm currently dealing with FFS corruption after my OpenBSD server lost power during a storm.

daneel_w 11d ago
Are you sure it's not just a dodgy SSD that simply failed to persist data when losing power mid-write? I've had my share of sudden power cuts upon OpenBSD during the past 20+ years, and FFS has so far never gone corrupt on me.
- doublepg23 11d ago
  I do not believe so? Drive is a 2TB Intel 670p NVMe SSD (INTEL SSDPEKNU020TZ) with 9078 power on hours and 42TBW - so pretty spry, but not at the start of the bathtub curve either. It was mounted as fast storage for a Bitcoin node. Perhaps the only 'unique' thing is it is using a NVMe to PCIe adapter card (Synology M2D20) due to this being my "legacy" server that's still rocking a Broadwell chip.
  - daneel_w 9d ago
    That does sound pretty spry. But it doesn't rule out that it utilizes slow storage which is fronted by a (too) large RAM buffer making the device appear much faster than it really is. Most SSDs are like this.
- yellowapple 11d ago
  I've seen file corruption with FFS on some of my OpenBSD servers, though them being VMs is likely a factor there.
  - oridb 10d ago
    Qcow2 will zero blocks on power loss, at least in some configurations.
- fodkodrasz 11d ago
  FFS corrupted multiple times on me, with intel video driver freezing on OpenBSD. My short OpenBSD sidetrack ended after reliably corrupting itself the third time... every time video driver panicking, leaving a corrupted filesystem after reboot, when I had eg. ports install going on during panic. Windows ran fine on the machine (Lenovo 200) before, and Linux ran fine after. FFS (and the intel video drivers) are the weakest part of OpenBSD in my experience, I liked many other aspects.
  - daneel_w 9d ago
    If writes are happening while the power cuts you will lose that data. Journaling doesn't help against this. FFS will need a consistency check if it doesn't "unmount cleanly", but this isn't the same as the file system having been corrupted and losing data. If something really got corrupted and it was something else besides what you were writing in the moment the machine died, it sounds like a lot of data (for whatever reason large amounts of data was still buffered; usually an SSD is the reason) just hadn't persisted yet. With the exception of the old unadvisable softdeps feature, FFS doesn't defer a lot of writing. And It's possible to tell FFS to be fully synchronous, with the caveat that it becomes even slower than the sluggish performer it already is.
rbc 10d ago
I've run OpenBSD continuously at home without backup power for something like eight years. They probably loose power about once or twice a quarter. I have yet to detect lost data that was important. Measures are taken. If a storm is coming through, I'll shutdown till it passes. I've been lucky with release driver support. The little Lenovo ThinkCentre's being used seem to chug along without crashing on driver issues, at least with OpenBSD releases. The standard OpenBSD partitioning scheme is also being used. Boot time fsck has never failed when the storage was properly attached and in a good state. Backups are performed using pax. So far, so good.

metalforever 11d ago

Finally . Very good work team !

anthk 11d ago

Ori B. it's a great programmer, he fixed a small bug on the earlier GeFS on 9front versions in no time. It worked fine in my n270 based Atom netbook under 9front, so it will run perfectly well under OpenBSD in a near future. It isn't as resource heavy as ZFS, and it will be more reliable than FFS, for sure.

geoffbp 11d ago

> The git repo is hidden on shithub Heh :)

irusensei 11d ago
Is this classic 9front tomfoolery?
- MisterTea 11d ago
  Indeed. If that URL is too crude then one may also use only9fans.com.

moody__ 11d ago

I've been following (and helping test) gefs on 9front for a while now. 9front's nightly builder has been running off of it for quite a while. Ori's done a fantastic job.

sellmesoap 10d ago
Oh my gosh, while I may have heard of 9front in passing I had a little look today and it's super cool! also shithub what an amazing alternative forge, it feels like one of those days when I'm part of the 10,000!
- creeperhost 10d ago
  For reference, the shithub that plan9 uses is not shithub.sh (to any of my knowledge)
  - moody__ 10d ago
    no they are different, our shithub is shithub.us to be specific.
    - sellmesoap 9d ago
      Ahh thanks for getting my shit straight!

yjftsjthsd-h 11d ago

From https://orib.dev/gefs.pdf https://orib.dev/gefs.pdf - > While snapshot consistency is useful to keep data consistent, disks often fail over time. In order to detect corruption, block pointers contain a hash of the data that they point at. If corrupted data is returned by the underlying storage medium, this is detected via block hashes. And if a programmer error causes the file system to write garbage to disk, this can often be caught early. The corruption is reported, and the damaged data may then be recovered from backups, RAID restoration, or some other means. Okay! It's got CoW, snapshots, and data checksums. Therefore, it's good enough to compete with ZFS while being way smaller and permissively licensed. Now I just want it ported to Linux and the other BSDs:)

atmosx 11d ago
I don't think it will compete with ZFS or BTRFS (e.g. I don't think ppl will use GEFS over ZFS or BTRFS for a storage server), but it's a modern, much needed FFS replacement.
- yjftsjthsd-h 11d ago
  Who said anything about storage servers? I'm using zfs on laptops and desktops right now because I want data checksums and a filesystem that doesn't have a history of breaking horribly (I dropped btrfs after the second time it hosed my rootfs). Given the license issue with zfs - and in particular, the technical fallout like needing dkms - I'd be very pleased to replace it.
  - sippingabonedry 11d ago
    > I dropped btrfs after the second time it hosed my rootfs btrfs fans use the "you're using it wrong" excuse a lot. I recall a failure mode that activated when you fill the FS to 100% and their response was "you should never fill a filesystem to capacity"
    - jeffrallen 11d ago
      Otoh, good luck bringing a CoW filesystem back from 100%. Delete a file? Sure, let me just make a copy of all the metadata that was pointing at it using... the zero blocks I have left. Tradeoffs are a bitch, bitch.

fn-mote 11d ago

Is there any chance of proving a filesystem is correct? Is this one simple enough that it won’t have bugs?? Given the issues with well-known filesystems like ZFS and BetterFS, why shouldn’t I expect data-losing bugs in this one?

spijdar 11d ago
I think the premise is basically yes, you should assume there will be data-losing bugs, but: 1. The filesystem should be reasonably good at detecting an error/corruption state and informing you, and 2. You should have backups of said data stored elsewhere, and backups should be tested (e.g. to verify that data can be read back)
cyberpunk 11d ago
What well known data-losing bugs are there in zfs? It can be slow, and resource hungry, but afaik it's about as safe as they come (and I've been using it in prod since solaris 10)
- alethic 11d ago
  There was a long-running data corruption issue with non-raw sends that was finally found and patched in 2025: https://github.com/openzfs/openzfs-docs/issues/494 https://github.com/openzfs/openzfs-docs/issues/494. But I agree, it's about as safe as they come. I trust it far more than any other file system, in large part due to all its built-in redundancy and the way it makes backups trivial (encrypted sends <3)...
- sellmesoap 11d ago
  I never dug into the failure, but I once had a ZFS get to a state where it would crash the kernel on mount, I was able to mount it with checks turned off an recover what was important, but it was a spooky experience. I live on the bleeding edge of file systems for my desktop, I was on reiser4 back when that was fresh, I daily drive bcachefs (it's been great!) Mostly I've been lucky, I don't usually keep an openbsd system around, but I love FreeBSD and I'll give OpenBSD a try with GEFS for sure!
- 11d ago

calvinmorrison 11d ago

I have been running GEFS for a number of days and it hasnt crashed 248 ├gefs [ctl.1] 249 ├gefs [mutate.2] 250 ├gefs [sweep.3] 251 ├gefs [tasks.-1] 252 ├gefs [readio.4] 253 ├gefs [syncio.5] 254 ├gefs [srvio.-1] 255 ├gefs [stdio.-1] up 13 days, 15:34:25 send it to production!!

BoingBoomTschak 11d ago

What a wonderful surprise! The nearest thing seem to be modern (v5) XFS + dm-integrity, I'll have to see a comparison once it's stable enough. A thing ZFS suffers from is fragmentation (no way to defragment in-place nor preallocate so stuff like bittorrent doesn't play well with it), which it justifies with its CoW design, wonder if/how it mitigates the problem.

kjs3 11d ago
If we're looking at 'future' filesystems, is fragmentation really an issue in an SSD world? Not that there isn't a lot of spinning rust (and will be for quite a while), I don't think it's unreasonable to assume "most block storage is going to be SSD in the future" when allocating resources to priorities.
- BoingBoomTschak 11d ago
  The day I can furnish my NAS in SSDs for roughly the same price as HDDs probably won't come before any current filesystem is obsoleted for some reason or another, methinks.
  - kjs3 10d ago
    Probably true. My bad.
- 6d6b73 10d ago
  Fragmentation in ZFS wastes a lot of space. So it doesnt matter if it's SSD or not.
  - kjs3 10d ago
    You're right...I didn't think that through.
snvzz 10d ago
>modern (v5) XFS Is still silly, for the same reasons Hans Reiser documented in an article about Reiser4's design. e.g. its b-tree stores directories and small files in the same level of the tree, which makes directory operations bloated, while also hurting cache lines. Fortunately, neither ZFS, Hammer2 or GEFS suffer from this.

ThePowerOfFuet 11d ago

>Error handling is largely commented out. First we do the first 90%, and then we do the last 90%.

oridb 10d ago
It's done on 9front. The mechanical work of translating it to OpenBSD is not yet done.

throw0101a 11d ago

From NYC*BUG† May 2023, "GEFS, A Good Enough File System" By Ori Bernstein: * https://www.youtube.com/watch?v=juFndFy72gI https://www.youtube.com/watch?v=juFndFy72gI September 2026 EuroBSDCon presentation from Sunday: * https://www.youtube.com/watch?v=yPoU4QEv_u8&t=49m43s https://www.youtube.com/watch?v=yPoU4QEv_u8&t=49m43s † BSD User Group

tiffanyh 11d ago

All respect to the author on their work, but for me personally - I'm be more interested in Hammer2 (from Dragonfly BSD) to come to OpenBSD. https://github.com/kusumi/openbsd_hammer2 https://github.com/kusumi/openbsd_hammer2

jijji 10d ago

> Error handling is largely commented out. I guess we won't really know when the file system breaks or corrupts data

limagnolia 10d ago

I've always wondered why HAMMER2 from DragonFlyBSD hasn't gotten more attention from other OSes?

rzerowan 10d ago
I think its the way their kernel architecture has diverged to this point in time.Seeing as it depends on structures/primitives in DRagonfly that dont exist in the other BSDs. Making a port a bit of a challenge.
- LargoLasskhyfv 10d ago
  Some people have 'hammered' on it, to varying degrees: https://github.com/kusumi/hammer2 https://github.com/kusumi/hammer2 https://github.com/jdmanring/linux_hammer2 https://github.com/jdmanring/linux_hammer2

Rounin 7d ago

I wonder what it would take to swap out the top layer for a FUSE layer? After all, ten thousand lines is comparatively small, but still a lot of work. On the other hand, having at least one modern file system with most of the bells and whistles that worked everywhere would benefit a lot of people.

tylerius 6d ago

What a nice surprise! It would be great if it finally gets integrated into OpenBSD tree. Corruption Detection and Crash Safety will be more than welcomed here. I can't complain about FFS since it has been fully reliable for me. I have been directly powering off my obsd router for years and never had a problem... in the worst case if I use a very old and semi broken USB drive I have to access console and manually fsck -y some partitions, that's it. I dig the GEFS acronym and concept too.