> 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:)
I've always wondered about similar designs: Doesn't calculating a hash of every block, on every read and every write, create lots of overhead? Why isn't that a problem?
Some systems have dedicated crypto co-processors for confidentiality (encryption) - e.g., I think drives with FDE, and I think Apple Silicon SoCs might have them. Can those be repurposed for hash calculation? What about systems that lack them?
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.
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.
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)
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!
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. 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)...
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.
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.
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.
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.
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.
From 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:)
I've always wondered about similar designs: Doesn't calculating a hash of every block, on every read and every write, create lots of overhead? Why isn't that a problem?
Some systems have dedicated crypto co-processors for confidentiality (encryption) - e.g., I think drives with FDE, and I think Apple Silicon SoCs might have them. Can those be repurposed for hash calculation? What about systems that lack them?
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.
There was a recent presentation on this at EuroBSDCon for those interested.
https://events.eurobsdcon.org/2026/talk/NVMSCJ/
https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u
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.
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?
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)
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)
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!
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. 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)...
Talk at EuroBSDCon 2026: https://exquisite.tube/w/3QQimMdswWJxrsPaJtak2u
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!!
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.
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.
GEFS: A Good Enough File System https://orib.dev/gefs.pdf
> The git repo is hidden on shithub
Heh :)
This is great timing considering I'm currently dealing with FFS corruption after my OpenBSD server lost power during a storm.
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.
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.
Finally . Very good work team !
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.