GEFS on OpenBSD: A Early Preview(marc.info) |
GEFS on OpenBSD: A Early Preview(marc.info) |
> 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:)
Does it have a built-in RAID layer? Because if it doesn't, then it can't compete with ZFS in many use cases. For example, what does "data may then be recovered from […] RAID restoration" mean?
With ZFS, if you have a (e.g.) mirrored/RAID-1 configuration, and you fetch some data from one drive and the checksum is wrong, ZFS can check the other drive, and if that checksum is good it can (a) pass the good data up, and (b) use the good data to fix the bad data. Most mirroring systems can't do that both-drives checking: ZFS is self-healing.
(This isn't to say that GEFS won't be useful in many other situations.)
We'll see where things go.
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?
Both implement sha256, which does impose a heavy speed penalty.
ZFS allows you to adjust the checksum on the fly, using something faster (Fletcher) if desired.
In btrfs, a global checksum is set at filesystem creation; xxhash is the best modern option.
There is a website: https://xxhash.com
Deduplication adds concerns for a strong hash free of collisions.
And if you are concerned about the compute rather than storage, then writing to a block device is still slow enough so that computing a checksum isn't important performance-wise.
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.
* https://www.youtube.com/watch?v=juFndFy72gI
September 2026 EuroBSDCon presentation from Sunday:
* https://www.youtube.com/watch?v=yPoU4QEv_u8&t=49m43s
† BSD User Group
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.
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.
First we do the first 90%, and then we do the last 90%.
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!!
It isn't as resource heavy as ZFS, and it will be more reliable than FFS, for sure.
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?
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)
I guess we won't really know when the file system breaks or corrupts data
Heh :)
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.
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.
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.
* https://openzfs.github.io/openzfs-docs/man/master/7/zfsprops...
* https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Data...
* https://en.wikipedia.org/wiki/Fletcher%27s_checksum
* https://people.freebsd.org/~asomers/fletcher.pdf
* https://www.intel.com/content/www/us/en/developer/articles/t...
Originally documented in the paper "An Arithmetic Checksum for Serial Transmissions" (referenced also in RFC 1146, in the context of TCP).
TRIM commands sent to the block layer would probably help with SSD/NVMe wear leveling, as well as thin-provisioning in virtualized environments.
And the lack of RAID is not a critique: if you're mostly interested in the file system layer that's fine, and a useful area to solve problems in. My comment was more towards the comparison to ZFS and its "rampant layering violation" [1] and some of the trade-offs that happen when you focus on more or fewer parts of the stack.
[1] https://web.archive.org/web/20070602005153/http://blogs.sun....
Unrelated: and since you're surfing the comments, with regards to your superblocks [1], you may wish to look into some of the lessons learned by ZFS; specifically see perhaps Allan Jude's "Large Label and Blockpointer-V2" from the 2025 OpenZFS Dev Summit: https://www.youtube.com/watch?v=3tqOBv8BmXI
[1] https://orib.dev/gefs.pdf § 9.1
I'll probably be picking Allan's brain on a few things in the coming few months; amusingly, he mentioned doesn't use ZFS for ZFS development so that he can unload and reload the module, and he's interested in something that won't corrupt when he panics the kernel.
At this point in software/file system history, having some kind of TRIM functionality I think is pretty important: either built in, or a separate utility (like fstrim(8) for ext4, etc).
Are you planning to (eventually?) do a RAID (or at least mirror) layer, or will this strictly stick do file systems?
To the point:
- llm'ed or not, dasn't matter, just quality matter
- raid ? I know nothing about that but looks like pure hardware raid (if that exists), no "raid layers" at all and fs raid aware are three different animals. But adding something about raids will complicate things before "production ready" stability. Which, of course, we want ASAP ;)
- 8k+ seems easy to manage and bend so maybe key-value only partitions ?
- obviously wishlist is easy to construct (key-value storage, encryption, power off resistance, mail reading ;) ) so maybe some plugin system or at least guidelines for peoples before we will have repos of patches DWM-style ? :)
- that 5 second is clearly stated but a bit strange limit and obviously peoples will want to do something with that
- man give us producion readiness before you will be puched by some corporation, swamped with work and hidden from daylight, pls ? Pleas do not fall into Compiz trap...
- thank you :)
Running ZFS since it was originally released on Solaris (June 2006) with zero problems (then FreeBSD, then Linux), including on RAID-5/6 (RAID-Z1/2) configurations, which btrfs still does not recommend using all these years later:
* https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
What have the btrfs developer(s) been doing for the last decade(+) that the code is still of debatable dependability?
From what I understand single copy setups, RAID 1, and RAID 10 never had the same problem. It's left a bad taste for a lot of people though.
Very early ext4 versions also had some data loss or data corruption, but I never hear people dismiss it completely for that brief spot of its history. Maybe part of that is because it was around 17 years ago and it's been a reliable default OS for many years now.
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"
You should be able to dd /dev/zero to a file and not worry about the entire filesystem shitting the bed.
Tradeoffs are a bitch, bitch.
Also, some failure modes are worse than others. The failures known as DI (data integrity) are the worst. Even though they aren't expected to happen to everyone at a certain frequency (because, again, mature storage software is comparatively very reliable), even a single DI error that happened to any user sets up a major alarm.
In the storage industry, the running joke is that after first DI in your product you lose funding, after the second DI you loose the product.
And it did happen to Btrfs quite a bit... I've seen it with my own eyes when a system didn't come back after power failure. (But I'm in the business of testing software storage products, so, it's less surprising that it happened to me).
So... it's perfectly plausible that you have never seen Btrfs fail, and it's been more error prone than eg. EXT4. The error rate is low enough so that if you don't actively try to cause the error you will never experience one. But, over a large group of diverse use patterns, the rate is still worse than expected.
Famous last words. Most failures are not reported, because people move on.
In my experience, btrfs is actually more reliable than other filesystems due to its checksumming abilities, but when it does fail, it's much harder to fix than with other filesystems (which will often try to continue on even when stuff is broken).
I did.
> I'm using zfs [...]
ZFS is primarily used on single-storage appliances.