Slashdot Mirror


Practical File System Design with the Be File System

erikharrison writes "Dominic Giampaolo's Practical File System Design with the Be Filesystem has been around since 1999 - not exactly a new book. The book has been out of print for a time now, however, so Dominic made the book available in PDF form on his website. With this public release of the book, and the BeOS rising to join the ranks of OSs that won't die (hi Amiga!) it makes sense to take a look at what the book has to offer us today." Read on for the rest of Harrison's review below to see just what that is -- it covers a surprisingly broad range. Practical File System Design with the Be File System author Dominic Giampaolo pages 227 pp publisher MORGAN KAUFMANN PUBLISHERS, INC. rating 8.5 of 10 reviewer erikharrison ISBN 1558604979 summary Discusses implemeting a file system, using the Be file system as example

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.

10 of 258 comments (clear)

  1. Crud more file Systems? by LoveTheIRS · · Score: 0, Flamebait

    Aren't there enough filesystems? All you need is one!

  2. Ill shout Troll... by Peden · · Score: -1, Flamebait

    ...to anyone proclaiming this to be old news!

  3. Sorry by Anonymous Coward · · Score: -1, Flamebait

    But ext3 is the perfect file system.

  4. Re:Need more than one filesystem by Anonymous Coward · · Score: -1, Flamebait

    Sounds like you must be a Linux-loving lus3r.

    HFS is the only filesystem worth using. Mac OS 9 for life! CLI's still suck!

  5. GAS FS by AnimeFreak · · Score: -1, Flamebait

    If the Germans wrote a journaled file system, it would be called "GAS FS," or "German Accounting System File System." I don't think it would go well with the Jewish population.

  6. Re:Silly submitter... by Anonymous Coward · · Score: -1, Flamebait



    It is official; Netcraft now confirms: BeOS is dying.

    One more crippling bombshell hit the already beleaguered BeOS community when Slashdot confirmed that BeOS market share has dropped yet again, now down to less than a fraction of 1 percent of its target market. Coming on the heels of a recent 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 recent tests.

    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. Their offices are dark, the tomb-like sepulchral atmosphere is all that remains. BeOS continues to lose market share. Red ink flows like a river of blood.

    The BeOS development team 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 dilettante dabblers and hangers-on. 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 dying

  7. Re:BeOS won't die? by Shut+the+fuck+up! · · Score: -1, Flamebait

    I can't say any more, but you can connect the dots if you think about it for a while.

    Connecting...dots....Got it! It's your new gay porn company! Do I win a copy of your first release, "Iron Faggots: Battle Fisting!"?

  8. EARTH TO SELF-IMPORTANT JACKASS: by Anonymous Coward · · Score: -1, Flamebait

    noone cares who says they're using beos but really arent.

    I wonder if the mods are fair enough to mod you offtopic, probably not.

  9. Re:Mirror with PDF by Anonymous Coward · · Score: -1, Flamebait

    What, no profanity? I'm very unimpressed! I was expecting:

    You fucking prick, the god damned motherfucking solution to this shit is to host your fucker of a site your bloody self on your own un-fucking-metered DSL line. It's slow as runny shit coming out your asshole in February, but if there's a big fucking demand for some shitty cock of a file, there's always some god damned cunt who will cache the fucker for you.

  10. Re:Like a warm hug. by Anonymous Coward · · Score: -1, Flamebait

    Except you're actually 50 and not five, plus your grandmother's dead and has been dug up and raped continuously by a series of strangers. BeOS is kind of the same, except your grandmother also raped you and it's some stupid toy company started by an Apple exec at mid-life crisis instead of your grandmother.