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:

garbroot

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.

sels

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.

htb

This is an array of heaps whose purpose will be described in more detail below.

classes

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

When a segment is flushed to disk the following occurs:

If no .SEG file exists Then

create the file

write the segment to it

Otherwise

If the .SEG file is newer than the timestamp Then

overwrite the existing .SEG file

Otherwise

erase any .BAK file

rename the .SEG file as a .BAK file

create a new .SEG file

write the segment to it

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.