I doubt that anything could have changed, because OpenBSD has not implemented any new file system and a few years ago they have even removed the support for "UFS with soft updates", which is a file system that is not affected by power failures, but the OpenBSD developers could not maintain it, because apparently today nobody understands it any more.
Thus there is no doubt that the UFS variant used by OpenBSD remains very sensitive to power failures, so this will remain a persistent problem, until they add a more resilient file system.
The right technical solution would have been to merge a good Linux file system, e.g. XFS, but that is impossible because of license conflicts.
The alternative is to take ZFS from FreeBSD, which might be OK, but I do not know this for sure, because on FreeBSD I use only "UFS with soft updates" which works fine for me and it is still immune to power failures.
I have some knowledge of the BSDs and they all are but OpenBSD is particularly belligerent about Licenses and they consider ZFS "non–free" on par with the GPL(I know I know) which is a huge barrier to entry into the kernel. They only begrudgingly accepted clang after they changed their license because there was no real alternative. Before that they had been using some ancient GPLv2 gcc.
Truth is, I've never had a catastrophic data loss on traditional filesystems like ext2 and ufs and the devs probably haven't had one either so they don't feel like the situation is the same as with lacking a compiler.
I read the article about why they removed soft updates and the gist of it was that the maintainer moved on and no one else was willing to understand the complex system anymore.
I'd imagine ZFS is at least on the same level of complexity.
So, two pretty tall hurdles to clear.
If someone gave them a filesystem with the right license, ideas from 20+ years ago and a promise to maintain it on OpenBSD forever, I'm sure they'd take it.
> they consider ZFS "non–free" on par with the GPL
Why isn't it? The CDDL is basically the MPL, which in-turn is basically the LGPL.
The jihad against the GPL by FreeBSD and conveniently ignoring the CDDL being weak-copyleft was always ironic to me.
> and the devs probably haven't had one either
solene@ left and stated the filesystem as a supporting reason:
> I have grievances against OpenBSD file system. Every time OpenBSD crash, and it happens very often for me when using it as a desktop, it ends with file corrupted or lost files. This is just not something I can accept.
>If someone gave them a filesystem with the right license, ideas from 20+ years ago and a promise to maintain it on OpenBSD forever, I'm sure they'd take it.
They have the right to take NetBSD's UFS (with WAPBL), FreeBSD's (UFS with softupdate) or DragonFly's Hammer2.
Or give users the freedom to use ZFS (optionally) like NetBSD.
Filesystem fragility is the #1 embarrassment of Unix since time immemorial, and it is shameful that Linus and all the BSD developers cannot be arsed with a default filesystem that is robust and resilient in this regard.
I was just crowing the other day with my parents about the filesystem resilience of the simple Amiga Workbench system. I reminded Dad how you can't just pull the plug on Windows since 3.0. You can't pull the plug on DOS if you're in an app, for that matter. But Amiga, you could just hit the power button whenever you pleased, and the filesystem was none the worse for wear, because it was designed well.
Back in the heyday of Raspberry Pi 3, I was tinkering with a kit, but I moped into a Linux User Group meeting, complaining how often I'd ruined an sdcard filesystem after being forced by circumstance to pull the plug. And a nerd, an AWS Engineer by profession, ignored or misread the situation of the humble SBC, and he told me 'just install ZFS' and also 'stop pulling the plug'.
He did not understand the Raspberry Pi, and I let him know exactly how I felt about his idiotic, misplaced advice. Yes, sure, ZFS for the big systems with gobs of memory and UPS backups. Personally I kinda liked btrfs.
Also the author of today's article cannot spell "gigabytes" and for a storage specialist, that's a real bad look, kids. Learn how to abbreviate, and you communicate better. Spell your units wrong, and you appear uneducated and inexperienced.
But any filesystem in 2026 that simply can't survive a power-cut does not deserve to be in an OS that is High Availability and Redundant and promising >4 nines of uptime. I mean seriously. If this guy's hacks involve mounting rofs everywhere, then ufs (or whatever OpenBSD still uses) has failed again, in 2026, after 56 years' worth of trying to get it right.
File system fragility was indeed still an embarassment of many UNIX-derived file systems, up to twenty years ago and perhaps until more recently, but this is no longer true today.
Even in the early 2000's, there was one UNIX file system, the FreeBSD UFS with "soft updates", which was completely immune to computer crashes caused by power failures or by anything else, at a time when the journaled file systems of Linux, and also NTFS of Microsoft, were still buggy enough that power failures could result in bricked computers, despite their claims that journaling should protect against this.
But since then, most bugs have been fixed and now at least for XFS I know with certainty that it can pass through numerous power failures without any problems and with no filesystem corruption.
What exactly about the Amiga FFS made it more fault tolerant?
I’m not sure comparing the file system on a single user workstation where disk is probably quiescent most of the time to the file system used on a busy server is really apples to apples. The Wikipedia article on the Amiga FFS makes it sound like it was an early journaled file system, but not technically superior to anything developed since. It plays back the journal if not shut down cleanly. All modern filesystems do that.
OpenBSD uses FFS btw (not the same FFS as the Amiga).
I ... do not know. I do not know how I came to believe these things. It seems they are false beliefs. The Amiga filesystems were not particularly resilient. I suppose I just finished lying to my parents again. I really should fact-check every damn thing I remember, before talking out my ass about them. I surely live in a fantasy dream world.
Having just read through Wikipedia, though: OpenBSD uses UFS, which layer is referred to as ffs in the userspace. It's potato, potato. The soft-updates should have readily mitigated corruption issues, though they didn't entirely go away. LFS is another component to UFS/ffs, as a formally log-structured filesystem.
Reader beware. Article is from 2022 and stuff has probably changed a lot. OpenBSD is currently in version 7.9, article talks about 6.6.
Also the PC Engines APU2 the author speaks about is EOL and no longer in production.
I do like how the article is clearly dated at the top. I believe all internet articles should be dated - it provides a huge amount of context imo.
I doubt that anything could have changed, because OpenBSD has not implemented any new file system and a few years ago they have even removed the support for "UFS with soft updates", which is a file system that is not affected by power failures, but the OpenBSD developers could not maintain it, because apparently today nobody understands it any more.
Thus there is no doubt that the UFS variant used by OpenBSD remains very sensitive to power failures, so this will remain a persistent problem, until they add a more resilient file system.
The right technical solution would have been to merge a good Linux file system, e.g. XFS, but that is impossible because of license conflicts.
The alternative is to take ZFS from FreeBSD, which might be OK, but I do not know this for sure, because on FreeBSD I use only "UFS with soft updates" which works fine for me and it is still immune to power failures.
I have some knowledge of the BSDs and they all are but OpenBSD is particularly belligerent about Licenses and they consider ZFS "non–free" on par with the GPL(I know I know) which is a huge barrier to entry into the kernel. They only begrudgingly accepted clang after they changed their license because there was no real alternative. Before that they had been using some ancient GPLv2 gcc.
Truth is, I've never had a catastrophic data loss on traditional filesystems like ext2 and ufs and the devs probably haven't had one either so they don't feel like the situation is the same as with lacking a compiler.
I read the article about why they removed soft updates and the gist of it was that the maintainer moved on and no one else was willing to understand the complex system anymore.
I'd imagine ZFS is at least on the same level of complexity.
So, two pretty tall hurdles to clear.
If someone gave them a filesystem with the right license, ideas from 20+ years ago and a promise to maintain it on OpenBSD forever, I'm sure they'd take it.
> they consider ZFS "non–free" on par with the GPL
Why isn't it? The CDDL is basically the MPL, which in-turn is basically the LGPL.
The jihad against the GPL by FreeBSD and conveniently ignoring the CDDL being weak-copyleft was always ironic to me.
> and the devs probably haven't had one either
solene@ left and stated the filesystem as a supporting reason:
> I have grievances against OpenBSD file system. Every time OpenBSD crash, and it happens very often for me when using it as a desktop, it ends with file corrupted or lost files. This is just not something I can accept.
https://dataswamp.org/~solene/2024-11-15-why-i-stopped-using...
> The jihad against the GPL by FreeBSD and conveniently ignoring the CDDL being weak-copyleft was always ironic to me.
CDDL is not viral.
Honest question: Am I the only one bothered by the fact that this author puts her name absolutely everywhere on her posts? Feels very ego-trippy.
>If someone gave them a filesystem with the right license, ideas from 20+ years ago and a promise to maintain it on OpenBSD forever, I'm sure they'd take it.
They have the right to take NetBSD's UFS (with WAPBL), FreeBSD's (UFS with softupdate) or DragonFly's Hammer2.
Or give users the freedom to use ZFS (optionally) like NetBSD.
The same article for FreeBSD:
- Install FreeBSD in defaults with Auto (ZFS) option.
- Do not thing more.
- You are resilient for power outages.
Regards,
vermaden
Filesystem fragility is the #1 embarrassment of Unix since time immemorial, and it is shameful that Linus and all the BSD developers cannot be arsed with a default filesystem that is robust and resilient in this regard.
I was just crowing the other day with my parents about the filesystem resilience of the simple Amiga Workbench system. I reminded Dad how you can't just pull the plug on Windows since 3.0. You can't pull the plug on DOS if you're in an app, for that matter. But Amiga, you could just hit the power button whenever you pleased, and the filesystem was none the worse for wear, because it was designed well.
Back in the heyday of Raspberry Pi 3, I was tinkering with a kit, but I moped into a Linux User Group meeting, complaining how often I'd ruined an sdcard filesystem after being forced by circumstance to pull the plug. And a nerd, an AWS Engineer by profession, ignored or misread the situation of the humble SBC, and he told me 'just install ZFS' and also 'stop pulling the plug'.
He did not understand the Raspberry Pi, and I let him know exactly how I felt about his idiotic, misplaced advice. Yes, sure, ZFS for the big systems with gobs of memory and UPS backups. Personally I kinda liked btrfs.
Also the author of today's article cannot spell "gigabytes" and for a storage specialist, that's a real bad look, kids. Learn how to abbreviate, and you communicate better. Spell your units wrong, and you appear uneducated and inexperienced.
But any filesystem in 2026 that simply can't survive a power-cut does not deserve to be in an OS that is High Availability and Redundant and promising >4 nines of uptime. I mean seriously. If this guy's hacks involve mounting rofs everywhere, then ufs (or whatever OpenBSD still uses) has failed again, in 2026, after 56 years' worth of trying to get it right.
File system fragility was indeed still an embarassment of many UNIX-derived file systems, up to twenty years ago and perhaps until more recently, but this is no longer true today.
Even in the early 2000's, there was one UNIX file system, the FreeBSD UFS with "soft updates", which was completely immune to computer crashes caused by power failures or by anything else, at a time when the journaled file systems of Linux, and also NTFS of Microsoft, were still buggy enough that power failures could result in bricked computers, despite their claims that journaling should protect against this.
But since then, most bugs have been fixed and now at least for XFS I know with certainty that it can pass through numerous power failures without any problems and with no filesystem corruption.
Actually it's a shame that motherboards don't provide a battery that will allow the system to save file, even if the battery life is just 30 seconds.
What exactly about the Amiga FFS made it more fault tolerant?
I’m not sure comparing the file system on a single user workstation where disk is probably quiescent most of the time to the file system used on a busy server is really apples to apples. The Wikipedia article on the Amiga FFS makes it sound like it was an early journaled file system, but not technically superior to anything developed since. It plays back the journal if not shut down cleanly. All modern filesystems do that.
OpenBSD uses FFS btw (not the same FFS as the Amiga).
I ... do not know. I do not know how I came to believe these things. It seems they are false beliefs. The Amiga filesystems were not particularly resilient. I suppose I just finished lying to my parents again. I really should fact-check every damn thing I remember, before talking out my ass about them. I surely live in a fantasy dream world.
Having just read through Wikipedia, though: OpenBSD uses UFS, which layer is referred to as ffs in the userspace. It's potato, potato. The soft-updates should have readily mitigated corruption issues, though they didn't entirely go away. LFS is another component to UFS/ffs, as a formally log-structured filesystem.
> how you can't just pull the plug on Windows since 3.0.
Good luck with that. I had to make a shortcut to mark the filesystem dirty before reboot or else Windows will not check it after crash/power off.