Hacker News Reader

Comment by ninkendo | Hacker News Reader

I put OpenBSD on my router earlier this year to get in-kernel NAT64 support and to learn pf, among other things.

I’m massively regretting that choice due to the UFS root filesystem. Power outage? Hope you weren’t planning on your internet coming back up without manual intervention. Get ready to plug that keyboard in and type “fsck” manually at boot, and press “y” a few dozen times while it asks you questions about what to do with corrupted inodes. I hope none of that data is important to the correct operation of the system!

A filesystem lacking journaling support in 2023 is an absolute travesty given that the rest of the world has had this problem solved for 25 years or so.

View on HN

Could you perhaps run it with a read-only root filesystem (only mounting r/w for changes/upgrades)?

I’d have to put /etc on another partition, which really means I’d have to up front plan to put every damned writable thing on its own partition, which OpenBSD encourages specifically because it allows you to mount more stuff as r/o. And even then, any partitions which are writable would not be able to be mounted after boot until I do the same ridiculous fsck dance.

But that’s, in my opinion, brain-dead stupid when it only exists to work around the idiocy of not having a journaled file system like ever other modern OS has had for the past 25 years. Having to up-front plan a size (and inevitably get it wrong) for half a dozen partitions, just to work around glaringly obvious weaknesses in the OS itself, is beyond stupid.

You are on point. I still use OpenBSD where it makes sense though—in your case it does not. All my OpenBSD systems are backed by a UPS, but a crash, while rare, could still readily cause file system corruption.

Here's how I solved it:

https://www.mimar.rs/blog/how-to-increase-openbsds-resilienc...

I know of the non-standard workarounds, I'm just not interested in doing them unless it's for a very specific deployment and needs to be repeatable across a large number of systems.

Great article and a cool way to learn more about the inner workings of OpenBSD, thanks for sharing. I like the idea of a separate /var/syspatch directory. I typically make separate /var/log and /var/www directories too.

I noticed you're using a good quality SD card and wrote a couple times about flash wear, is there any reason you didn't opt for an mSATA SSD? It might be more resilient than SD.

OpenBSD has soft updates as an option. I don't recall ever having to manually fsck a FreeBSD system with soft updates enabled.

softdep is gone:

https://marc.info/?l=openbsd-cvs&m=168856997929968

Oh, that's interesting! Huh. I wouldn't have guessed that, although I haven't tracked OpenBSD development in ages, so maybe that was a big public debate for years for all I'd know.

This happened quite recently ( at the July 2023 hackathon), apparently to make it easier to update/fix other stuff as it was tied into a lot of kernel subsystems.

https://undeadly.org/cgi?action=article;sid=20230706044554

What happened to fsck_options in rc.conf?

It wouldn't solve an actually corrupted filesystem.

For network appliances, read-only root FS is probably the way to go anyway. (I'd say it's also worth doing it in general.)

(Disclaimer: avid fan of everything BSD, OpenBSD in particular.)

Ok say my root file system is read only, and say, /var/log is writable. The power goes out. Then what? Does /var/log just not mount until i type fsck? Aren’t i back to the same issue?

It's probably not a safe assumption to rely on for a device out in the field, but in my experience, OpenBSD's fsck typically works just fine unattended. I could pull the plug on my router right now and I would expect it to come back up on its own.

However, yes, sometimes a badly timed power loss will break the filesystem in a way that requires a manual fsck.

I’ve had 3 power outages this year since installing OpenBSD (which is a lot for my area, admittedly) and it has required manual intervention each time. My root FS is on an SSD, it that matters.

Reply on news.ycombinator.com