next up previous
Next: The persistent heap Up: Virtual Memory for Previous: Segment fault handler

Backing store organisation

Passive data resident on disk needs to be appropriately organised. It has to provide both an area of disk to store persistent data when swapped out, and some form of transactional security. One has to ensure that a consistent image can be read off disk even if an earlier program had crashed whilst running. In a system that swaps data between memories, there is always the chance that a crash may leave the version in non-volatile memory half completed, with some blocks updated and some in an earlier state.

In DPOS this transactionally secure disk store is provided cheaply and simply using the filing system. There is a reserved directory SEGS used to store persistent data. The currently versions of segments are stored in files with the suffix .SEG and the previous version of a segment is stored in a file with suffix .BAK. Thus the most recent copy of segment 4001 would be in file SEGS32015.SEG and the backup copy, if any, in file SEGS32015.BAK.

In addition to the segments, the system stores housekeeping tables in the ROOTBLOK file, whose structure is shown in figure 3.15.

Figure 3.10: The type of the root block which provides housekeeping tables for the persistence manager.

It has 4 components:

This is the unique pointer from which all persistent data must eventually descend. The garbage collector uses it to determine which objects must persist. It will contain a pointer into a record in the persistent store.
This is a table containing flags used to describe the attributes of all of the selectors. These flags indicate if the selector's segment is reserved for the persistent store, if it is currently holding persistent data, and if the data it contains is executable instructions.
This is an array of heaps whose purpose will be described in more detail below.
This is an array, indexed by persistent segment numbers, of pointers to class descriptors. These too, are described below.

When the persistence system is initialised, the ROOTBLOK is read into RAM and the time at which the file was last-written noted in a variable timestamp. The sels array is inspected and the selectors currently used by DPOS are identified. The following algorithm is then executed: For each segment in use

If its .SEG file was last written since the timestamp Then
erase the .SEG file
rename the .BAK file as the .SEG file

At the end of this, any segments that had been flushed to disk since the last checkpoint operation will have been replaced by their previous versions.

When a segment is flushed to disk the following occurs:

If no .SEG file exists Then
create the file
write the segment to it

If the .SEG file is newer than the timestamp Then
overwrite the existing .SEG file

erase any .BAK file
rename the .SEG file as a .BAK file
create a new .SEG file
write the segment to it

This ensures that any .SEG file that predates the timestamp is preserved in the event of a subsequent crash.

When the checkpoint procedure is invoked, all segments in memory are flushed to disk followed by the ROOTBLOK file. This ensures that the timestamp on the ROOTBLOK will be later than those on all of the segments in the database.

next up previous
Next: The persistent heap Up: Virtual Memory for Previous: Segment fault handler

W Paul Cockshott
Fri Sep 6 10:29:18 BST 1996