Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

changing path prefixes on restart #53

Open
gc00 opened this issue Apr 9, 2015 · 0 comments
Open

changing path prefixes on restart #53

gc00 opened this issue Apr 9, 2015 · 0 comments

Comments

@gc00
Copy link
Contributor

gc00 commented Apr 9, 2015

We're seeing more and more requests for changing path prefixes on restart. It's time that we rationalize our approach, instead of a series of ad hoc solutions. A large part of this may turn out to be a plugin, but some of it will have to go into the DMTCP core (at least into the MTCP core).
I propose that we have an environment variable: DMTCP_PATH_PREFIXES
It will be set to a colon-separated list both on launch and on restart. On restart, the list should be of the same lenght or else the behavior is undefined. Corresponding paths in the list indicate that the original path prefix should be virtualized and replaced by the new path prefix on restart.
This will directly affect mtcp_restart.c. Currently it has some commented code as a first start that tries to do this for the cwd. This could be a default setting: DMTCP_PATH_PREFIXES=$PWD by default. We will then re-map memory with an underlying file based on the new prefix.
Other places in DMTCP (probably the file plugin) are likely to also be affected. I understand that code less well, but I could probably hack through it. If that code could be re-factored into a new plugin for path virtualization, that might be the best approach.

There are some difficult issues that I do not propose to solve in this first implementation. For example, as we saw with the problem with Java migration, sometimes the underlying file will be strictly different. This will happen for example if there was a directory on the source machine based on one version of software and based on a different version on the destination machine. In this case, we might want to change to MAP_ANONYMOUS. A similar issue comes up for files mapped as MAP_SHARED. As I wrote earlier, I do not propose to solve these issues now --- but we need to be aware of them so that we don't implement a dead end for the evolution of our code.

Please consider this an RFC. I welcome all comments. I could start on a solution by this summer if we are all agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant