Comments on “Transparent User-Level Process Checkpoint and Restore for Migration ” by Boz

Comments on“Transparent User-Level Process Checkpoint and Restore for Migration”by Bozyigit and WasiqFelix Rauch,Thomas M.StrickerLaboratory for Computer SystemsETH-Swiss Institute of TechnologyCH-8092Z¨u rich,Switzerland{rauch,tomstr}@inf.ethz.chAbstractThe simple checkpointing and migration system forUNIX processes as described in the article of Bozyigitand Wasiq[1]can be improved in two ways:First by atechnique to checkpoint and migrate applications withoutthe need to recompile them and second by an alternativeapproach to precisely locate all the data segments of a pro-cess that need to be checkpointed.We fully acknowledgethe difficulty to do checkpointing or even portable check-pointing for the general case of processes and do not claimto solve the many remaining problems with the simplisticcheckpointing and migration approaches presented in theearlier article.Still we are aware of many systems andapplications where a simple solution is extremely helpfulonce it also works with binaries.1IntroductionRecent multi purpose and multi boot clusters are not nec-essarily built out of rack mounted machines,but consistalso of users or even students workstations[4].On suchworkstations,memory intensive and long running pro-cesses cause mainly two kinds of problems:(1)Usersmight want all the available resources of their worksta-tions and therefore get rid of the resource intensive back-ground jobs and(2)the machines might be rebooted tochange the operating system or to perform maintenancetasks.In both cases it is desired that the long running pro-cess’state is not lost and therefore the process is check-pointed.To proceed the process’work,its state is mi-grated to another available and probably idle machine inthe cluster and the process is continued.There are different approaches to apply checkpointingand migration to self written programs or open sourcesoftware as the structure of the available source codecan be changed to match the chosen checkpointing tech-nique1.For other programs there is no source codecesses by transforming and recompiling the source code of an appli-cation,such as described in[2].checkpointed.On some UNIX systems,the data segment does not consist of contiguous,accessible pages.Writable pages containing data segments might be alternated with read only pages of constant data.All these problems lead to a more advanced approach of checkpointing the data parts of a process.3Suggested ImprovementsTo overcome the need for recompilation of applications to enable checkpointing,we suggest to use dynamic link-ing.Dynamic linking techniques allow to track open files,duplicatedfile handles and other program state by redirecting system calls to special library routines.In-stead of redirecting system calls by introducing macros in the source code,we dynamically link the existing ex-ecutable to our checkpointing library by the use of the LDpreinit()in our library is called.This function then initializes the checkpointing library.With this ap-proach the checkpointing library can be initialized with-out changing the source code of the application. Another suggested improvement is a better method to find the data segments of the process to checkpoint.In-stead of trying to link special variables at the beginning and the end of the data area and then checkpointing the memory between the addresses of the two variables,we suggest to analyze the ELF binary of the process.The binary in ELF format contains informations about its dif-ferent segments.The segments are marked as read only data(like program text and probably constant data)or read/write data(like initialized but not constant data). Read only segments need not be checkpointed as they do not change during the process’lifetime and are au-tomatically loaded into memory when the applications is restarted after its migration.On the other hand the pro-cess may change all data in read/write segments,there-fore it is best to checkpoint all its read/write segments. This method assures that all non-constant data segments are checkpointed and that there will be no error after mi-gration due to erroneously restored read only segments in the data space of the process.4ConclusionsThe improvements presented in this paper allow to check-point and migrate applications without the need to change the source or even recompile them.This enhancement is especially important for programs for which there is no source code available and allows to use the checkpointing and migration mechanism even with some commercial ap-plications.In our own experience we found that it is difficult to implement a truly portable user-level checkpointing and migration mechanism.Such a mechanism relies ex-tensively on subtle differences of the various existing UNIX systems and their associated libraries.Remain-ing problems for user-level checkpointing consist of non-checkpointable state in network sockets and randomly ac-cessedfiles.Checkpointing and migration mechanisms help to bet-ter utilize the available resources on modern clusters con-sisting of rack mounted machines or even users work-stations.Equiping a cluster with user-level checkpoint-ing facilities is easy and allows owners of large jobs to keep their long running jobs on unused and otherwise idle workstations.Our improvements allow to integrate some commercial applications into the checkpointing and mi-gration facilities without the need to recompile them. References[1]M.Bozyigit and er-Level ProcessCheckpoint and Restore for Migration.Operating Systems Review,35(2):86–95,2001.[2]Balkrishna Ramkumar and V olker Strumpen.Portable Checkpointing for Heterogeneous Archi-tectures.In In27th International Symposium on Fault-Tolerant Computing—Digest of Papers,pages 58–67,April1997.[3]F.Rauch.Porting ckpt。