As for why: A power loss will likely only affect filesystems being written to. So less risk of ending up with an unbootable system if / and /usr are not being written to.
Even moreso if they are mapped read-only.
I don't know about now, but I've seen people only enable softdep mount option for FSs that need some extra speed, and not on / and /usr. (article does this for /home. look at the listed mount options)
It's also nice to mount /tmp and /home with "nosuid" and "nodev". Some file systems even "noexec".
Edit:
Note that I'm not advocating for it. I'm merely listing reasons one could have.
Yeah. I don't quite remember now, but I think many of the packages don't work if you don't have a separate /usr/local fs, since the packages need wxallowed.
Unless you want to enable wxallowed on / or /usr.
Then of course there's the fact that they don't do journalling. It's not my expertise but if literally everyone is doing journalling instead of softdep, then maybe they're right.
I've used OpenBSD off and on since 2.1, and I've experienced much more data loss on it than on Linux. So yeah I'm also not a fan of OpenBSD's filesystems.
I feel like OpenBSD don't have enough staffing to do the right things (e.g. Wayland, Bluetooth), so instead they try to do what they can, but right.
Which is fair enough, but will become more and more like retro computing for every year that passes.
I'm honestly in much doubts here. To make it proper reply it must be lengthy, will try to highlight at least several points and keep it short.
* finding FreeBSD guys, who probably the best match here is somewhat puzzle on its own
* highly likely common approaches in modern world would fail - cloud-init, systemd units to be adopted, not even mentioning Docker/podman and highly likely monitoring/metrics tooling. Not checked, but very unsure NewRelic or Datadog are compatible => admins will not be able to use their previous skillset effectively
* convincing people to join team of supporting OpenBSD systems can be somewhat tricky. I'm basing on my own feelings here - I'd rise the bar for salary 2 times and even that will think twice on should I spend my time on such experience
* leaving performance alone, I bet it will require extra hardware planning instead of buying any Supermicro/HP/whatever server and be sure it's Redhat compatible. Must be very serious reasons to put yourself in chores of this sort. And reasonable admins must consider such risks and delays for rollouts of products in production
I guess that's part of "adaptation" and for humans probably not a bit deal
But I feel that would be the top of the iceberg - bottom part would be - how much of other tooling, say Ansible will fail? Homegrown scripts will fail?
Amount of efforts seems to be very high for, let's say politely unknown and unclear benefits.
OpenBSD has certain flags it sets on various partitions to enable/disable performance and security features. Sort of like setting `noexec` on /tmp, using XFS instead of BTRFS on your database volume, etc. Like most OpenBSD things, it stays way on the "correctness/security" side of the "security--convenience" scale
As for why: A power loss will likely only affect filesystems being written to. So less risk of ending up with an unbootable system if / and /usr are not being written to.
Even moreso if they are mapped read-only.
I don't know about now, but I've seen people only enable softdep mount option for FSs that need some extra speed, and not on / and /usr. (article does this for /home. look at the listed mount options)
It's also nice to mount /tmp and /home with "nosuid" and "nodev". Some file systems even "noexec".
Edit:
Note that I'm not advocating for it. I'm merely listing reasons one could have.