On Tue, Dec 10, 2024 at 03:59:03PM -0500, Implausibility wrote: > > > 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. 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 -- and the penalty for > getting it wrong under OpenBSD is quite severe... As far as I know, > there's no good way to move / expand / reduce filesystems, and the > only way forward is to rebuild from scratch with new numbers. Today, > I have / and /var as the only two filesystems (plus swap), and I will > graft additional block storage onto specific mount points if there's a > subdirectory that expands beyond what has been allocated.
It does not have to be this way. One truly good advice I got from this list (can't remember from whom, probably Nick Holland) is: resist the temptation to allocate the entire disk for partitions. Start with some sane amounts for the basics (/, /tmp, /usr, /usr/local, ...) and then some big chunks for wherever you predict you'll need more. But don't get greedy, and leave a good unallocated area at the end of the disk. Storage capacities are huge, nowadays, so there is plenty of capacity to spare. Remember that you can't shrink a filesystem, but you can expand one with growfs so a partition too large is an unsolvable problem, but a partition too small isn't. If one of the partitions gets too full, just edit the disklabel, create a new larger partition on the unallocated space, newfs, dump|restore, edit fstab, umount old, mount new, done. You'll have a "hole" in the middle of the disk, true, but maybe that will become handy later on, if something else needs to grow. Or, if you are comfortable with the process, and if the 'hole' is big enough, you can even shuffle some of the partitions around, if needed be. > > Thanks for your comments. > > --
