Running OpenBSD on a Thinkpad: The Bad

Several months ago, I decided to have a little fun. I ordered a Thinkpad T420s for around $200 on Ebay, installed OpenBSD on it, and started carrying it around as my daily-driver. And, quite to my surprise, I am still carrying it. I haven’t opened up my other laptop (a System76 Lemur Pro running Arch Linux) since I pulled this Thinkpad out of the box. It has, of course, not been without its challenges, but on the whole I’m pretty satisfied with the experience. So I wanted to write a little bit about what it’s been like using a decade old computer with a fairly esoteric operating system.

The T420s I ended up with has fairly modest specifications, a 1600x900 display, a dual core i5 processor, hard disk, and 4GB of RAM. I have recently upgraded the drive to an SSD and the RAM to 16GB, but for most of the time that I’ve had the computer, it was configured as I purchased it.

As it turns out, I have a lot to write here, so I’m splitting this out into two posts. This post will cover specifically the bad experiences I’ve had, and a follow up post will go over my positive experiences. On the whole, bear in mind that I’m still using this system, so the good definitely outweighs the bad for me.

Limitations of the T420s

In comparison to my more modern laptop, there are immediately two major disadvantages to the T420s that I noticed during daily use,

1. It is a lot heavier. This is more of an issue than I had expected–I do a lot of walking over the course of the day, and I definitely feel the weight difference. It has gotten better as I’ve grown used to the extra weight, however.

2. The battery life is much shorter. With a new (aftermarket) battery, I could barely get 2 hours of life out of the laptop while just running a text editor for taking notes.

The battery situation is the worse of the two. Only having two hours of battery life made things a little tight. I could get through a class with it, but there wasn’t much wiggle room, and I’d need to remember to always charge it fully in between classes. Thankfully, the T420s has support for ultrabay battery expansion. Adding one of these gets me closer to three and a half hours of life, which is more than adequate to have a comfortable buffer.

To be fair to the battery, OpenBSD is not known for having best-in-class power management (that is to say–it seems to be widely regarded as terrible). I’m sure that battery life would be better in Linux, though I’ve not tested it as of yet. Even with this in mind, though, the battery situation is very annoying. One would think that, ten years later, battery technology advances would have made it possible to make far better batteries in the same form factor. But I suppose there isn’t enough of a market for old Thinkpad batteries to invest more resources than are necessary to make aftermarket batteries that are categorically worse than the decade-old OEM design.

As a distant third, the display is also poor. The resolution is actually fine, I don’t find myself pining for something with more pixels (the 1366x768 displays, on the other hand, are way too cramped for my liking). But the panel itself has poor colors and worse viewing angles. It isn’t something that I notice directly when I’m using it. But I’ll often be struck by how much prettier and more vibrant the syntax highlighting of my code looks on my desktop monitors, after I’ve been using the laptop for a while.

OpenBSD Filesystem Woes

Hardware concerns aside, OpenBSD itself does have a few issues that crop up in desktop use. First, and foremost… the filesystem. Oh the filesystem…

OpenBSD uses the FFS2 filesystem, which is an enhanced version of FFS (also called UFS, not the Amiga FFS). Be warned, this section is about to get a little technical, but it’s hard to talk about filesystems without getting a little into the weeds. Feel free to skip ahead if this isn’t your cup of tea.

A filesystem needs to keep track of files (go figure) on disk. They represent files, and information about them, in a variety of different forms, which are collectively referred to as metadata. This information is what associates data on disk to particular files, for example.

One single “logical” operation, such as deleting a file, creating a new file, pressing “save” in your word processor, etc., may well be associated with several metadata operations. To give an example, in some hypothetical filesystem, saving some data to a new file (i.e., “save-as”) could require creating a new file, associating data with that file, and associating that file with its parent directory. These three operations are distinct, but all three must happen for the new file to have been created.

One can imagine the problems that would ensue should the system crash part way through this series of operations. You might have a directory containing a file that doesn’t exist, or a file that isn’t in a directory, or a file without any data associated with it, etc., depending upon the order in which the different metadata updates were completed.

Some of these situations may be “valid”, in the sense that a filesystem could conceivably be in that state (whether or not the user intended it to be in that state is another matter). If the state of the filesystem is correct, in that general sense, it is said to be consistent. In the above example, it could easily be that the case that the system crashes before the data is associated with the file. In this situation, the filesystem is in a consistent state: the file exists and is in a directory, but is empty. It’s important to emphasize that this state is not the “correct” state based on what the user wanted to happen, but it is “correct” insofar as the metadata represents a state that the filesystem could legally be in. That is what is meant by consistency.

On the other hand, some of these situations could put the filesystem into an inconsistent state: a state which the filesystem could not normally be in. For example, deleting a file in our hypothetical filesystem could involve removing the file object, and marking the data regions it occupied as free. If the file is removed, but the system crashes before the data is freed, then we have orphaned data (which is a storage leak–this space will be forever lost to us, as the filesystem won’t know to reuse it).

Filesystems, then, must take pains to protect against partial metadata updates throwing them into inconsistent states. One technique that is commonly used by modern filesystems such as ext4 or ntfs is called journalling. In journalling, when an operation begins that consists of multiple metadata updates, the system logs what these updates are before it actually does them. That way, if the system is interrupted partway through, it can easily recover by replaying the operations stored in the log.

OpenBSD’s FFS2 takes a different approach. Rather than using a log, it arranges the metadata updates so that they occur in an order that ensures that the filesystem state remains consistent at all points in time, aside from storage leaks, which won’t damage data and can be easily fixed later using the fsck(8) utility.

