Who still partitions like that???
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
It also taints the kernel, which is interesting.
FYI this list was created to address Ubuntu's choices for ZFS datasets, which I think are suboptimal.
> It also taints the kernel, which is interesting.
Oracle could fix the ZFS situation at any time if they wanted to (and then get some positive feelings which they sorely need).
They don't. Personally, I don't care much. They may eventually change, like Microsoft did.
It's in their best interest: adapt or die.
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
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.
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
_x11 71289 0.0 0.6 11164 24992 ?? S 9:06AM 0:00.41 /usr/X11R6/bin/X :0 vt05 ...
root 2878 0.0 0.0 2696 1412 ?? IpU 9:06AM 0:00.04 X: [priv] (Xorg)
http://www.undeadly.org/cgi?action=article&sid=2005082419031...
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.
Among others - is it supported by any hosting vendor or I'll be forced to tinker with it myself without even cloud-init tooling?
* 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
So on.
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.
1984.is has OpenBSD as an install option; that's what I use for my mailserver and webserver.
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.
Yup, the journaling is the nail in the coffin for me. I scratch my head when people recommend it as a network appliance due to the data loss issues.
> retro computing
I kind of do use it in that niche. I enjoy finding the oddball hardware OpenBSD runs on with, at least partial, -current support.