Since ZFS partitions are all taking from the available space of the pool, you can have as many partitions as you need, which is very practical for snapshots and diffs, or if you want to use the same pool for different hosts (=> use a different etc along with a few others like var/lib )
You don't have to go to that extreme. Although, /usr/local should be its own partition for the wxallowed, and /var/log should be its own to keep some nasty logging from screwing everything up. I have a standard /, /home, /tmp, /usr, /usr/local, /var, /var/log. I also am a heretic so I also do /opt.
It actually isn't that hard. I do wish OpenBSD had a more robust filesystem. I switch to FreeBSD when I need a server with lots of storage.
[edit]
the vultr install of OpenBSD only has / and /usr/local
I kinda wish Linux distributions would do this. Sure the /usr/X11R6 is a bit weird, but otherwise I think you should.
You should have at least: /tmp/, /var, /home and /usr by themselfs, personally I'd add /var/log as well. I've lost count of the number of times I had to rescue a Ubuntu system here something filled up either of those directories and now the system isn't responding. Having the entire disc filled up doesn't make it easier to fix.
OpenBSD's X distribution (xenocara) is based on X11R7.7 + updated components, it's just a historical naming convention. Other systems have merged X into /usr or /usr/local, OpenBSD kept the install prefix.
All of them that I can remember. Note that this is from the '90s. At some point they all merged the X stuff into /usr. Maybe it was with the x.org switch, as XFree86 does indeed mention /usr/X11R6 in the docs.
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
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
Anyone using ZFS should!
Since ZFS partitions are all taking from the available space of the pool, you can have as many partitions as you need, which is very practical for snapshots and diffs, or if you want to use the same pool for different hosts (=> use a different etc along with a few others like var/lib )
Look at the set of partitions I recommend on https://github.com/csdvrx/zfs-autosnapshot (this is for the host 7275 on the pool nvme)
zfs create -o mountpoint=/ nvme/7275
zfs create -o mountpoint=/etc nvme/7275/etc
zfs create -o mountpoint=/opt nvme/7275/opt
zfs create -o mountpoint=/usr nvme/7275/usr
# for optimization
zfs create -o mountpoint=/img recordsize=1M primarycache=metadata secondarycache=none nvme/7275/img
zfs create -o mountpoint=/img/qcow2 recordsize=64k nvme/7275/images/qcow2
# for safety
zfs create -o mountpoint=/var nvme/7275/var
zfs create -o mountpoint=/var/tmp nvme/7275/var/tmp
zfs create -o mountpoint=/tmp nvme/7275/tmp
zfs set exec=off nvme/7275/var
zfs set setuid=on nvme/7275/var/tmp
zfs set setuid=off devices=off sync=disabled nvme/7275/tmp
# for systemd-journald
zfs create -o mountpoint=/var/log nvme/7275/var/log
zfs set acltype=posixacl nvme/7275/var/log
# for postgresql optimization
zfs create -o mountpoint=/var/lib nvme/7275/var/lib
zfs create -o mountpoint=/var/lib/postgresql nvme/7275/var/lib/postgresql
zfs set recordsize=8K primarycache=metadata logbias=throughput nvme/7275/var/lib/postgresql