Stability in a Persistent Store Based on a Large Virtual Memory

Abstract

Persistent systems support mechanisms which allow programs to create and manipulate arbitrary data structures which outlive the execution of the program which created them. A persistent store supports mechanisms for the storage and retrieval of objects in a uniform manner regardless of their lifetime. Since all data of the system is in this repository it is important that it always be in a consistent state. This property is called integrity. The integrity of the persistent store depends in part on the store being resilient to failures. That is, when an error occurs the store can recover to a previously recorded consistent state. The mechanism for recording this state and performing recovery is called stability. This paper considers an implementation of a persistent store based on a large virtual memory and shows how stability is achieved.

The Napier88 Persistent Programming Language and Environment

“…The data is inherently valuable and requires protection from: system malfunction, such as hardware failure; misuse of common facilities, such as the operating system; and finally from users themselves [11]. Hardware malfunction has little to do with software protection and is best dealt with by techniques such as incremental dumping or stability strategies [79,80]. Here the focus is on software methods designed for the protection of persistent data.…”

Distributed persistent stores

“…When determining the correctness of such a disk block these time stamps are read, and if they are identical then the last write operation on the block completed correctly. By maintaining two such blocks, storing the roots for the last two checkpoint operations, in well known locations on disk, and by only overwriting the older or the incorrect block, it is possible to use these blocks to point to the last stable state of the store [39].…”

“…It should be noted that in normal operation only the most recent version of the mapping table actually exists because, as part of a successful checkpoint, the disk space allocated to the previous stable state is returned to the free disk space pool. To cater for pointers between volumes (which may be mounted on different nodes), a multi-volume stabilise mechanism is provided, implemented as a two phase commit [25,39]. This requires that a set of dependent volumes must be stabilised at one time.…”

Graph-based Optimistic Transaction Management.

“…The use of directed graphs as a data structure for control of transaction-based concurrency control in object stores was motivated by the authors' observation of the similarity between the objectives of stability [3,16,32] in persistent object stores [2,7,29,33] and of transaction management [6,14,15] in conventional database management systems. Previous work [16,19] describing the use of directed graphs to maintain information about the inter-entity dependencies created during program activity in an object store appeared to provide the basis for the satisfaction of a similar need for transaction-based systems.…”