Looking at BFS Helps Explain Abiding Interest in BeOS

Andrew Hudson at Ars Technica has a well constructed retrospective on BFS the file system designed and implemented for BeOS before Be stopped being a going concern. Along the way he gives a primer on file systems so the uninitiated can follow along. What is most striking is how the high level design decisions that went into BFS foreshadowed features we pretty much take for granted in more recently built file systems.

As Hudson notes, BFS’s designers ignored the constraints of the common hardware of the day, designing for the future. This sort of go large or go home approach may explain why BeOS, now being developed as Haiku, has such a devoted following. I’ve never used BeOS, myself, but stories of its history and its re-birth as open source continue to fascinate me. BFS is a good example of why even the uninitiated are drawn to the OS.

This is a deep article, digging into the lower level details of the file system, if you are curious. Hudson makes some comparison to other file systems. It gets a bit more accessible when he discusses extended attributes. In particular, the comparison to databases seems apt as illustrated by Haiku’s MailKit. Rather than having an underlying binary file format or an actual database it uses BFS alone defining some fifteen attributes just for email handling. Eliminating the need for an extra layer between application and data storage makes sense and in this case takes advantage of the obscenely large files and disks BFS can handle.

Some of the warts of BFS are drawn out in the last section of Hudson’s article. Here he interviews one of the original developers of BFS and a current maintainer of the open source successor. Hudson mentions a book he drew on heavily to write this article which is by turns accessible and deeply geeky. I am guessing, based on his reference to it, that the book is also both highly readable and deeply crunchy. Sounds like my kind of read.