J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under Unix. In Usenix Winter Technical Conference, pages 213223, January 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....of the object server, a local representative cannot be recovered, the server can trace the persistent data that belonged to this LR and remove it. Because we save only the in core parts of the local representative s state in a checkpoint, our approach is also known as user directed checkpointing [21] We decided to implement just periodic, user directed checkpointing for performance reasons. The alternative is to checkpoint the state at each update operation, but this was felt too expensive for a general solution as it requires a synchronous disk operation. Further research is needed to see ....

....a large number of clients simultaneously downloading a heterogeneous set of files. Both servers were loaded with the 50 most popular files on the SourceForge free software site in October 2001. In the GDN case, each file was placed in a separate storage object. The size of these files ranged from 21 KB to 15 MB (average 1.5 MB) At the client side 50 clients were started and each client continuously downloaded the same file from the server. After 30 minutes all clients were killed and the total number of successful downloads was counted. We used the following hardware and software. The ....

[Article contains additional citation context not shown here]

J. Plank, M. Beck, G. Kingsley, and K. Li. "Libckpt: Transparent Checkpointing under Unix." In Proc. USENIX Winter 1995.

....application [3, 4, 5] Although both approaches are complementary, there is no implementation that combines their advantages, since current operating system kernels do not provide suitable support for implementing checkpointing and rollback recovery at the application layer. As it is suggested in [6], incremental and concurrent checkpointing, which are effective methods of reducing the overhead of checkpointing, should be provided by the operating system kernel. In this scenario, our work has focused on the design of a reduced set of services that can be incorporated to operating system ....

....services. 5. Experimental Results The first experimental results obtained after implementing IMs show that Incremental Operations can be used in real applications. However, we do not claim to have a particularly efficient implementation of IMs. Previous published results from other researchers [1, 6] prove that incremental and copy on write techniques significantly improve performance, and the strength of IMs is to offer these kernel level techniques to application designers, which can use IMs to selectively create, update and recover critical data copies. Therefore, applications such as the ....

[Article contains additional citation context not shown here]

J. S. Plank, M. Beck, et al., "Libckpt: Transparent Checkpointing under Unix", USENIX Winter 1995.

....Schmidt[24] In that work, capsules were implemented in the Solaris operating system and only groups of Solaris processes could be migrated. Other work has looked at migration and checkpointing at process and object granularities. Systems working at process level include V[26] Condor[16] libckpt[21], and CoCheck[25] Object level systems include Legion[10] Emerald[14] and Rover[13] LBFS[19] provided inspiration for HCP and the hash cache. Whereas LBFS splits blocks based on a fingerprint function, HCP hashes page aligned pages to improve performance on memory and disk images. Manber s ....

J. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under Unix. In Proceedings of the USENIX Winter 1995.

....of increasingly common clusters of independent machines, each with its own operating sys tem. Several systems have been developed to support process migration at the user level and can be run on unmodified commercial operating systems. These systems include Condor [22] CoCheck [29] libckpt [28], and MPVM [10] These systems are primarily intended for executing long running applications on a cluster of machines. However, because there is no kernel support for process migration, these systems require processes to be well behaved in order to migrate, which means that such processes cannot ....

J. S. Plank, M. Beck, G. Kingsley, and K. Li, Libckpt: Transparent Checkpointing under Unix, Proceedings of Usenix Winter 1995.

....a consistent state from which the computation can continue. Such important observation indicates that semantic information regarding such data items is necessary to obtain a consistent checkpoint for the new object copy. Another approach consists in providing the user with libraries of functions [14] or classes [10, 11, 13] to deal with fault tolerance protocols and state information. In object oriented terms, the application classes must inherit from some base class in which the two methods SaveState and RestoreState are defined as virtual methods. This second approach is clearly not ....

J. S. Plank, M. Beck, G. Kingsley, and K. Li, "Libckpt: Transparent checkpointing under unix," presented at Usenix Winter 1995.

.... styles for implementing application transparent rollback recovery in messagepassing systems, namely coordinated checkpointing, message logging, and communicationinduced checkpointing (CIC) 5] Both coordinated checkpointing and message logging have received considerable analysis in the literature [4,6,11,14,17,18,20,21,24,28], but little is known about the behavior of CIC protocols. This paper presents an experimental analysis of these protocols through a prototype implementation and reveals several of their theoretical and pragmatic characteristics. CIC protocols are not new. The paper by Briatico et al. was perhaps ....

