This memo addresses the issue of how to implement phase zero of Yggdrasil. In this plan, we attempt to get a minimum function server usable at an early date. To a large extent, we use existing software to provide the bulk of the functionality.

In particular, we would use the UNIX file system to store the data. We defer many of the more interesting aspects of the system, and try to get early users. We provide a basic hypertext system with few of the frills. This system should be useful to NoteCards.

Alternatively, the use the UNIX file system can be viewed as scaffolding to build the higher layers of the system. This decouples the storage layer from the basic upper layers proposed here. We can proceed down both paths at the same time.

Below are the features of the system as taken from the overview memo. In strikeout are the features that are to be omitted in phase 0.

The goal of Phase 0 is to get up a running server with a restricted interface, modest performance, poor recovery time, modest availability, and poor fragmentation. Phase 0 of Yggdrasil will sacrifice many of the interesting systems features of the project. However, the server would support the basic hypertext, naming, and indexing that are the key features of the data model. When the server runs in this mode, then it is possible to put up a server for a few clients. By putting up a server early, we hope to be able to measure its use, obtain client feedback, and build a history of success in the project. In any case, this approach allows us to scaffold up the higher levels of the system on available pieces of software.

The essential idea is to get maximum leverage out of the UNIX file system. We would run under SUN OS and use the "Fast File System." Reserved files would be used for key system data.

The logging code of Yggdrasil would be the same. It would log to a UNIX file, using the fsync system call to force the log file.

The directory system of the UNIX file system is used extensively. A directory is a container. Sub-containers are directories in the container's directory. Specially named files in the directory have the contents ($contents), index ($index), links ($links), and properties ($properties) files. Objects directly contained in the container appear as file triplets: a unique name followed by one of three extensions. The extension contents contains the file's contents, the extension links contains the file's links, and extension properties contains the file's properties. Either or both of the links and properties files may be missing if they are empty.

Links are encoded using the file name of the "from" or "to" object. If the object moves, then all links to it must be updated.

It will not be possible to find out in which containers an object resides.

A typical object will take three (3) disk pages. If (when) this is a problem, we could merge the three files into one file for the simple cases (e. g., if each was < 1/3 the size of a file block, then use a fixed allocation scheme). Conversion to the general case would have to be automatic.

Large containers are a problem. The UNIX file system searchs a directory linearly, so finding a particular entry can take a long time.