A walk through FreeBSD filesystem history in +5/-8 lines

A very interesting and history-filled commit just hit the FreeBSD repository:

https://freshbsd.org/freebsd/src/commit/9a2fac6ba65fbd14d37ccedbc2aec27a190128ea

It’s a 166-line commit message for a diff that is a net change of -3 lines and affects only 8 lines of existing code. The TL;DR is that there were some discrepancies between 4.4BSD-Lite and FreeBSD 1.x filesystems that led to some possible metadata differences surrounding the encoding of “embedded” symlinks [1]. Nearly thirty years later, this discrepancy was attributed to some unexpected kernel panics dealing with a corrupted filesystem, and is being cleared out. In the process, the hero of our story, David Greenman Lawrence, did a deep dive into the history of that code and turned an excellent patch by Chuck Silvers into an even more excellent (in this humble author’s opinion) piece of FreeBSD history.

Via this Mastodon post.

[1] A Unix symbolic link is a “pointer” from one place in the filesystem to another, by name. When they were first introduced, they were implemented as a file that contained a pathname as its contents, having a special type that indicated that it was in fact a symbolic link. Upon encountering a symbolic link, the kernel would load the file’s data block, read the path from it, and open the target file instead. At some point someone made the observation that most symlink pathnames were effectively only a few (dozen) bytes in length, and would fit in the part of the link’s inode that would normally point to the block containing the link data. Since this reduced disk accesses and reduced the amount of data that needed to be cached in the block cache, it was a large win, and embedded symlinks that did just that were born.

4 Likes