....checkpoints seems to be limited by the occurrence of forced checkpoints due to interactions with other processes. 10 3. 2 Non blocking Checkpointing in CIC The benefits of non blocking checkpointing in reducing the performance overhead of checkpointing protocols have been clearly established [6,14,20]. Non blocking checkpointing allows the application to resume computation as soon as possible and to schedule the actual writing of the checkpoint concurrently with the application execution. The result is that saving the checkpoint to stable storage does not become a bottleneck that impedes ....

[Article contains additional citation context not shown here]

J.S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under UNIX. In Proceedings of the USENIX Technical Conference, pp. 213---214, Jan. 1995.

....and its active information, i.e. its descriptor, access mode, the offset to which it is positioned, etc. Although supporting the correct rollback of persistent state has become the primary concern of many users [1] existing checkpoint libraries usually save and restore only active information [2, 3]. This is because it is unacceptably expensive to save all the content of user files into checkpoint due to their arbitrary size and number. This straightforward but incomplete way will result in inconsistent rollbacks of volatile state and persistent state under following circumstances [4] 1) ....

J. S. Plank, M. Beck, G. Kinsley, and K.Li, "Libckpt: Transparent Checkpointing under Unix", Proceedings of the Unix Winter Technical Conference, Jan. 1995, pp. 213-223.

....calls. Hence, a better alternative is to establish checkpoints before the beginning of such program blocks and role back to the latest checkpoint if the execution control is within such a program block at the time of signal for migration of the process. Such checkpoints are called synchronous [11] because they are not initiated by timer interrupts, and thus the programmer knows exactly when they occur. Delayed Incremental Checkpointing strategy can be used for checkpointing in this case. 7.2 Fault Tolerance Here, checkpointing needs to be done at regular intervals. Asynchronous ....

James S. Plank, Micah Beck, Gerry Kingsley, "Libckpt: Transparent Checkpointing under Unix", In USENIX Winter 1995 Technical Conference

