Persistent Storage Management

Data objects are loosely divided into two categories: those which are described in a Process or Task environment, and those which are described in the System environment. Objects which are part of a Task or Process environment will be automatically destroyed when an application terminates. In contrast, objects described in the System environment will not be deallocated, and may remain defined indefinitely.

It is intended that the MagicEight system access long-term storage in several different manners:

• The system environment, and process environments are built and stored on long-term (non-volatile) storage, and loaded into memory as needed. Only a minimal system environment need be provided locally in long-term storage on a processor node, as system resources and all application resources may be fetched from other processors in the system.
• Data objects placed in the system environment for sharing by different processes may migrate onto long-term storage if unused and memory is needed.
• Deliberate disk I/O may be performed by specifying a system/file_in or system/file_out tasks as the source or destination (respectively) of a stream. These tasks take a name, which may be either a object name in the system name space or a filename in a (distributed or locally) attached filesystem, and promptly fetch or store data as needed for the stream.

Deallocation of persistent objects is problematic. Unlike the temporary data objects defined local to a process, it is difficult to determine when a persistent object is no longer needed. In a manner similar to existing disk filesystems, it is anticipated that occasional manual intervention will be necessary to remove unneeded data (e.g. something as simple as deleting all persistent data objects unused for more than several hours.)

The manner described above for deliberate file I/O will also be used for other physical device I/O. The ``device drivers'' will consist of publicly executable tasks located in the system environment for driving displays, peripherals, and audio outputs, as well as inputting video, audio, and sensor or other data.. It is expected that these drivers will be relatively generic, and that a list of common ones will become part of this document.