BFS: How Haiku's File System Doubles as a Database
BFS treats extended attributes as first-class, indexable data — turning ordinary file queries into something closer to a database lookup, decades before this became a mainstream idea.
Most file systems store exactly two things about a file: its data, and a small, fixed set of metadata (name, size, timestamps, permissions). BFS — the Be File System, inherited by Haiku directly from BeOS — was built around a different idea: let any file carry an arbitrary number of typed, named attributes, index those attributes, and let applications query the file system by attribute value the same way they’d query a database.
What an attribute actually is
A BFS attribute is a typed name/value pair attached to a file, entirely separate from the file’s actual data content — an MP3 file might carry Audio:Artist, Audio:Album, and Audio:Title attributes, populated by a media application, without any of that metadata being encoded inside the audio data itself:
myfile.mp3
├── (file data: the actual audio stream)
└── attributes:
Audio:Artist = "Miles Davis"
Audio:Album = "Kind of Blue"
Audio:Title = "So What"Any application can read, write, or query these attributes through the same file system interface used for ordinary file I/O — there’s no separate metadata database to keep in sync, because the file system itself is that database.
Indexing: what makes queries fast
Storing attributes alone would just be unstructured metadata; what makes BFS meaningfully database-like is that specific attributes can be indexed — the file system maintains a B+tree index for each indexed attribute name, letting a query like “find every file where Audio:Artist equals ‘Miles Davis’” run as an efficient index lookup rather than a slow, brute-force scan of every file on the volume.
Who built it, and when
BFS was designed and implemented by Dominic Giampaolo and Cyril Meurillon, developed over roughly ten months starting in September 1996. Giampaolo later documented the design in detail in his book Practical File System Design with the Be File System — still a commonly cited reference for how BFS’s on-disk structures, indexing, and query mechanism actually work underneath the API.
Why this mattered specifically for multimedia
BFS’s attribute-and-query model was designed with exactly the kind of data Be Inc. cared about most: multimedia files with rich, structured metadata that a traditional hierarchical file system had no good place to put. Rather than requiring a separate media-cataloging application to maintain its own database (which can drift out of sync with the actual files on disk if a file is moved, renamed, or deleted outside that application), BFS made the metadata travel with the file itself, queryable by any application through the same standard interface.
Where this leads: live queries
Indexed attributes are also what makes live queries possible — a query whose result set updates automatically as matching files are created, modified, or deleted, functioning less like a one-time search and more like a saved, continuously-updating view. That capability doesn’t require any additional file-system machinery beyond what’s already described here; it’s a direct consequence of attributes being indexed and the file system already tracking changes to indexed values as part of ordinary write operations.
Why this was unusual for its time
Treating structured, queryable metadata as a core file system feature — rather than something layered on top by a separate application or database — was a distinctly uncommon design choice in the 1990s, and remains uncommon today outside of a handful of specialized systems. Haiku inheriting BFS wholesale rather than building a new file system from scratch preserved this specific, still-unusual capability, giving the modern OS a query-and-attribute model considerably more sophisticated than what most contemporary mainstream file systems offer even now.