Back & Forth

 | 

Low End Mac

BeOS and BFS, the BeOS Filing System

Jonathan Ploudre - 2001.04.20

I’m glad that my previous article has generated some interest and that David Puett took the time to clarify some points that I skimmed over in his BeOS or NeXT: Did Apple Make the Wrong Choice. I agree that I oversimplified some things in my article. Still, I think some of my ideas were generally correct, even if they were oversimplified.

Back and Forth

BeOS logoAs far as I know, no file system completely avoids fragmentation. The example in David Puett’s article points to exactly the kind of situation that can lead to fragmentation – a file that grows is more likely to get fragmented. But BFS (the BeOS Filing System) does several things to reduce the likelihood of fragmentation. It’s more fragmentation-resistant than fragmentation-proof.

When I use my PowerBook with the Mac OS, it will write a file in the available free space, but it seems to ignore whether there is contiguous free space. I’ve had a file written into 200 fragments even though there was a large enough single chunk of free disk space available. If that file is a QuickTime movie, the fragmentation will result in skips or dropped frames, since the hard drive can not keep up as it is searching for the next fragment.

BeOS does things a bit differently than the Mac OS or some other operating systems. When it writes a file, it tries to write it as a contiguous file. It does something called preallocation, where it gives files room to grow and still stay contiguous. It tries to write files in 64 KB segments, because you get better throughput rates as your block size gets bigger. For example, disk benchmarking will always show random reads as slower than 1 KB reads – and those are slower than 4 KB, and so on. Be chose 64 KB to provide a balance of size and performance. This may be the reason that the BFS can be considered high-performance. Its typical activity (reads and writes) is at a high percentage of the hardware’s theoretical speed. In contrast, the classic Mac OS works at a much lower percentage – Finder copies are much slower than my benchmark results on the same computer.

BFS also avoids the problem that HFS had of block sizes growing with the size of hard drives. On my hard drive, a 340 byte file takes up 21 KB of space. That’s more than 20 KB of wasted space. Apple fixed that problem with HFS+. Like HFS+, BFS can have a smaller block size – it’s 1 KB in BeOS. I don’t understand how BFS can have 64 KB preallocation and a minimum block size of 1 KB, but I’m not a programmer, so I’ll just assume it’s magic. The designer of BFS explains some of these issues in a presentation he made in 1998.

In my earlier article, I said that BeOS protects against corruption. David Puett responded that journaling will not prevent corruption. I suspect we are both overstating our points. The journaling provided in BeOS does not prevent all corruption in the BFS, but it does protect against some types of damage. When my Mac freezes while writing to the disk, it’s easy for the file system to get corrupted and cause me grief.

This is one reason why people started using a RAM Disk for their Netscape cache. By using a RAM Disk, it decreases the chance that a Netscape crash could result in file system corruption from a partially written file. Cache files are ephemeral and frequently changing; it was safer to put them on another partition or a RAM Disk to separate them from the rest of the hard drive – and RAM Disks provided a lot more zip.

BFS can still lose information when it hits a snag. If, for example, NetPositive has three cache files in memory waiting to write when the power goes out, those files would be gone. But by keeping a journal of intended reads and writes, BeOS would know if a file had not finished writing during the power outage. I still think this provides an extra level of safety or security.

As for David Puett’s points about BeOS not having any applications, that sounds like the opposite side of a common Window’s complaint about the Mac. PC users say that we have no applications when we have loads of programs that are real gems. No programs? Hah, I’ve got iCab, which doesn’t run on Windows. If you head over to BeBits, you’ll see that there are indeed many programs for BeOS.

But – and this is important – there are not many large commercial-grade applications. That’s a function of market size. The BeOS market isn’t big enough to warrant the investment. Of course, I’ve heard that same comment dozens of times from PC game companies when talking about the Mac. Doubtless, if Apple had bought Be, there would be many more programs than there are today, because the Mac market is much bigger.

I’m not against NeXT, as you’ll see in my future articles. NeXT had some great technologies long before any other OS. Still, it’s taken four years for Apple to bring its next generation OS to the market. [Mac OS X 10.0 was released in March 2001.] I suspect they could have brought BeOS to market much more quickly, since they had to port NeXT to the PowerPC before they even got started on Rhapsody.

We’ll never know what would have happened if Apple had bought Be instead. Based on the competing technologies and the intervening history, I still consider it a fair question: Did Apple make the wrong choice?

Further Reading

Keywords: #beos

Short link: http://goo.gl/0bIYZU

searchword: beosandbfs