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:
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
When a segment is flushed to disk the following occurs:
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.