> Am 10.12.2024 um 21:59 schrieb Implausibility <open...@hottub.ca>: > > >> On Dec 10, 2024, at 3:40 PM, Mike Fischer <fischer+o...@lavielle.com> wrote: >> >> For a low-traffic site that should be fine. >> >> The actual disk footprint depends on your needs of course. Only you know >> what those are. How big are your DocumenRoot directories, databases and >> mailboxes? > > The only large-ish site (30GB) will live on it's own block storage device.
If your webserver runs in a chroot(2) environment, then this might not work. (No idea whether nginx does or not, or whether chroot(2) can span multiple filesystems …) > Everything else is under 1GB. > >> It may make sense to partition the disk manually so that e.g. MySQL >> (MariaDB?) and the webserver have enough space in /var and OpenSMTPd has >> enough space in /var/mail and /home. Just make sure /usr/local is big enough >> for all your installed ports with some space to spare and I have done well >> with a swap partition equal to the RAM size. Also make sure you have enough >> reserve space to comfortable do future OpenBSD upgrades. > > This is my concern. I've never been able to wrap my head around how anyone > can predict their future disk usage Technically you can’t of course. But experience gives some good values for the system’s needs. Add your application/user data sizes + some reserve space and you have a good start. One strategy I have successfully used: - Look at what the auto-partioning does on a 20-40GB disk. (disk label and /etc/fstab) - Then manually partition your larger disk and copy the sizes of /, /usr, /usr/X11R6, /usr/src, /usr/obj from the smaller disk. - Set swap=RAM size. - And allocate the rest (/tmp, /usr/local, /home, /var) according to your projected needs + reserve, but generally no smaller than on the small disk. - Of course if this is a server and you know you don’t need much space in /home, then you can adjust that size down and give the space to /var for example. - If you don’t use X11 then /usr/X11R6 could be very small or left out. - If you never plan to compile the kernel or base system then /usr/src and /usr/obj can be very small (or left out entirely). However if you do that, Murphy dictates that you will run into a situation where you need to apply a patch to the kernel ;-) But then temporary block storage might be an easy fix. Or compile on a different machine (same architecture) and copy the resulting binaries. > -- and the penalty for getting it wrong under OpenBSD is quite severe... Yes. > As far as I know, there's no good way to move / expand / reduce filesystems, I did that once as an experiment: resized the physical volume, then adjusted partition sizes by recreating and copying. The process is not fun and the result is less than optimal with unused holes between the new partions. > and the only way forward is to rebuild from scratch with new numbers. Basically yes. > Today, I have / and /var as the only two filesystems (plus swap), Not such a good idea IMHO. You are giving up some of the security the different settings for the default partitions offer. > and I will graft additional block storage onto specific mount points if > there's a subdirectory that expands beyond what has been allocated. If that is an option with your hoster/hypervisor then it can make "resizing" partitions somewhat easier. Good backups may also help (for the case where you do need to start from scratch). That might also happen when filesystems get broken due to unclean shutdowns of the VM. Another OpenBSD filesystem annoyance. And of course good documentation about your setup is always a good idea. Makes recreation of a server much easier. Mike
