link-remap: Add --keep-link-remaps option

[ajwock]

When specified, this option disables the automatic deletion of link-remaps on restore. This allows checkpoints dumped with --link-remap to be restored multiple times (provided that other conditions for reuse are met).

Signed-off-by: Drew Wock [email protected]

[github-actions[bot]]

A friendly reminder that this PR had no activity for 30 days.

[rst0git]

@ajwock What is the use case for this option? Would you be able to add a test?

[ajwock]

In my use case, we have a process which needs to use --link-remap in order to be C/Red. This checkpoint image also may need to be restored from multiple times, but because by default a restore with --link-remap deletes the hardlink, it is not possible to do this with vanilla criu.

I can work on adding a test.

[Snorch]

One possible downside of --keep-link-remaps is that if you leave "remap/path/file.cr_link" on the filesystem you would likely fail dumping the same process again as link creation would fail with EEXIST. (probably after first dump you will have only "remap/path/file" leftover on the filesystem and after second you would get "remap/path/file.cr_link" and third dump would fail, but anyway, see code in open_path around rfi_remap)

[ajwock]

One possible downside of --keep-link-remaps is that if you leave "remap/path/file.cr_link" on the filesystem you would likely fail dumping the same process again as link creation would fail with EEXIST. (probably after first dump you will have only "remap/path/file" leftover on the filesystem and after second you would get "remap/path/file.cr_link" and third dump would fail, but anyway, see code in open_path around rfi_remap)

It's interesting you mention this: I have another patch I was planning on submitting after this one that finds a unique name for the remap in the case of EEXIST. Perhaps I should include that as part of this patch?

[github-actions[bot]]

A friendly reminder that this PR had no activity for 30 days.