next up previous contents
Next: 6.5 4.4 BSD's nullfs Up: 6. Related Work Previous: 6.3 Programmed Logic Corp.'s

6.4 Spring

Spring is an object oriented research operating system built by Sun Microsystems Laboratories [Mitchel94]. It was designed as a set of cooperating servers on top of a microkernel. Spring uses a modified Interface Definition Language (IDL) [Stone87,Warren87] as outlined in the CORBA specifications [CORBA91] to define the interfaces between the different servers.

Spring includes several generic modules that provide services that are useful for file systems:

Spring file systems inherits from many of the above modules. The naming module provides naming of otherwise anonymous file objects, giving them persistence. The I/O layer is used when the read or write system calls are invoked. The memory pager is used when a page needs to be shared or when system calls equivalent of mmap are invoked. The security layer ensures that only permitted users can access files locally or remotely, and so on.

Spring file servers can reside anywhere -- not just on the local machine or remotely, but also in kernel mode or in user-level. File servers can replace, overload, and augment operations they inherit from one or more file servers. This form of object oriented composition makes file systems simpler to write.

File system stacking is easy and flexible in Spring. The implementation of the new file system chooses which file system modules to inherit operations from, then changes only those that need modification. Since each file object is named, Spring stackable file systems can perform operations on a per-file basis; they can, for example, decide to alter the behavior of some files, while letting others pass through unchanged.

Spring is a research operating system used by Sun to develop new technology that could then be incorporated into its commercial operating system products. As such, performance is a major concern in Spring. Performance had always been a problem in microkernel architectures due to the numerous messages that must be sent between the many servers that could be distributed over distinct machines and even wide-area networks. Spring's main solution to this problem was the abundant use of caching. Everything that can be cached is cached: pages, names, data, attributes, credentials, etc. -- on both clients and servers.

Without caching, performance degradation for a single stack layer file system in Spring ranged from 23%-39%, and peaked at 69%-101% for a two-layer stack (for the fstat and open operations)! With caching it was barely noticeable. However, even with caching extensively employed, basic file system operations (without stacking) still took on average 2-7 times longer than the highly optimized SunOS 4.1.3 [Khalidi93]. So while it is clear that caching helped to alleviate some overheads, many more remain. Compare that to FiST's total overhead for a single stack layer of about 3-6% (Section sec-design-eval-performance) and you see that FiST is more capable of commercial grade performance.

To implement a new stackable file system in Spring, one has to write only those operations that need implemented. The rest get their implementation inherited from other file system modules. FiST also lets you implement only those file system operations that are needed. Every operation you do not explicitly modify or override defaults to that of Wrapfs (forward the vnode operation to the interposed file system).

The work done in the Spring project is clean and impressive. Spring, however, still uses a different file system interface and as a research operating system is not likely to become popular any time soon, if ever. There is still plenty of merit to using FiST to provide as many of the file system facilities that Spring provides, using a simple to define language and generating code for a more common interface.

next up previous contents
Next: 6.5 4.4 BSD's nullfs Up: 6. Related Work Previous: 6.3 Programmed Logic Corp.'s
Erez Zadok