C/R: File substitution at restart

Serge E. Hallyn serge at hallyn.com
Wed Sep 8 15:49:27 PDT 2010

Quoting Sukadev Bhattiprolu (sukadev at linux.vnet.ibm.com):
> Serge Hallyn [serge at hallyn.com] wrote:
> | Quoting Matthieu Fertré (matthieu.fertre at kerlabs.com):
> | > Hi,
> | > 
> | > Here is a proposal for a C/R related feature already developed in
> | > Kerrighed: file substitution at restart.
> | > 
> | > The goal of this mail is to start a discussion about adding such feature
> | > to Linux cr. Comments are welcome!
> | 
> | Yup, AFAIK metacluster and zap do this too.  I don't think there is
> | any question about whether we want to support this, but rather
> | what the user-kernel API should look like.  Perhaps the easiest
> | "API" is to have the userspace program rewrite the checkpoint image,
> | but that probably isn't quite as simple as just substituting #s in
> | the image, bc we'll have to also find the place where the source of
> | the original fd was specified and tweak that.
> | 
> | I assume this is one of the things Oren would have 'cradvise()'
> | do, and at this point that sounds nice to me - might be worth
> | seeing how the community reacts.  Sentiments on such things change,
> | after all.
> Yes, I had the same question about the kernel API. cradvise() would be
> one option, but am not too clear on the details. For each process in
> the checkpoint image that we want to substitute one or more fds,
> do we call cradvise() *before* the call to sys_restart() ? This would

No, I would rather think that we follow the Kerrighed example,
and specify a checkpoint-wide id for the fd (the objhash id i
guess).  The first cr_advise() starts to create a restart context,
which finally gets used at sys_restart by the coordinator (and of
course all subsequent tasks).

> require the kernel to save these substitution pairs in memory until
> the following sys_restart() right ?
> Passing in a list of fd-substition pairs to sys_restart() might be one
> option, but would require modifying the sys_restart() API.
> Sukadev

More information about the Containers mailing list