Apparently, Matt Dillion has decided to roll his own filesystem for DragonFly. "Here is my initial outline of the filesystem design. It is open for discussion. Please feel to ask questions for anything you do not understand. I do not intend to start coding anything for at least two weeks. There are currently two rough spots in the design. First, how to handle segment overflows in a multi-master environment. Such overflows can occur when the individual masters or slaves have different historical data retention policies. Second, where to store the regeneratable indexes."

Great question! The basic design philosophy of Plan9 is to extend the UNIX philosophy of "everything is a file" to its logical conclusion. This is a much more filesystem-oriented approach to clustering than is being attempted by DragonFly. While DF began by designing an MPI protocol for synchronizing the process and memory managers, Plan9 began with the design of the filesystem and took it from there.

The Plan9 filesystem is called 9P. It supports mapping any kind of resource--be it physical memory, files, I/O devices, or network-attached instances of all of these things--via a hierarchical namespace that may be unique for any process on the system. It also supports union directories, which is essentially a mount point that may refer to any number of mounted namespaces and resolves reference conflicts in a deterministic fashion.

To be brutally honest, Plan9's design is cleaner and more elegant than DragonFly's. Plan9 was destroyed by Lucent Technologies, and it doesn't have the basic ingredients to thrive as a community-based OSS project. DragonFly's BSD heritage has complicated their design, but it has helped them cultivate a development community.

1. Couldn't DF implement the Plan9 filesystem?
2. Couldn't DF evolve to a logical continuation of Plan9? 3. Is it possible without rewritting everything?
4. What are the candidate filesystems instead or writing another one?