On 6/4/19 1:29 PM, Mogens Jensen wrote: > I'm going to build a router for use in a remote location, and I have > chosen OpenBSD 6.5 for the task. Unfortunately, it's not possible to > protect the router with an UPS, so it will have to be resilient enough > to survive sudden power outages and still boot without manual > intervention. > > In the past I have built a few Linux based routers and they were > configured to run from RAM. I have made some research to see if this is > also possible on OpenBSD and found that, while there are solutions to > have / read-only, none of this is officially supported. > > Can anyone with experience running OpenBSD routers without UPS, tell if > filesystem corruption is going to be a problem after power outages, or > if there are any officially supported ways to make the system resilient > enough to not break after a power outage? > > I'm using an mSATA disk with MLC flash in the router.
I realized a few decades ago that consumer UPSs are a bad investment. Industrial UPSs are a dubious idea in business unless you have a dual-power supply machine and can hook each PS to a DIFFERENT UPS -- in my area, grid power is more reliable than cheap UPSes (your mileage may vary). And you have to MAINTAIN your UPSs, otherwise after a few years, UPSs turn minor glitches into power outages (thank you very much). I'm also fond of proving my own claims, so I very often just yank the cord on my systems rather than doing orderly shutdowns. Yes, if you drop power on an OpenBSD system, you will get an fsck on reboot. Solution: Make your partitions as small as reasonable. Just because you got a 500G disk for cheap, no reason to allocate all 500G. For a router, 10G is PLENTY, and will fsck quickly. If you have slow media (i.e., flash drives), you might want to aim for 1G. Every once in a long while, you might catch a really bad time for the power to go out, and have to manually say "Fix it!" to fsck, but for the most part, the system will just come back up after the power comes back on. The less you write to disk, the less risk you have of having to manually intervene in your system's reboot. IF you want to do some fancy logging, keep the logging partition out of the fstab file, and have a script that brings it up with a "fsck -y" AFTER the system comes up, and start the fancy logging AFTER the big logging partition successfully mounts. But don't do stupid games to try to improve your chances, just make sure there's a monitor and keyboard available to fix any problems that might happen. Simple systems have simple problems. Complex systems break in complex ways. You want me to swear you'll never have to manually intervene in boot after an "event"? Nope. But I've walked non-technical people through single-user fsck's over the phone; when your bastardized system breaks, you will be down for a lot longer and you will be going on-site to fix. Nick.
