79
edits
Changes
Added btrfs workaround with nocow
"All filesystems are equal, but some filesystems are more equal than others."
"All filesystems are equal, but some filesystems are more equal than others."
This page describes how different different filesystems are and how this affects CRIU dump (and restore) process.
This page describes how different filesystems affect the CRIU dump (and restore) process.
== BTRFS ==
== BTRFS ==
In order to address this issue, CRIU performs path-to-device resolution in user-space by analysing the information obtained from the <code>/proc/$pid/mountinfo</code> files. The routine in question is <code>mount.c:phys_stat_resolve_dev()</code>.
In order to address this issue, CRIU performs path-to-device resolution in user-space by analysing the information obtained from the <code>/proc/$pid/mountinfo</code> files. The routine in question is <code>mount.c:phys_stat_resolve_dev()</code>.
=== BTRFS Workaround ===
One possible workaround to use BTRFS in combination with CRIU is to disable copy on write (COW). During the discussion in https://github.com/containers/podman/issues/9318 one workaround to use Podman's checkpoint/restore support was: <code>chattr +C /var/lib/containers</code>
== NFS ==
== NFS ==
== AUFS ==
== AUFS ==
[http://aufs.sourceforge.net AUFS] is not (yet) upstream, but Docker guys use one, so does CRIU.
This FS has a strange BUG -- when we <code>execv</code> some file on it, and then check for <code>/proc/$pid/maps</code> or <code>.../smaps</code> files or links in the <code>.../map_files/</code> directory, we would note, that those mappings, that correspond to the executed file are seen under "wrong" paths.
How wrong are these paths? AUFS joins several subdirectories into one, all these subdirs are called ''branches''. And the file seen inside AUFS by one path "really" has some other one -- the path by the file is seen in the respective branch. So in proc in these strange cases we would see the path from branch, instead of the path, by which the file is seen in AUFS.
This is problematic, since CRIU needs to know the path by which the file was accessed inside AUFS in order to properly restore one. To fix this, CRIU checks that there's an AUFS mount in the game, reads the branches info from sysfs, and then, when meets an AUFS file in mappings, check for the path to belong to one of the branches and "fixes" one. This has sits in the <code>sysfs_parse.c:fixup_aufs_vma_fd</code>.
[[Category:Under the hood]]
[[Category:Under the hood]]
[[Category:Files]]