particularly suitable for a distributed system connected over Ethernet, i.e., a distributed system with physically distinct partners.
8.2.5 Implementation Aspects
The main focus in research during the last centuries focused more on the theoretical
aspect of recovery point protocol than actual implementation. Especially in commercial systems, recovery points are rarely used and if at all mostly based on shared
library implementations.
Classic Unix-based system that is often used for the implementation of recovery
points uses different processor modes to protect the kernel with its kernel data
structures from the application. In case of an implementation on the application
level (shared library), a recovery point contains user mode data structures only.
If the recovery point mechanism is directly implemented on the kernel level, it is
possible to store kernel data structures together with the user mode data, which
helps in recovery significantly, as the kernel resources occupied by the application
can be restored as well. This is especially useful if the application is heavily I/O
based. An example of kernel-level implementation is [26] and for a user mode,
implementation is [50].
Another approach replicates relevant process kernel structures in the application
and stores them together with the application data in a recovery point. In case of
recovery, the recovery process restores the application kernel structures and uses
this information to continue processing.
An approach of creating recovery points is presented in [15, 18, 51–53]. This
approach heavily relies on the memory management unit of the processor. When a
recovery point of a process is created, the system write protects all memory pages of
the specific process and concurrently starts saving the memory pages and continues
processing.
In case of a memory written by the application, the memory protection violation
handler copies the affected memory page to a separate buffer and removes the write
protection from the accessed page. The content of the new buffer is then stored to
disk instead of the original page. Using the dirty bit of the memory protection unit
or software-based dirty bit, this approach can be adapted to use incremental recovery points.
Another approach simply compares the content of a recovery point with the
current memory content and stores only the difference. However, the significant
comparison overhead together with the storage access time can jeopardize the
advantages of this approach.
In a probabilistic approach, hashes are calculated for all memory pages and
stored together with the recovery point on stable storage. Recalculating the
checksums can identify changes to the pages. Further comparison of current and
stored ones can be useful as it was presented in [51–54]. This approach requires less
computation than comparing the contents of the recovery points directly.
8.2 Overview of Existing Backward Recovery Techniques
121
8.2.5 Implementation Aspects
The main focus in research during the last centuries focused more on the theoretical
aspect of recovery point protocol than actual implementation. Especially in commercial systems, recovery points are rarely used and if at all mostly based on shared
library implementations.
Classic Unix-based system that is often used for the implementation of recovery
points uses different processor modes to protect the kernel with its kernel data
structures from the application. In case of an implementation on the application
level (shared library), a recovery point contains user mode data structures only.
If the recovery point mechanism is directly implemented on the kernel level, it is
possible to store kernel data structures together with the user mode data, which
helps in recovery significantly, as the kernel resources occupied by the application
can be restored as well. This is especially useful if the application is heavily I/O
based. An example of kernel-level implementation is [26] and for a user mode,
implementation is [50].
Another approach replicates relevant process kernel structures in the application
and stores them together with the application data in a recovery point. In case of
recovery, the recovery process restores the application kernel structures and uses
this information to continue processing.
An approach of creating recovery points is presented in [15, 18, 51–53]. This
approach heavily relies on the memory management unit of the processor. When a
recovery point of a process is created, the system write protects all memory pages of
the specific process and concurrently starts saving the memory pages and continues
processing.
In case of a memory written by the application, the memory protection violation
handler copies the affected memory page to a separate buffer and removes the write
protection from the accessed page. The content of the new buffer is then stored to
disk instead of the original page. Using the dirty bit of the memory protection unit
or software-based dirty bit, this approach can be adapted to use incremental recovery points.
Another approach simply compares the content of a recovery point with the
current memory content and stores only the difference. However, the significant
comparison overhead together with the storage access time can jeopardize the
advantages of this approach.
In a probabilistic approach, hashes are calculated for all memory pages and
stored together with the recovery point on stable storage. Recalculating the
checksums can identify changes to the pages. Further comparison of current and
stored ones can be useful as it was presented in [51–54]. This approach requires less
computation than comparing the contents of the recovery points directly.
8.2 Overview of Existing Backward Recovery Techniques
121