....accomplished at the execution site will be lost and must be redone (i.e. it is badput) analogous to a dropped network packet that must be retransmitted. Not all jobs on all systems can be checkpointed. Only some operating systems support process checkpointing. User level checkpointing services [35, 36, 52] often 13 Schedule Placement Execution point Check Execution Checkpoint Execution Preempt Checkpoint Remote I O Figure 5: Job Timeline (Periodic Checkpoints, Remote I O, and Preemption) require the job to be re linked with a checkpointing library (often not possible for commercial ....

....the amount of checkpoint data to be transferred. Techniques for efficiently compressing checkpoints include saving only those memory pages modified since the last checkpoint [54] Memory exclusion allows the application to specify ranges of memory which need not be saved across a checkpoint [52, 53]. The performance benefits of compression vary according to the relative speed of the compression algorithm compared to available I O bandwidth. Compression can be particularly effective when many processors are checkpointing across a shared network, since the checkpoints can be compressed in ....

J. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under UNIX. In Usenix Winter 1995 Tech. Conf., pages 213--223, January 1995.

....are architecture specific: they copy the pages of the program s heap and stack, plus the state of the registers, and store them in a file. The same program can then be easily restarted on the same kind of machine, since the code, addresses of data, etc. will be the same. The libckpt library [PBKL95] is a simple, elegant approach to this kind of checkpointing implemented in user space. Unfortunately, a user space library cannot capture OS resident data, like mappings from file descriptors to open sockets, pipes, etc. However, some operating systems implement 197 checkpointing, e.g. EROS ....

.... should there be active procedures (so far as I could tell) The advantage of platform dependent state transfer is that it can be easily implemented in the framework of standard tools; e.g. no special compiler support is required, even a 204 general purpose checkpointing library (e.g. libckpt [PBKL95] It has the standard drawbacks as well (1.1.2) Moreover, because stack and heap data are copied as is, all procedures and data in the new program must be at the same addresses as before. This prevents the straightforward addition of new global data. Perhaps Gupta s most important contribution ....

James S. Plank, Micah Beck, Gerry Kingsley, and Kai Li. Libckpt: Transparent checkpointing under Unix. In Proceedings of the USENIX Winter Technical Conference, 1995.

.... process at its destination first, and to transfer remaining state subsequently to reduce migration latency [95] Alternatively, for the purposes of checkpointing, incremental schemes for saving a process s memory, such as periodically capturing only dirty pages, may improve time space performance [69]. Beyond the obvious issue of heterogeneity, kernel level state capture schemes have a number of undesirable features in metasystem contexts. First, as the number of different architecture and operating system platforms grows, the issue of mechanism portability becomes important in addition to ....

....of support for heterogeneity, strongly suggest the use of user level state capture mechanisms. 2.3.1. 2 User Level Mechanisms A number of systems to date have provided some form of homogeneous process state capture implemented at the user level (i.e. without direct, special kernel support)[14,55,54,69]. For example, Condor[55] performs process state capture and recovery in homogeneous environments by using a slightly modified core dump of the process to capture and recover memory and processor state. Needed operating system specific information associated with the process is maintained at the ....

[Article contains additional citation context not shown here]

J.S. Plank, M. Beck, G. Kingsley, and K. Li, "Libckpt: Transparent Checkpointing under Unix," in Proceedings of USENIX Winter 1995 Technical Conference, New Orleans, LA, January 16-20, 1995.

....makes just about any long running application a possible candidate for migration. This is important for job scheduling algorithms, so they have a broader range of applications to decide whether they (applications) will migrate or not. All available freely distributable tools for checkpointing [1, 2, 3, 4] cannot checkpoint fork parallel applications. So this makes it a new approach to Epckpt. Our tool is able to checkpoint a group of processes running in parallel in a SMP machine. 2 And finally, our tool can save the checkpoint image to any file descriptor abstraction, be it a regular file, a ....

....common shared libraries and dynamic linked libraries. It only works for some special well behaved kind of process, the ones that don t call fork( exec( don t communicate at all via pipes or files. By not allowing processes to fork, Condor can t checkpoint a group of parallel processes. Libckpt[2] is much like Condor and has much of its limitations such as not allowing processes to fork or exec. Also, it uses only regular files to save processes image. To be of more value, Libckpt requires the programmer to modify the source code of the program to give the library some hints on when to ....

J. Plank, M. Beck, G. Kingsley. Libckpt: Transparent Checkpointing under Unix. Princeton University.

....[Jor96] The same concept has been applied in many contexts; Section 7.2.2 mentions some examples. 6 Future work on the checkpointer We have several ideas for improvements to our checkpointer. Plank s libckpt package includes two several common optimizations we would be silly to overlook [PBKL95] We may exploit shared libraries to save time and disk space. We may simplify the tool by packaging it completely as a native class. We may provide a way for our data to persist beyond class and JVM upgrades. We may modify icee to allow the creation of persistent data repositories. And finally, ....

James S. Plank, Micah Beck, Gerry Kingsley, and Kai Li. Libckpt: Transparent checkpointing under Unix. In Proceedings of the 1995 USENIX Technical Conference, pages 213--224, January 1995.

....applications and the proxy can be renegotiated when they migrate, but since the proxy does not migrate, the proxy to nonwrapped application connection remains the same. 5. Related Work There are several existing solutions to process migration problem on UNIX like MPVM [5] Condor [17] LibChkPt [20], MOSIX [3] and Sprite [11] To our knowledge, the systems that provide process migration on Windows NT are NT SwiFT [15] at Bell Labs and a checkpoint facility [24] developed at Intel, Israel. The following sections explain the related work. 5.1 MPVM Parallel Virtual Machine (PVM) is a ....

....fork( or exec( or communicate with other processes via signals, sockets, pipes, files, or any other means. Condor checkpointing code must be linked in with the user s code and it does not work for users of third party software who do not have the access to the source. 5. 3 Libckpt Libckpt [20] is a portable transparent checkpointing library on UNIX. It checkpoints the process state, i.e. it saves the process state to a file and recovers the process state after a failure. It uses transparent incremental and copy on write checkpointing. It also implements userdirected checkpointing to ....

[20] J. S. Plank, M. Beck and G. Kingsley. Libckpt: Transparent Checkpointing under UNIX. In Proceedings USENIX Winter 1995, New Orleans, Lousiana, January 1995.

....once written, remains unchanged. The function is then said to have no side effects. A functional approach has several benefits. External memory algorithms may run for hours or days in practice. The lack of side effects on the external data allows standard checkpointing techniques to be applied [16,19], increasing the reliability of any real application. A functional approach is also amenable to general purpose programming language transformations that can reduce running time. See, e.g. Wadler [22] We formally define the functional I O model in Section 1.1. The key measure of external ....

....transformations to data, which do not change the input. Once a disk cell, representing some piece of state, is allocated and written, its contents cannot be changed. This imposes a sequential, write once discipline on disk writes, which allows the use of standard checkpointing techniques [16, 19], increasing the reliability of our algorithms. When results of intermediate computations are no longer needed, space is reclaimed, e.g. through garbage collection. The maximum disk space active at any one time is used to measure the space complexity. All of our algorithms use only linear space. ....

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under UNIX. In Proc. Usenix Winter 1995 Tech. Conf., pages 213--23, 1995.

....10.1 Optimization The current version of the checkpoint system dumps the entire process state for each checkpoint call. This requires time proportional to the size of the process, and can clearly be an expensive operation for large processes. The developers of the Libchkpt checkpoint system [4] note that it is possible to speed up checkpointing procedures by dumping only those pages whose data has changed since the previous checkpoint call. We may optimize our checkpoint facility to dump incremental changes to the process state by using the VirtualProtect API to write protecting pages ....

J.S. Plank, M. Beck, and G. Kingsley, Libckpt: Transparent Checkpointing Under Unix, 1995 Usenix Conferencee.

....in user space have been proposed or implemented. These checkpointing schemes need some way to save all process data and stack context to disk in order to work. In the case of Condor, an operating system s core dumping mechanism is used for this end [16] Another user space checkpointer, libckpt [19], uses the C library s set jmp( function to save stack state. This implementation assumes that some areas of the address space are contiguous, which may not be true. Dependence upon the organization of process address space is inherently nonportable, regardless of whether or not the code to do it ....

....code simple and to reasonably limit the scope of this project. 6.3 Performance and Verification We chose to test our checkpointer s performance against a user level implementation in order to see if a kernel based implementation is significantly faster. We tested our system against libckpt [19], which is a completely user level checkpointing library. The test consisted of repeatedly checkpointing several processes with different size address spaces over an otherwise idle network. The checkpointing operations were timed using a special register on the Pentium architecture which is ....

[Article contains additional citation context not shown here]

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent Checkpointing under Unix. In USENIX, January 1995.

....undo log concept, using a two phase commit protocol to commit a transaction. Besides requiring explicit denotation of a program to mark the start and end of a transaction, libft does not provide portability. A number of checkpointing systems exist for homogeneous environments, such as Libckpt [11] or a supplement of the Condor system [12] Not only are these systems tied to binary compatible machines, they also do not support transactional file operations. There are two approaches to migration across binary incompatible machines, the Tui system [13] and the work on Dynamic Reconfiguration ....

James S. Plank, Micah Beck, and Gerry Kingsley, "Libckpt: Transparent Checkpointing under Unix," in USENIX Winter 1995 Technical Conference, New Orleans, Louisiana, Jan. 1995, pp. 213--233.

....case of a failure, the failed process is re started and its state is restored to that recorded in the latest checkpoint. In our current implementation, checkpoints are synchronous (i.e. applications block during checkpointing) The checkpointing mechanisms used are similar to those described in [17]. We are currently enhancing our implementation to utilize optimizations such as incremental checkpointing and copy on write [8] Although such optimizations reduce the cost of checkpointing and hence the failure free execution time of distributed application, they do not affect the failure ....

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt:Transparent checkpointing under Unix. In Proceedings of the USENIX Technical Conference, pages 213--224, January 1995.

....or re initialized during the recovery operation. Thus, if the programmer has the freedom to specify exactly which data should be saved in a checkpoint operation it would reduce considerably the size of the checkpoint, and consequently, reduce the performance overhead of the checkpoint operation [13]; Flexibility: in some particular cases, some users may find convenient to perform a data driven or iteration based checkpoint, rather than a blind time triggered checkpoint. This was acknowledged as a very important feature in [9] for the sake of flexibility and functionality, ....

....approach has some nice advantages, like transparency and automatic recovery. However, it may incur a higher performance penalty, it requires more space in stable storage and is restricted to homogeneous platforms. In the past years there has been some work on high level checkpointing schemes [6][13][21 27] Juan Leon implemented a transparent checkpointing mechanism for PVM (Fail Safe PVM) 20] Despite the feasibility of that mechanism he considered a possible relaxation of the transparency as an interesting alternative. Latter on, he proposed an application oriented toolkit for ....

[Article contains additional citation context not shown here]

J.S.Plank, M.Beck, G.Kingsley, K.Li. "libckpt: Transparent Checkpointing Under UNIX", Conference Proceedings USENIX Winter 1995 Technical Conference, January 1995

....f 1, the stop and go effect occurs after the log is replayed and consequently, the cost of recovery marginally increases with f . 6 Related Work The literature contains several systems that have been designed to provide transparent fault tolerance using rollback recovery. They include libckpt [22], Fail safe PVM [19] MIST [5] Co check [31] Manetho [9] and libft [13] As opposed to Egida , however, these systems are designed to support only a specific checkpointing or message logging protocol. Egida emphasis on code reusability and extensibility is also present in the ....

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt:Transparent checkpointing under Unix. In Proceedings of the USENIX Technical Conference, pages 213--224, January 1995.

....it started on. This implies that heterogeneity is not an issue. However, if we wish to restart it on a different machine, with a different architecture, then the problem is identical to that of heterogeneous process migration. Several checkpointing systems have been created for Unix systems [8] [26], but they only function in a homogeneous environment. 8 Summary The Tui Heterogeneous Process Migration system is able to move a process between machines of different architecture. It uses type information that is generated when the migratible program is compiled. The bulk of the work involves ....

James S. Plank, Micah Beck, and Gerry Kingsley. Libckpt: Transparent Checkpointing under Unix. In USENIX Technical Conference, 1995. 30

....but does so in a fairly limited context which is mainly targeted for load balancing amongst a set of desktop machines to exploit idle time. One notable feature supported by MOSIX which REXEC currently does not support is process migration. Mechanisms to implement it, however, are well known [5, 11, 15, 19] in both user level and kernel level implementations and under various constraints. Another notable difference between REXEC and these kernel level implementations is the degree of transparency in the remote execution system. Kernel level implementations can achieve greater levels of transparency ....

PLANK, J. S., BECK, M., KINGSLEY, G., AND LI, K. Libckpt: Transparent checkpointing under unix. In Proceedings of the 1995 USENIX Winter Conference (1995).

....There are two kinds of rollback recovery techniques: checkpoint based and logging based. Checkpoint based techniques periodically save the state of an executing process to a disk file from which it can be recovered after a failure. Examples of work on checkpoint based techniques include Libckpt [13] and Libckp [14] Checkpointing of process state is an expensive operation in the context of high performance network access devices. Duplex provides a logging based mechanism that keeps a persistent record of nondeterministic events, such as changes made to the device configuration. In the event ....

J.S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under unix. In Proc. of Usenix Technical Conference 1995.

.... Failure and repair data was obtained by the authors of [8] and the checkpointing performance data was gleaned from performance results of CosMiC s transparent checkpointer libckp [35] It is assumed that the copy on write optimization yields an 80 percent improvement in checkpoint overhead [24]. The failure rate of LOW is extremely high, which is typical of these environments, and as the data later show, they are not particularly conducive to this kind of parallel computing. This will be discussed later. 1 2 4 8 16 32 Number of processors 30 20 0.5 5 2 3 4 1 10 BT LU EP ....

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under Unix. In Usenix Winter Technical Conference, pages 213--223, January 1995.

....be taken asynchronously without the overhead of making the main memory copy, and can be implemented almost effortlessly on those systems which employ copy on write as part of their fork( system call. This optimization works extremely well at hiding 3 checkpointing latency [LNP90, EJZ92, PL94b, PBKL95] Diskless Checkpointing [PL94a] Instead of saving checkpoints to disk, extra processors can be used to save redundant information so that any one processor can fail and the system can continue to operate. This eliminates disk writes as the major source of overhead. However, this technique ....

....good locality. For other programs in which a sizable portion of the address space is dirty during each checkpoint, incremental checkpointing can degenerate to the unoptimized case. In this situation the cost of catching the page faults can actually increase the checkpointing overhead [FB89, EJZ92, PBKL95] Word level Memory Exclusion [NW94] This technique tracks every read and write in the program so that both clean and dead memory can be excluded from checkpoint files. This leads to (nearly) optimally small checkpoint files. However, the extra overhead incurred due to this tracking can run ....

[Article contains additional citation context not shown here]

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under unix. In Conference Proceedings, Usenix Winter 1995 Technical Conference, January 1995.

....owners. Failure and repair data was obtained by the authors of [6] and the checkpointing performance data was gleaned from performance results of CosMiC s transparent checkpointer libckp [27] It is assumed that the copy on write optimization yields an 80 improvement in checkpoint overhead [18]. The failure rate of LOW is extremely high, which is typical of these environments. For each application, we selected a problem size that causes the computation to run between 14 and 20 hours on a single workstation with no checkpointing or failures. These are matrix sizes of 160 and 175 for BT ....

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under Unix. In Usenix Winter Tech. Conf., pp. 213--223, Jan. 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under Unix. In Usenix Winter Technical Conference, pages 213223, January 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under Unix. In Proceedings of the 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and Kai Li. Libckpt: Transparent Checkpointing under Unix. Proceedings of the USENIX Winter 1995.

No context found.

J. S. Plank, M. Bech, G. Kingsley, and K. Li. Libckpt: Transparent Checkpointing Under UNIX. In Usenix Winter 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under UNIX. In Proceedingsof the 1995.

No context found.

J. Plank, M. Beck, and G. Kingsley. Libckpt: Transparent checkpointing under UNIX. In Proc. of USENIX Winter Technical Conference, pages 213--223. USENIX Association, 1995.

No context found.

J.S. Plank, M. Beck and G. Kingsley, "Libckpt: Transparent Checkpointing under UNIX", Proc. USENIX Winter 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under unix. Technical Report UT-CS-94-242, 1994.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under unix. Technical Report UT-CS-94-242, 1994.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li, "Libckpt: Transparent checkpointing under unix, Tech. Rep. UT-CS-94-242, 1994. [Online]. Available: citeseer.ist.psu.edu/plank95libckpt.html

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li, "Libckpt: Transparent checkpointing under unix," in Proceedings, Usenix Winter 1995.

No context found.

PLANK, J. S., BECK, M., KINGSLEY, G., AND LI, K. Libckpt: Transparent checkpointing under unix. In Proceedings of the 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent Checkpointing under Unix. In Proceedings of Usenix Winter 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under unix. In Proceedings of Usenix Winter 1995.

No context found.

J. S. Plank et al, "Libckpt: Transparent checkpointing under Unix", Proc. Usenix Tech. Conf., pp. 213-223, 1995.

No context found.

J. S. Plank, M. Bech, G. Kingsley, and K. Li. Libckpt: Transparent Checkpointing Under UNIX. In Usenix Winter 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li, "Libckpt: Transparent Checkpointing under Unix," Proceedings of USENIX Winter Technical Conference, New Orleans LA, pp. 213-223, January 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under UNIX. Technical Report UT-CS-94-242, Dept. of Computer Science, University of Tennessee, 1994.

No context found.

J.S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent checkpointing under unix. In Proc. of Usenix Technical Conference 1995.

No context found.

James S. Plank, Micah Beck, and Gerry Kingsley. Libckpt: Transparent Checkpointing under UNIX. In Proc. USENIX Winter 1995, New Orleans, Louisiana, January 1995.

No context found.

J. S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt: Transparent Checkpointing under Unix. From http://www.cs.utk.edu/~plank/plank/papers/USENIX-95W.html.

No context found.

J.S. Plank, M. Beck, G. Kingsley, and K. Li. "Libckpt: transparent checkpointing under Unix." In Proceedings of the 1995 USENIX Technical Conference, pp. 213--224, January1995.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC