Electrical computers and digital processing systems: virtual mac – Virtual machine task or process management
Reexamination Certificate
2000-02-04
2004-09-21
Follansbee, John (Department: 2154)
Electrical computers and digital processing systems: virtual mac
Virtual machine task or process management
C718S100000
Reexamination Certificate
active
06795966
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This application relates to an arrangement of a computer system, in particular, to a system and a method for acquiring, storing and using data concerning the state of hardware and software components within the computer system.
2. Description of the Related Art
Modern computers “crash” with irritating frequency, with much work lost or recovered only with time-consuming effort. Sometimes, crashes or other errors are expected, for example, when designing new software or debugging an existing program. In such cases, and even when first turning the computer on, time is also lost waiting for computers to “boot” or “reboot.” At other times, when problems occur for an ordinary user of a commercial application, even more time is often lost when the frustrated user must try to explain orally what has happened to a technician located far away in a customer service department. These are just a few of many possible examples of situations when information about the state of the computer system is either desirable, for example, when debugging a new program, or necessary, for example, when the computer is to reboot and automatically load previously running applications along with the data they were processing when exited.
One known attempt to ensure the ability to analyze and reconstruct the state of a physical memory, disk or data base is based on the concept of a “transaction,” which involves on-going tracking of updates to at least one region of storage. In this context, a transaction is a collection of updates that are bundled together so that they are atomic that is, either all of the updates occur, or none of them occur. The idea of transactions is typically applied to databases, where a series of updates to different tables need to occur simultaneously.
A transaction proceeds as follows: A begin command from the operating system or an application marks the beginning of the series of updates that make up the transaction. After the updates complete, a commit command marks the end of the transaction and the updates become permanent. If an error occurs during one of the updates that are part of the transaction, a rollback command is used to undo any updates in the transaction that may have completed.
Transactional Disks
In the prior art, this use of the concept of transactions is commonly implemented in database systems. Recently, transactions have been extended to apply to logical disks (also referred to as virtual disks), which are a software construct that emulate physical disks. One example of this solution, in the context of a parallel or distributed processing arrangement, is described in U.S. Pat. No. 5,634,096 (Baylor, et al., May 27, 1997, “Using virtual disks for disk system checkpointing”), which discloses a scheme for storing data on disks in such a way that a “checkpoint” is taken across several disks connected to different processors. This checkpoint is then used to restore the entire disk system to a known state after one or more of the disks or processors fails.
Yet another solution involving virtual disks is described in “The Logical Disk: A New Approach to Improving File Systems,” by de Jonge, Kaashoek, and Hsieh, in Proceedings of the 141h ACM Symposium on Operating System Principles, pp. 15-28, December 1993. In this paper, the term “Atomic Recovery Unit” is used to describe transactions to the logical disk.
The implementation of a logical disk requires the interception of requests to the physical disk, and transforming them into operations on a logical disk. Once this has been accomplished, it is possible to keep a log of all of the updates to the logical disk and defer the update so that the original data is not overwritten. When the updates are kept in a log in this fashion, then a rollback can be accomplished by discarding the updates in the log for a particular transaction. A commit can be accomplished by retaining these updates in the log, and eventually applying them to the logical disk.
A similar concept has been proposed in “Petal: Distributed Virtual Disks,” by Lee and Thekkath, in
Proc
. 1
“Intl. Conf. On Architectural Support for Programming Languages and Operating Systems
,” pp. 84-92, October 1996. The Petal virtual disk supports the ability to take snapshots of the virtual disk, using techniques known as “copy-on-write.” Copy-on-write is a common technique that allows copies to be created quickly, using a table of pointers to the actual data, and only copying the data when it is modified by a user program.
In Petal, the virtual disk itself is implemented as a table of pointers, and the snapshot (equivalent to a “checkpoint”) is implemented by including an identifier (called an epoch number) in this table. When a snapshot is taken, the current epoch number is assigned to the snapshot. The epoch number is then incremented, and all subsequent updates to the virtual disk belong to this new epoch number. When a block of the disk is next updated, there will be no copy at the current epoch number, so a copy of the block will be created. In short, as the term “copy-on-write” implies, a copy is made only when a disk block is written to. The original data is still available, under the epoch number of the snapshot.
Both the logging technique and the snapshot technique allow the implementation of transactions on a logical disk. In both cases, there are two copies of the modified disk block: the original version and the updated version. By restoring the state of the logical disk to point to the original version of all the disk blocks that were modified during the transaction, the transaction can be rolled back, that is, the state of the disk at the beginning of the transaction can be restored.
The concepts of transactions on virtual disks and snapshots of virtual disks have a number of limitations. The first is that they are useful only in the context of restoring the state of the disk: These systems provide no way to recover from, for example, failures caused by errors in a peripheral device.
Another limitation is that, during the operation of a typical computer system, the state of the disk is not complete: Modern operating systems employ disk caches that contain copies of data from the disk, as well as data that needs to be written to the disk. Applications also buffer data, so that even the operating system itself lacks a complete view of all the data entered by a user of the computer system. Snapshots of the disk state taken at an arbitrary point are only as consistent as the disk would be if the computer system were to crash at that point. On the other hand, any data that is present in the cache or in application memory, but that is not yet written to disk, is lost.
If snapshots of the disk state are taken only at points when the operating system is shut down, then the disk is in a consistent state, and no data is lost. However, this represents a significant limitation on the concept of transactions: Before a transaction can begin or end, all applications must be closed and the operating system must be shut down. This makes the snapshot technique inadequate to restore the full state of the disk when the system or an application “crashes,” that is, when an application terminates other than as a result of a prescribed shut-down routine and whose execution cannot proceed. Alternatively, the application or operating system must explicitly issue commands that cause the buffered or cached data to be written back to the disk. In short, the reality of modern systems does not always conform to the “clean” assumptions of the snapshot model, or they require the explicit coordination of application or operating system software.
The technique of taking snapshots (also known as “checkpointing”) has also been used not only for virtual disks, but also for other subsystems such as file systems. Moreover, checkpointing has also been proposed for applications, and, in certain very restricted senses and cases, for systems as a whole. Examples of each will now be given.
File System Checkpointing
One example of checkpointing o
Bugnion Edouard
Devine Scott W.
Lim Beng-Hong
Follansbee John
Patel Ashok
Pearce Jeffrey
VMWare, Inc.
LandOfFree
Mechanism for restoring, porting, replicating and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Mechanism for restoring, porting, replicating and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Mechanism for restoring, porting, replicating and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3196897