Patent number 8631066 is assigned to
The following quote was obtained by the news editors from the background information supplied by the inventors: "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.
"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.
"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.,
"Yet another solution involving virtual disks is described in 'The Logical Disk: A New Approach to Improving File Systems,' by
"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 '
"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 of file systems is disclosed in 'Deciding when to forget in the Elephant file system,'
"Other checkpointing techniques for file systems are described in 'File system design for a file server appliance,'
"Many different proposals have also been put forward for checkpointing systems in certain restricted situations. One such proposal for the system known as KeyKOS is described, for example, in 'The Checkpoint Mechanism in KeyKOS,'
"Still another known system-checkpointing technique is described in 'EROS: a fast capability system,'
"As its title implies, U.S. Pat. No. 5,715,464 (Crump, et al.,
"Yet another system with features similar to the suspend-to-disk features of a portable computer is disclosed in U.S. Pat. No. 5,758,174 (Crump, et al.,
"In both the Crump '464 and '174 systems, the operating system (OS) and application software must participate in the suspension and must go through a shutdown and a wake-up phase. In particular, these known systems require software executing within the operating system, such as an Advanced Power Management (APM) driver, and applications/subsystems to register with the APM driver. Furthermore, each suspended image must belong to a different OS, or instance of an OS, since the image does not include the state of the disk at the time the system was suspended. Resuming an OS will thus alter the contents of the disk associated with that OS at the next occurrence of a disk write, causing any suspended image associated with that OS to be inconsistent with the state of the disk. Another limitation is that neither system employs any form of copy-on-write techniques to reduce the amount of saved state.
"Still another system of this type is described in U.S. Pat. No. 5,386,552 (Garney, et al.,
"As in other suspend-and-resume systems, in the Garney system, the evolution of the computer system state is always moving forward in a linear trajectory. In other words, once the system is resumed, there is no way to go back to the previously suspended state. This is in part because the contents of the disk, which are not saved when the system enters the suspend state, may be freely modified after resuming--any post-resume modification prevents resuming again from the previously saved state. Thus, it is not possible to resume multiple times from a saved image. It is also not possible to save the state, continue execution, and then resume later from the saved state.
"The Garney system also illustrates another common disadvantage of existing arrangements that provide for saving at least some part of the system state: It requires that software within the system itself must participate in saving the system state. Thus, in order to save the partial state in the Garney system, the additional system software needs to cause the processor to go into a system management interrupt state so that it can access a system management memory area. The processor must also be in the system management interrupt state in order to ensure that a critical part of the save routine will not be interrupted by a hardware interrupt.
"One known system for checkpointing applications is the 'Condor' distributed processing system, which is described in 'Checkpoint and Migration of UNIX Processes in the Condor Distributed Processing System,'
"All of the known systems and methods mentioned above suffer from one or more of the following disadvantages:
"They save only part of the entire system state; as such, they cannot ensure complete restoration of the system state sufficient to guarantee that all applications will be able to continue exactly as they would have when the saved state is restored.
"They are not able to generate checkpoints and save the state of the system at arbitrary points, or at multiple points. The systems will therefore not correctly save the partial state except when processing is interrupted at specific points or under specific conditions. This implies, of course, that there will be circumstances when the state cannot be saved at all. This means, in turn that such systems cannot be used for such operations as full-state, step-by-step debugging of applications. In many cases, this limitation is caused by a need for synchronization of the partial state-saving procedure with applications, or a need to wait for some other internal process--such as a shut down of some sub-system--to be completed before saving the partial state.
"They require specialized system software such as special API's or operating systems. Alternatively, they assume and work only for particular operating systems and hardware architectures. They are therefore not beneficial to the most common users--those who need to run off-the-shelf applications using an off-the-shelf operating system. An additional consequence of this is that the checkpoints are not portable between different systems.
"They need to flush disk caches.
"What is needed is some way to overcome these disadvantages of the prior art, and in particular, to extract and restore the entire state of the computer system as a whole, not just of some portion of the memory. This then would enable complete restoration of the system to any point in its processing without requiring any application or operating system intervention, or any specialized or particular system software (such as API's and OS's) or hardware architecture. This invention provides a system and method that accomplishes this, and it does so in a way that makes possible even other unique features, such as the ability for one or even multiple users to run, evaluate, test, restart, and duplicate a processing stream not only from the same point, but also from different points. The invention accomplishes this, moreover, in a manner that allows checkpointing the entire state of the system in a way that allows state information to be portable between different hardware platforms and system software configurations."
In addition to the background information obtained for this patent, VerticalNews journalists also obtained the inventors' summary information for this patent: "Embodiments of the invention comprise methods, computer systems and computer program products.
"One embodiment is a method for allowing multiple users to share a common computer system image. The method comprises: generating a state vector representing the total machine state for a virtual machine configured with one or more commonly used applications; establishing the state vector for the virtual machine as a read-only common computer system image for use by multiple users; loading the state vector into a first virtual machine for use by a first user and into a second virtual machine for use by a second user; and allowing the first user to use the first virtual machine and allowing the second user to use the second virtual machine, and allowing the first and second users to enter different data in the first and second virtual machines, respectively, so that the processing paths of the first and second virtual machines diverge.
"In another embodiment, the common computer system image is stored on a server computer, the first user accesses the common computer system image on the server computer from a first client computer and the second user accesses the common computer system image on the server computer from a second client computer. In another embodiment, updates to the common computer system image are kept in local storage on the client computers. In another embodiment, the method further comprises, at a later time, loading the state vector into a third virtual machine for use by a third user, allowing the third user to use the third virtual machine, and allowing the third user to enter different data so that the processing path of the third virtual machine diverges from the processing paths of the first and second virtual machines. In another embodiment, the method further comprises, at a later time, loading the state vector into a third virtual machine for use by a third user, allowing the third user to use the third virtual machine, and allowing the third user to enter different data so that the processing path of the third virtual machine diverges from the processing paths of the first and second virtual machines, wherein the third user accesses the common computer system image on the server computer from a third client computer. In another embodiment, the method further comprises generating a checkpoint of the first virtual machine, transferring the checkpoint of the first virtual machine to a first client computer, restoring the checkpoint of the first virtual machine in a first remote virtual machine in the first client computer and allowing the first user to use the first remote virtual machine in the first client computer; and generating a checkpoint of the second virtual machine, transferring the checkpoint of the second virtual machine to a second client computer, restoring the checkpoint of the second virtual machine in a second remote virtual machine in the second client computer and allowing the second user to use the second remote virtual machine in the second client computer. In another embodiment, the checkpoint of the first virtual machine is transferred to the first client computer and the checkpoint of the second virtual machine is transferred to the second client computer using a network.
"Another embodiment is a method for providing a common virtual machine to each of multiple users. The method comprises: generating a state vector representing the total machine state for a source virtual machine running on a first computer; transferring the state vector to a second computer, restoring the state vector in a first remote virtual machine on the second computer and allowing a first user to use the first remote virtual machine on the second computer; and transferring the state vector to a third computer, restoring the state vector in a second remote virtual machine on the third computer and allowing a second user to use the second remote virtual machine on the third computer, wherein the first user and the second user enter different data so that the processing paths of the first remote virtual machine and the second remote virtual machine diverge.
"In another embodiment, the first user and the second user also change parameters differently between the first remote virtual machine and the second remote virtual machine. In another embodiment, the state vector is kept on the first computer in a read-only state. In another embodiment, the state vector is transferred to the second computer and to the third computer using a network. In another embodiment, the state vector is transferred to the second computer and to the third computer using a disk. In another embodiment, the first computer is a central server."
URL and more information on this patent, see: Lim, Beng-Hong; Bugnion, Edouard; Devine,
Keywords for this news article include: Software,
Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC
Most Popular Stories
- Chobani Counters Competition With Expanded Lineup
- Pope Francis, Huge Crowd Joyously Celebrate Easter
- Automakers Turn to China to Fuel Sales Growth
- GM Boosting China Production Capacity
- GOP Making Bold Play for Oregon Senate Seat
- Report: Iran VP Says Row Over Reactor Resolved
- Delay in Ferry Evacuation Puzzles Maritime Experts
- Confusion, Anger as Sunken Ferry's Relatives Wait
- NASA's Space Station Robonaut Finally Getting Legs
- Iran Denounces U.S. Ruling to Sell Property