Slashdot Mirror
Practical File System Design with the Be File System
Table of Contents
- Chapter 1 Introduction to the BeOS and BFS
- Chapter 2 What Is a File System?
- Chapter 3 Other File Systems
- Chapter 4 The Data Structures of BFS
- Chapter 5 Attributes, Indexing, and Queries
- Chapter 6 Allocation Policies
- Chapter 7 Journaling
- Chapter 8 The Disk Block Cache
- Chapter 9 File System Performance
- Chapter 10 The Vnode Layer
- Chapter 11 User-Level API
- Chapter 12 Testing
- Appendix A File System Construction Kit
First thing to note is that Giampaolo is not a great writer, nor is he a bad one. He does not have the gift that some tech writers have of making both an interesting technical document and a fun read. His style is very straightforward - introduce idea, explicate idea, summarize idea. On the other hand, he knows his topic inside and out, and has an obvious enthusiasm for the material, and a real talent for saying things simply without dumbing it down, and his occasional dry wit makes the book a surprisingly easy read.
Giampaolo is doing two things - discussing designing filesystems in general and documenting the Be filesystem. He does both well. BeFS has some advanced features - arbitrary metadata, attribute queries, and indexing. The desire to support these features influences the overall design of the system, but Giampaolo shows how changes to that design change implementation details. The result is a good overview of how a file system works, the trade-offs in optimizing for a particular usage pattern, and how to design one yourself.
The book can be roughly divided into three sections: the first is an overview of how filesystems work and some of the concepts that you encounter - extents, inodes, B-trees, superblocks, and the other standard pieces of a filesystem. Included in this early section is a good high-level overview of the design of five other file systems: BSD FFS, Linux's ext2, Macintosh HFS, Irix XFS, and Windows NT's NTFS. The coverage here strikes a proper balance between too much and too little information. Giampaolo prefers to show rather than to tell, and these filesystem overviews make the connection between design, performance, and features perfectly clear, and provide a solid background to talk about a specific implementation in detail - namely BeFS.
The second section is the bulk of the book - how to implement a filesystem from the ground up, leaning heavily on the BeFS implementation for examples. This is the most straightforward part of the book. Giampaolo covers a single issue in design and implementation in a "Here's the problem, here's and overview of possible solutions and their drawbacks, here's how I did it, now lets summarize" manner. Again, Giampaolo's style makes this an easy if somewhat dry read. As a filesystem and kernel ignoramus, I would have appreciated a slightly more detailed coverage of how all of the various data structures get to disk - how are they serialized, whether endianess is an issue, etc. The BeOS was pretty portable, running at one time or another on the AT&T Hobbit processor, PowerPC, and x86 - I would have liked to have seen portability issues discussed, however, BeFS wasn't written until after the move from the Hobbit to PowerPC, and the book was written prior to the move to x86, so the lack of coverage is reasonable.
Even considering the plain Jane style of this middle section, there are a few gems. The coverage of journaling is excellent, and while I've long understood journaling from a 10,000 foot perspective, this really made me understand the underlying concepts, combined with simple code snippets that helped understand implementation. The Allocation Policies chapter showed in clear terms that disk access is a major bottleneck, and filesystems have become very sophisticated in their optimizations.
The third section of the book deals with some of the more indirect concerns in implementing a file system; specifically, interacting with the kernel, designing a user level API and the major role of testing in filesystem development. This is the one place Giampaolo's writing shines. He really is a good teacher, and this section affords him the chance to talk about the broader perspective of OS design, and even recount a few war stories. For example, in terms of parentage, the BeOS has BSD and classic MacOS as its father and mother. In a few places, such as the Storage Kit API covered in chapter 11, this heritage shows some signs of less-than-seamless integration, and this offers Giampalo a chance to wax philosophical on the nature of OS design, company politics, and the pressure of shipping dates.
In short, the book lives up to it's title. The author is a pragmatist, and offers a clear roadmap for those who have a need to work with low level filesystem implementation. His emphasis on testing, careful optimization, and data structure protection not only helps to show the pitfalls of filesystem work, but also offers a Swiss army knife of techniques to dodge them. The book concludes with a short appendix which covers a file system construction kit, allowing a would-be implementor to begin work on his own filesystem safely without worrying about killing his hard disk. All in all, a solid read.
Here's a link to Practical File System Design with the Be File System as a PDF; you can also look for a used copy at Barnes & Noble. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
It is now official - Netcraft has confirmed: BeOS is
dying
Yet another crippling bombshell hit the
beleaguered BeOS community when recently IDC confirmed that BeOS
accounts for less than a fraction of 1 percent of all servers. Coming
on the heels of the latest Netcraft survey which plainly states
that BeOS has lost more market share, this news serves to
reinforce what we've known all along. BeOS is collapsing in complete
disarray, as fittingly exemplified by failing dead last in the
recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict BeOS's future. The hand
writing is on the wall: BeOS faces a bleak future. In fact there won't
be any future at all for BeOS because BeOS is dying. Things are
looking very bad for BeOS. As many of us are already aware, BeOS
continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its
core developers.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBeOS.
How many users of NetBeOS are there? Let's see. The number of OpenBeOS
versus NetBeOS posts on Usenet is roughly in ratio of 5 to 1. Therefore
there are about 7000/5 = 1400 NetBeOS users. BeOS/OS posts on Usenet are
about half of the volume of NetBeOS posts. Therefore there are about
700 users of BeOS/OS. A recent article put FreeBeOS at about 80 percent
of the BeOS market. Therefore there are (7000+1400+700)*4 = 36400
FreeBeOS users. This is consistent with the number of FreeBeOS Usenet
posts.
Due to the troubles of Walnut Creek, abysmal sales and so
on, FreeBeOS went out of business and was taken over by BeOSI who
sell another troubled OS. Now BeOSI is also dead, its corpse
turned over to yet another charnel house.
All major surveys show that BeOS has steadily declined in market
share. BeOS is very sick and its long term survival prospects are very
dim. If BeOS is to survive at all it will be among OS hobbyist
dabblers. BeOS continues to decay. Nothing short of a miracle could
save it at this point in time. For all practical purposes, BeOS is
dead.
Fact: BeOS is dead
Space eating troll
When an OS is compared to AmigaOS as a good thing, you know it's really time to throw in the towel.
Sm17h only serve
Ergo, it was not relational.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
> RDBs don't have tables
/. I have to say that you are either on such a higher level than me that I come off as a high school science teacher, or (the more likely) you have no idea what you are talking about. At the very least you should learn a little more about the evolution of the BeFS before spouting off about it:
WTF?
Reading your posts, at first I just dismissed you as uninformed and/or opinionated, but this just doesn't make sense.
The whole point of the table in a Relational Database is to store the RELATIONS between items. To say that relational databases don't have tables is like saying automobiles don't have engines. Sure, some don't, but then they won't go anywhere.
As much as I hate adding to the negative noise on
Be started with a relational database as a file system.
Be decided this was too complicated/cludgy/unneccessary, so the compromised with the BeFS attributes.
Giampaolo wrote a book about it.
All of this was in the '90s, long before the current (MS) trend of DB Filesystem.