home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / research / 1181 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  5.2 KB
  1. Path: sparky!uunet!olivea!hal.com!darkstar.UCSC.EDU!osr
  2. From: grichard@cis.ohio-state.edu (Golden Richard)
  3. Newsgroups: comp.os.research
  4. Subject: Summary of responses to Unix checkpoint request
  5. Message-ID: <1jmq5sINN87g@darkstar.UCSC.EDU>
  6. Date: 21 Jan 93 18:31:24 GMT
  7. Organization: The Ohio State University Dept. of Computer and Info. Science
  8. Lines: 130
  9. Approved: comp-os-research@ftp.cse.ucsc.edu
  10. NNTP-Posting-Host: ftp.cse.ucsc.edu
  11. Originator: osr@ftp
  12.  
  13.  
  14.  
  15. The response to my request for Unix checkpoint/restore packages was
  16. overwhelming, with the great majority of the responses pointing to
  17. Condor, available by ftp from ftp.cs.wisc.edu.   Condor works entirely
  18. at user level [no kernel modifications required] but doesn't currently
  19. support interprocess communication, signals, or fork().  Definitely
  20. worth a look.    With some modifications, Condor may be what I need.
  21.  
  22.  
  23. Some of the non-Condor responses follow (apologies in advance to the
  24. authors for the crude editing):
  25.  
  26. ****************
  27. Bennet S. Yee      
  28.  
  29. I have a mostly portable implementation of just that which I wrote
  30. around 6 years ago.  When you invoke the checkpoint procedure, it
  31. saves the state to a file; when you start up a second process with the
  32. same program (but with different arguments) which calls the restore
  33. procedure, it reads the old state from the file.  What is restored:
  34. data, stack, and all registers -- the restore procedure causes the
  35. restoring process to change its state so that the code appears to be
  36. returning from the save routine but with a different value, much as
  37. longjmp/setjmp does.  Even the arglist and the environment is changed
  38. back to that of the original invocation.  Unix process state that is
  39. NOT restored: I/O descriptors and their state, current working
  40. directory, resource limits.
  41.  
  42. You should be able to anonymous ftp this package from my machine,
  43. play.trust.cs.cmu.edu, from the directory /usr/bsy/pub/.  The package
  44. is in save_world.shar.Z, and it is known to work for Pmaxen, Sun4's,
  45. Sun3's, IBM RTs, and Vaxen.  Porting it to a new architecture should
  46. be relatively simple -- look at the README file.
  47.  
  48. Lemme know what you do with it.
  49.  
  50.  
  51. ********************
  52. charlie shub
  53.  
  54. i'd look at jefferson's Time Warp Operating System or contact Jade
  55. Simulations in Calgary who have implemented such a beastie.
  56.  
  57.  
  58. **********************
  59. Jian Xu
  60.  
  61. Stuart Feldman and Channing Brown's paper "IGOR: a system for program 
  62. debugging via reversible execution" in the 1st Worshop on Parallel 
  63. and Distributed Debugging (1988) described such system (the proceeding 
  64. also has been published as in SIGPLAN).  You may find the following paper 
  65. is also interesting. 
  66.  
  67. @INPROCEEDINGS{kaili:concurrentckp,
  68.         AUTHOR =        "Kai Li and J. F. Naughton and J. S. Plank",
  69.         TITLE =         "Real-time, concurrent checkpointing for parallel
  70.                          programs",
  71.         BOOKTITLE =     "Proc. 2nd ACM SIGPLAN Symp. on Principles and Practice
  72.                          of Parallel Programming",
  73.         PAGES =         "79--88",
  74.         MONTH =         mar,
  75.         YEAR =          1990
  76. }
  77.  
  78.  
  79. I don't know whether there is any production tool and/or free tool for 
  80. doing checkpointing and I am interested in learning if you have any points.
  81.  
  82.  
  83.  
  84. *************
  85. Andrew Mullhaupt
  86.  
  87.  
  88. In modern Unices, a process is a file (often in /proc) and you can
  89. completely record the state of the process via this file.
  90.  
  91. If you're just looking to checkpoint a process it's usually easiest
  92. to use memory mapped files for all your data as opposed to using
  93. malloc/free. You can easily write your own file backed malloc/free
  94. instead. Then the whole state of your process is checkpointed just
  95. by doing a msync, which gets all data onto disk. I've used this for
  96. big jobs which run a long time.
  97.  
  98.  
  99. *************
  100. Greg Price
  101.  
  102. I think that UNICOS (Cray stuff?) has this facility... I think I also saw
  103. a technical paper.... Look for Winter '88 USENIX Technical Conference in
  104. San Diego paper call "Job and Process Recovery in a UNIX-based Operating
  105. System" by Brent Kingsbury and John Kline (brent@yafs.cray.com & jtk@hall.
  106. cray.com) I haven't read it so I don't know how good or bad it is. I 
  107. seen to remember some people doing some work on this stuff a year or so
  108. back...was in usenet news.
  109.  
  110.  
  111. *************
  112. James Pinakis
  113.  
  114.  
  115. There's a public domain package available called "pmckpt" (poor man's
  116. checkpointer).  I can't remember exactly where I got it from but an
  117. archie search on pmckpt should give some results.  Here's the readme
  118. file...
  119.  
  120. [readme file deleted because of length]
  121.  
  122.  
  123. *************
  124. Pete Ware
  125.  
  126. Two options come to mind: "condor" which has been installed at OSU and
  127. will work for many programs merely by relinking and "isis" from
  128. Cornell which replayes IPC messages and has the notion of
  129. checkpointing.        ...
  130.  
  131.  
  132. *************
  133. John Bazik
  134.  
  135. You should look at condor from Univ of Wisconsin.  At Brown, we are working
  136. on our own distributed processing system that we call Quahog.  In it, we
  137. provide a simple checkpoint/restart facility, that does work, but not
  138. transparently, as condor's does.  We have a transparent facility on our
  139. list of todos.
  140. -- 
  141. Golden Richard III             OSU Dept. of Computer and Information Science
  142. grichard@cis.ohio-state.edu                                   (614) 292-0056
  143.