This is the first I've read that OpenBSD's file system is "notoriously flaky", "bubblegum-and-string" (the opposite of the OpenBSD approach) or make "the least reliable device in the network". The reputation is the opposite.
> visit the console like Sam Jackson in Jurassic Park
Consoles aren't so unusual for most server admins, IME. They're the most common tool.
It seems you’ve read too much general OpenBSD hype material and too little specific information about details like the filesystem. The OpenBSD filesystem notoriously lacks journalling support. It used to support soft updates, but that got removed too. There are no seatbelts. If you suddenly lose power, there is a high likelihood you lose data. OpenBSD is notorious for it.
For those that don't know soft updates are a clever method to prevent filesystem corruption.
Journaling: write the journal, write the filesystem, in event of sudden power outage either the journal will be partially corrupt and discarded or the filesystem will be corrupt and the journal can be replayed to fix it, the problem is that now you are duplicating all metadata writes.
Softupates: reorder the writes in memory so that as the filesystem is written it is always in a consistent state.
So softupdates was a clever system to reduce metadata writes, perhaps too clever, apparently it had to be implemented chained through every layer of the filesystem, nobody but the original author really understood it and everyone was avoiding doing filesystem work for fear of accidentally breaking it. And it may not of even worked, there were definitely workloads where softupdates would hose your data.(I am not exactly sure, But I think it was a ton of small metadata rewrites into a disk full) So when someone wanted to do work on the filesystem but did not want to deal with softupdates, obsd in characteristic fashion said "sure, tear it out" It may come back, I don't know the details, but I doubt it. It sounds like it was a maintenance problem for the team.
Journaling conversely is a sort of inelegant brute force sort of mechanism, but at least it is simple to understand and can be implemented in one layer of the filesystem.
Log message:
Make softdep mounts a no-op
Softdep is a significant impediment to progressing in the vfs layer
so we plan to get it out of the way. It is too clever for us to
continue maintaining as it is."
You don't need to talk about other commenters; because you don't know them (with few possible exceptions) you're certain to make a fool of yourself.
The components and their potential benefits aren't really consequential; performance is. Sometimes, the hi-spec components are technologically interesting and exciting to geeks (me too), but have little practical value, especially maximalist components like ZFS. I've never needed it, for example. Very rarely could a journaling file system provide an actual benefit, though I don't object to them.
Sometimes the value is negative because the complexity of those components adds risk. KISS.
> visit the console like Sam Jackson in Jurassic Park
Consoles aren't so unusual for most server admins, IME. They're the most common tool.