In principle, this should mean that the chances of metadata corruption are minimal in both systems. And generally I think that bears out to be true. However, FFS2 pays a much larger cost for this safety.

The strict ordering approach requires a very specific, synchronous ordering of IO operations, which slows things down a lot. As a result, FFS2 supports a second approach, called soft-updates. In principle, this is similar, but it allows the operations to be cached in memory, temporarily rolled back, etc., so that IO operations can be performed in any order, but the metadata updates remain, at least in appearance, in the same synchronous order. This is not the default, but most sources will recommend that you use it.

I couldn’t tell you precisely why, as most sources indicate that soft-updates are equivalent to journaling, but I have personally experienced a lot more metadata corruption issues requiring manual intervention with soft-updates on OpenBSD (4 in 3 months) than I have with journaled filesystems on Linux (0 times in 10 years). I’ve also lost data more often, even in situations not requiring manual intervention. It actually caught me off guard the first time it happened–I’d never needed to manually run fsck and parse through Lost+Found before.

My suspicion is that this happens because the two approaches are actually providing slightly different guarantees. Filesystem journalling ensures atomicity of logical operations. No matter how many metadata updates a given filesystem operation entails, either all of them will happen, or none of them will happen. This ensures consistency as a side effect. The OpenBSD approach doesn’t take the logical operations into account at all, but attempts to directly ensure consistency. A given logical operation may be fully completed, or only partially completed, so long as the resulting system is consistent. This seems to me like a weaker condition than the one that journalling guarantees, which may account for the differences in experience I noted above. It could also be that I’ve just been very unlucky these past few months.

Hard Crashes

The above filesystem troubles are revealed only when the system crashes, of course. Unfortunately, I’ve had a few crashes (resulting in the corruption issues referred to above) in the time I’ve been using OpenBSD. Not very many, in the grand scheme of things, but a lot more than I experienced when using Linux. And, unlike Linux, I had a metadata issue almost every time.

For the most part, the crashes take the form of the entire system freezing up. I think that it was related to memory usage, as it usually happened during periods of high memory usage, and it hasn’t happened since I upgraded my RAM to 16GB. It also completely froze once when I plugged in the power adaptor. In all cases, it required a hard reset.

I have also experienced kernel panics, while running fairly simple programs I was working on for a class, which was surprising. And they wiped out my most recent modifications to the code. Fun fact: you can manually force your data to go to disk using sync(8) before doing something you’re concerned might cause a crash.

Finally (and this is not OpenBSD’s fault, but the laptop’s), my T420s has a nasty habit of rebooting if I set it down too aggressively. It doesn’t happen consistently, though. I thought it was maybe a battery connection or seating issue, but it has happened even when running off of the ultrabay battery, so that seems to rule that issue out.

Web Browsers

For the most part, I had surprisingly little in the way of userspace problems with both the migration to OpenBSD and the low spec, old computer. The closest thing to an annoyance has been that neovim can sometimes get a little bogged down, but I attribute that to my LSP setup and other plugins. I’m sure I could get it working better by spending a little time creating a more streamline configuration.

There has been one major black mark on the whole process, though… Web browsers. Web browsers are awful, horrible, terrible pieces of software.

My primary web browser is qutebrowser these days. I quite enjoy its configurability and keyboard driven interface, and the fact that QtWebEngine works better for me than most of the slew of WebKit-based browsers in terms of rendering. However, it is written in Python… This works fine on higher end machines, and it is still usable on this laptop too, but it definitely chugs.

The rendering engine itself works okay, but the interface is sluggish and unresponsive. The most annoying thing, though, is the launch time. It takes a full 10 seconds to cold launch. And, funnily enough, that launch time hasn’t changed since I switched from spinning rust to an SSD. I don’t think it’s load-from-disk time, I think it’s Python time. Though Firefox sees a similarly slow cold launch time of about 7 seconds.

Lighter-weight browsers don’t have that issue. For example, Netsurf launches in under a second and doesn’t lag at all. But, Netsurf is almost useless in practice due to its poor support for Javascript and modern web standards. The major websites I need to interact with are Github, Canvas, and Penn State’s various portals, so a web browser that actually works with these sites is a must.

The unfortunately truth seems to be that using the “modern web” requires a monster of a web browser, which is almost always going to perform poorly on old hardware.

I’ve worked around the issue for the most part by replacing my browser with more specialized programs. For example, I now use a combination of ytfzf, newsboat, and mpv to watch videos from YouTube, lbry, etc. and Zeal to read offline documentation for things that don’t have man pages (sidenote: I wish C++ had man-pages in the way that C does. Yes, you can get cppreference in man format, but it’s not very good).

Conclusion

And that’s about it. I was honestly surprised that I had so few issues, especially after my last attempt to set up a BSD-based desktop system using FreeBSD. OpenBSD seems a lot more straightforward to get set up and working–at least if you ensure that you get compatible hardware.

A number of things notable for their absence in the above would include suspend, hibernate, and audio, which all worked perfectly out of the box. I didn’t even have any issues with finding the software that I use. Miraculously, the only thing that I needed that wasn’t available in the repositories was davmail, which provides a generic version that works out of the box on OpenBSD (yay Java! I guess…), it just needs to be downloaded from their site. I haven’t gotten Rust working yet, but I only need that for one or two minor things that I can live without (the LSP plugin for assembly language, mostly).

In any case, I’ll publish another post shortly going over all of, or some of, my positive experiences as well, so keep an eye out for that!