Be File System Retrospective
The Be operating system file system, known simply as BFS, is the file system for the Haiku, BeOS, and SkyOS operating systems. When it was created in the late ’90s as part of the ill-fated BeOS project, BFS’s ahead-of-its-time feature set immediately struck the fancy OS geeks. That feature set includes:
- A 64-bit address space
- Use of journaling
- Highly multithreaded reading
- Support of database-like extended file attributes
- Optimization for streaming file access
A dozen years later, the legendary BFS still merits exploration—so we’re diving in today, starting with some filesystem basics and moving on to a discussion of the above features. We also chatted with two people intimately familiar with the OS: the person who developed BFS for Be and the developer behind the open-source version of BFS.
Beyond that BFS has lots of annoying problems, which are very understandable in the context of it being rushed into use over such a short period of time and with really only one key person doing much of the work, but they don’t vanish just because they have an excuse:
The metadata indices are clearly aimed at end user operations like “Where’s that file with the client’s name in it?” or “What songs do I have by Michael Jackson?” but they’re designed in a way that wastes a lot of space and yet also has poor performance for such queries - because they’re case sensitive for no good reason. They also incur a LOT of extra I/O so if you don’t need that feature you’d really want to switch it off, but you can only really do that at filesystem creation time.
Fragmentation is a really nasty problem. This is an extent-based filesystem, so that’s somewhat inevitable, but BeFS almost seems to go out of its way to make it worse, and provides no tools whatsoever to help you fix it. It’s actually possible to get a “disk full” type error when trying to append to a file which is badly fragmented, even though there is plenty of disk space.
Unix files often have an existence that transcends the mere name on the disk, but BeFS takes that a step further, allowing application software to identify a file without knowing its name at all. There are a few scenarios where this is quite clever, but if you ever want to retro-fit actual privilege separation to the OS (which has been a long term ambition for Haiku for more than a decade) this produces a Gordian knot - permissions are associated with names, but software can simply obtain (or guess!) the anonymous number for the file and sidestep such permissions altogether.
Previously: Practical File System Design.
2 Comments RSS · Twitter
> I don't get the issue with the access to the file by number and not by name
The way I read it, the problem is not that files have an ID (which is good), but that you can circumvent access restrictions if you access a file by its ID (which seems bad).
I don't get the issue with the access to the file by number and not by name. HFS has that from the start (FSRef are just a volume ID and file ID) and it didn't prevent Apple to add UNIX privilege support to HFS+.