Browse Prior Art Database

Hardware Data Recovery at Task Level

IP.com Disclosure Number: IPCOM000102444D
Original Publication Date: 1990-Nov-01
Included in the Prior Art Database: 2005-Mar-17
Document File: 4 page(s) / 182K

Publishing Venue

IBM

Related People

Liu, L: AUTHOR

Abstract

Disclosed are techniques for using storage hardware to recover data from failed tasks. The basic idea is to enhance storage control with task information and hence allow it to undo data modifications of a task upon failure. The objective is to reduce the complexity of software recovery.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 33% of the total text.

Hardware Data Recovery at Task Level

       Disclosed are techniques for using storage hardware to
recover data from failed tasks.  The basic idea is to enhance storage
control with task information and hence allow it to undo data
modifications of a task upon failure. The objective is to reduce the
complexity of software recovery.

      In database systems a failed transaction may be recovered by
undoing its record changes based on log data. The goal is primarily
to maintain data access atomicity at transaction level.  Similar
recovery strategies have also been employed for many system tasks.
One weakness in such strategies is the complexity involved in
constant preparation for unexpected failures.  Such complexity
includes extra software pathlength and delays due to critical data
hardening in some systems.  Traditionally, recovery has also been one
of the major difficulties involved in system software design.

      One possibility in simplifying the management of software
recovery is to provide hardware support.  Ideally, such hardware
support can recover a failed task without any software intervention
by wiping out all side-effects of the execution.  Such side-effects
include storage updates and other types of communications with
external processes.  It is clearly difficult for hardware to solve
the problem for general tasks or transactions.  However, it is
possible to provide hardware recovery support for tasks in limited
fashion.

      An Exemplary Design We will illustrate the techniques of the
invention with an example of critical directory management.  Consider
a certain controller in which a number of processors are used to
serve a certain request.  There is a shared memory between the
processors, although each processor may have its own private memory
and/or operating system.  There is a directory D in the shared
memory.  The function of the controller is to examine D and provide
certain status for each external request with certain input
parameters (e.g., resource name, mode, etc.). During the service for
a request, the directory may be modified (e.g., to insert or delete
an entry, to change certain status tags, etc.). Examples of such a
controller are:  Storage Controller, Locking Engines, and other
Real-time Controllers.  One nature of such a controller is that, in
normal operations, each service task requires limited time to execute
and generates limited amount of storage accesses.  We also assume
that certain portions of the shared memory are regarded as CRITICAL
DATA AREA, and that storage hardware is capable of identifying
accesses to such area (e.g., via memory tags, page table flags,
etc.).  The directory D resides in the critical data area.  We assume
that different active tasks are guaranteed to access disjoint pieces
of critical data by software constructions and proper synchronization
mechanisms.  For instance, the directory D may be partitioned into
disjoint hash classes with a sem...